框架设计时强制性依赖以及非依赖式约定的考虑

本文讨论了在Struts框架中采用不同方式定制Action的方法及其利弊。一种是直接继承框架提供的Action类,这种方式简单但增加了对框架的依赖;另一种则是通过非强制性的约束来实现,虽然减少了依赖但也可能引入更多错误。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

在框架的设计中,例如struts,我们知道对于每个用户定制action都需要继承strtus的action,此乃典型的方式,这种方式的弊端是对框架依赖严重,不利于系统的移植,另一种方式是针对用户的类,不进行任何框架接口类的继承或者实现,只通过形式上进行约束,例如针对每个execute方法,框架不提供任何超类,只是口头的约定用户需要使用框架则必须自行实现该方法,不提供任何强制性的约束,这种方式的好处是用户定制的action可在代码实现上避免对框架的依赖,然而却因为没有固定约束,导致容易出现错误。

第一种方式是传统的解决方案,利弊大家也都知道,第二种方式虽然容易让使用的用户犯错,不过可以减轻应用对框架的依赖程度,而且通过框架详细指导可以减少用户犯错的机会,为了减少框架依赖此种做法是否有可取的价值?在此希望各位高手不吝赐教。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值