对设计模式的感悟

设计模式的出现,体现了先进的OO设计原则,这些设计原则以及设计模式的初衷都是为了拯救陷于系统维护噩梦的程序员:越来越大量的不断增加的复杂业务逻辑使得系统设计者们在OO设计中,仅仅单靠java原本的封装、抽象、继承和多态已经将他们自己置入两难的境地。一方面,OO程序设计者要求较好的代码复用性,于是将自己手头仅有的为数不多的几样工具之一——继承大肆滥用,于是将代码中间的类推向了一个固化、强耦合的不归路。另一方面,现代系统要求迭代更新快,对系统开发完成后的可扩展性,可维护性提出了越来越高的要求,于是继承带来的强耦合以及子类之间的差异性带来的大量针对型修改成为了程序员的噩梦。

具体来说,一般意义上来讲,为大家所承认的具有面向对象色彩的程序复用方法即是继承和实现接口,但严格来讲,实现接口并没有实现程序的复用:一、接口只定义了方法名,而未定义方法体。在具体实现某接口时,要在具体实现类中实现其方法体。在代码维护阶段,我们针对方法的某种具体实现进行修改仍需到接口方法的对应具体实现类中去修改,这并没有降低程序员的工作量。二、实现类实现某一个接口时需要将该接口的方法全部实现,使原本该实现类不需要的方法,被迫存在,这不但没有提高代码的复用性,还使实现类的方法泛滥,变相的降低了代码复用的优势,增加了程序员的工作量。而对于继承,它虽然很好地执行了代码的复用性,但也一定程度上存在着实现接口所具有的问题。不过,“继承”的问题还远不止于此:由于很多子类共享的方法已经在父类中实现,因此,当后续的业务需求需要使一些子类对父类中的这些共享方法提出差异性要求时,这些子类就只能对这些共享

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值