《设计模式之禅》之六大设计原则上篇
本文主要讲单一职责原则和里氏替换原则。 一、单一职责原则1.定义应该有且有一个原因引起类的变更。 2.单一职责原则的好处好处如下:
注意: 3.小结对于单一职责原则,以我实际开发为例,在公司开发项目,基本上沿用得开发模式就是MVC,模型-视图-控制器,每个职责不一样。然后再往大的范围来说,分层,比如数据访问层、业务逻辑层、视图表现层(其中该层就是MVC的应用)。 还有就是单一职责的一个体现就是一个函数办一件事情,比方说业务逻辑层中修改密码(设计db操作修改用户信息),最好是修改密码是一个方法,修改用户基本信息(例如昵称、性别、职位、籍贯等)是另外一个方法。不同的方法(不同的函数)办的事情不一样,我觉得这样也是单一职责的一个最好实践。记得刚工作第一年的时候,写代码基本上数据访问层就和业务逻辑层是一样的,这样的写法导致的后果是,如果是少量的五到六个类还好,但如果数十个的话或成百上千个这样写的话,后果将会非常严重,直接会导致维护成本的上升,可扩展性差、可维护性差等。 最后归纳一点,单一职责如果是以自己平时写写Demo玩玩而言实现起来并不困难。但是对于公司而言就不一样了,拿我曾经接手的一个项目来说,该项目采用jfinal框架,然后前任架构师对其又再度修改封装了很多东西,可以称之为扩展。当我接手这个项目的时候,初看项目结构,捋了下,大致能根据包名看出功能分层,但当我深入阅读的时候,发现太多的拼接sql,而且业务逻辑层和数据访问层并未分层明确,就像我们一般开发喜欢分为视图、业务、数据这样的分层,而这个项目基本上就是视图(一种是返回jsp,另外一种作为路由返回JSON数据),业务实现(基本上就是写业务逻辑的),还有较多的dto、request、response等包名下的众多类。 通常我所认为的最佳实践就是: 对于单一职责原则,接口一定要做到单一职责,类的设计尽量做到只有一个原因引起变化。 二、里氏替换原则继承的优点:
继承的缺点:
1.里氏替换原则定义那么什么是里氏替换原则呢? 通俗的来说:只要父类能出现的地方子类就可以出现,而且替换为子类也不会产生任何错误或异常,使用者可能根本就不需要知道是父类还是子类。但是,反过来就不行了,有子类出现的地方,父类未必适应。 2.规范里氏替换原则为良好的继承定义了一个规范,一句简单的定义包含4层含义。 (1)子类必须完全实现父类的方法注意: (2)子类可以有自己的个性子类可以有自己的行为和外观,也就是方法与属性,那这里为什么要再提呢? (3)覆盖或实现父类的方法时输入参数可以被放大方法中的输入参数称为前置条件,这是什么意思? (4)覆写或实现父类的方法时输出结果可以被缩小这是什么意思呢? 采用里氏替换原则的目的就是增强程序的健壮性,版本升级时也可以保持非常好的兼容性。即使增加子类,原有的子类还可以继续运行。在实际项目中,每个子类对应不同的业务含义,使用父类作为参数,传递不同的业务含义,使用父类作为参数,传递不同的子类完成不同的业务逻辑。 3.小结在项目中,采用里氏替换原则时,尽量避免子类的”个性”,一旦子类有”个性”,这个子类和父类之间的关系就很难调和了,把子类当做父类使用,子类的”个性”被抹杀;把子类单独作为一个业务来使用,则会让代码间的耦合关系变得扑朔迷离,缺乏类替换的标准。 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |