专栏首页java一日一条面向对象设计的 10 条戒律

面向对象设计的 10 条戒律

不,这不是上帝说的。

这也不是Jon Skeet / Martin Fowler / Jeff Atwood / Joel Spolsky(可以用你最喜欢的技术专家的替换这些名字)说的。

我们正在审查一些代码,并开始讨论为什么我们走捷径,不遵循常识原则。虽然每个人在对待关于类应该如何基于功能上下文来构建的问题上都有自己的智慧,但仍然有一些基本原则值得我们在设计类的时候牢牢记住。

I.遵循单一职责原则

每个类都应该有一个并且只有一个引起它变化的原因。这不仅适用于类,方法也是如此。不知道你有没有见到过那些长篇大论的冗余的类和方法,当将它们写到纸上的时候,简直就是懒婆娘的裹脚布——又臭又长?好吧,我们要提出的观点是不要这样做。

该原则的要点就是每个类或方法都有一个存在的理由。如果类被命名为Loan,那么它就不应该处理银行帐户的相关细节。如果方法被命名为GetLoanDetails,那么它应该负责获取贷款的详细信息!

II.遵循开放封闭原则

这一条使你能够思考你的系统将如何适应未来的变化。它指出,系统应该允许添加新的功能,但对现有代码的更改要做到最少。因此,设计对于扩展应该是开放的,但对于修改应该是封闭的。在我们的例子中,开发人员做了这样的事情:

LoanProcessor的问题是,当有一种新类型的Loan,例如HomeLoan出现的时候,它将不得不改变。结构最好是这样:

这样的话,如果添加了新类型的Loan,那么LoanProcessor也不会受影响。

III.尝试使用组合优于继承

如果不能正确地遵循这一条原则,那么可能会导致脆弱的类层次。这个原则真的很简单,只需要问一个问题——如果我要看子类,那么我能不能说“Child是Parent的一种类型?”或者,它更像“Child某种程度上是Parent的一种类型?“

始终对第一个问题使用继承,因为它将允许使用Child无论Parent在哪里。这也将允许你能够实现另一个称为Liskov替代原则的设计原则。并且在你想部分使用一个类的功能的时候使用组合。

IV.封装数据和行为

大多数开发人员只做数据封装,忘记封装基于上下文而变化的代码。不但隐藏类的私有数据很重要,而且创建被良好封装的作用于私有数据的方法也很重要。

V.类遵循松散耦合原则

这与封装正确的行为是相辅相成的。如果行为被很好地封装在类中,那么就只能创建松散耦合的类。我们可以通过依赖于抽象而不是实现来做到松散耦合。

VI.使类高度内聚

我们不应该在不同的类之间散开数据和行为。应该努力使类不泄露/打破实现到其他类的细节。这意味着不允许类有代码,因为这样超出了它存在的目的。当然,有一些设计范例,如CQRS,会希望你在不同的类中隔离某些类型的行为,但它们只用于分布式系统。

VII.编码接口而不是实现

这促进了松散耦合原则,并使得我们能够改变底层实现或引入新的实现,而不影响使用它们的类。

VIII.保持DRY(Don’t Repeat Yourself)

也是一个声明不要在两个不同的地方重复相同代码的设计原则。也就是说,特定功能或算法应当,仅,在一个地方实现。如果重复实现的话,则会导致维护问题。与此相反的是WET原则——Write Everything Twice。

IX.最少知识原则,也叫做迪米特法则。

这个原则声明对象不应该知道它协作对象的内部细节。它被著名地称为——与朋友交流,不要和朋友的朋友交流。类应该只能调用它正在协作的类的公共数据成员。不应该被允许访问由那些数据成员组成的类的行为或数据。如果不能正确遵守,则会导致紧密耦合,从而创建出更难改变的系统。

X.遵循好莱坞原则:Don’t Call Us, We’ll Call You

这能够打破条件流逻辑的模型,并允许基于事件执行代码。这要么通过事件回调,要么通过注入接口的实现来完成。依赖注入,控制反转或观察者设计模式都是这个原则的好例子。这个原则促进了类之间的松散耦合,并使得实现非常可维护。

本文分享自微信公众号 - java一日一条(mjx_java),作者:收听我

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2016-11-01

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 遨游码海之maven不可不知的小功能

    进入正题,今天要说的是一个maven的一个小技能,在编译期间可以容许我们做一些自己想做的事情。

    哲洛不闹
  • JAVA:自定义套件...

    各位亲爱的小伙伴们大家好,最近很多伙伴都问我该怎么做自定义套件封装,我在这里做了一个教程分享给大家。

    哲洛不闹
  • 前端程序员为什么应该拿高薪

    决定产品价格最重要的是供求关系。技术水平重要,但绝没有市场供给关系重要。不能理解的话举个简单例子,空气重要么?重要,人没了空气活不了,但是为什么不值钱?就是因为...

    哲洛不闹
  • 小白学习web前端开发学习攻略

    前端工程师,也叫Web前端开发工程师。web前端,前端从字面意思就很好理解,前端就是负责网站框架,首页内容的设计。web前端是IT行业入门门槛相对较低的类别,很...

    千锋哈尔滨IT培训
  • Leetcode 242. Valid Anagram

    Given two strings s and t, write a function to determine if t is an anagram of ...

    triplebee
  • Javascript中的Return,Return false和Return true

    版权声明:博客文章都是作者辛苦整理的,转载请注明出处,谢谢! https://blog.csdn....

    Tyan
  • 编写可复用的服务端软件系统应该注意的五个重要细节

    编写可复用的服务端软件系统应该注意的五个重要细节 作为程序员,我们往往希望自己写的代码能被最大程度的重用,但是我们依然能看到有很多“被重复发明的轮子”,其原因往...

    韩伟
  • 拿下人脸识别“世界杯”冠军!松下-NUS 和美国东北大学实战分享

    【新智元导读】被业界称为人脸识别“世界杯”的微软百万名人识别竞赛 MS-Celeb-1M 冠军团队技术分享。Panasonic-NUS 合作团队认为,竞赛最大的...

    新智元
  • Spring Boot2+JPA之悲观锁和乐观锁实战

    在我们开发的项目中,大量的请求,或者同时的操作,很容易导致系统在业务上发生并发的问题。通常讲到并发,解决方案无非就是前端限制重复提交,后台进行悲观锁或者乐观锁限...

    攻城狮的那点事
  • 架构设计与安全:代码未写,漏洞已出。

    来自 MIG 玄武实验室总监、专家工程师于旸,就基架构和设计的安全,给大家进行了关于安全问题的成因分享。

    腾讯玄武实验室

扫码关注云+社区

领取腾讯云代金券