面向对象设计的 10 条戒律

不,这不是上帝说的。

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

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

I.遵循单一职责原则

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

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

II.遵循开放封闭原则

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

public class PersonalLoan
{
    public void Terminate()
    {
        //Execute Termination related rules here and terminate a personal loan
    }
}
public class AutoLoan
{
    public void Terminate()
    {
        //Execute Termination related rules here and terminate a personal loan
    }
}
public class LoanProcessor
{
    public void ProcessEarlyTermination(object loan)
    {
        if ( loan is PersonalLoan )
        {
            //Personal Loan processing
        }
        else if (loan is AutoLoan)
        {
            //Auto Loan Processing
        }
    }
}

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

public abstract class Loan
{
    public abstract void Terminate();
}
public class PersonalLoan: Loan
{
    public override void Terminate()
    {
        //Execute Termination related rules here and terminate a personal loan
    }
}
public class AutoLoan: Loan
{
    public override void Terminate()
    {
        //Execute Termination related rules here and terminate a personal loan
    }
}
public class LoanProcessor
{
    public void ProcessEarlyTermination(Loan loan)
    {
        loan.Terminate();
    }
}

这样的话,如果添加了新类型的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学习网(javalearns)

原文发表时间:2017-06-29

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Jimoer

Java设计模式学习记录-责任链模式

 已经把五个创建型设计模式和七个结构型设计模式介绍完了,从这篇开始要介绍行为型设计模式了,第一个要介绍的行为型设计模式就是责任链模式(又称职责链模式)。

1222
来自专栏积累沉淀

Java设计模式(十七)----责任链模式

责任链模式 一、 概念 二、 引子 三、 结构 四、 具体案例 一、概念 责任链模式是一种对象的行为模式。...

1899
来自专栏余林丰

命令模式

当学了这个命令模式后,又一次体会到编程的艺术,明明一个看似很简单的事,却要用“复杂”的方法来实现,就像在之前我多次说到的,其实并不是“复杂”,并不是“难”,而是...

1729
来自专栏斑斓

我们的技术实践

本文是我在中生代技术群分享的话题《创业一年经历的技术风雨》中的第三部分《研发团队总结的技术实践》。若要阅读第二部分《技术团队的管理》,请移步中生代技术群公众号。...

3305
来自专栏Java学习网

最佳编码实践:搞砸代码的10种方法

 这是一篇提供有效、实用编程方法的程序箴言,作者Susan Harkins是世界最大的技术期刊出版社的主编,具有多年的实践经验;在这篇文章里她重申“最佳编码实践...

2714
来自专栏SDNLAB

OpenFlow 1.3 学习笔记

因为7、8月我跟小伙伴们在备战今年的全国大学生SDN大赛,9月在全身心投入准备特殊人才保研的专家答辩,所以好久没有新文章跟大家见面啦。现在一切尘埃落定,继续卯足...

3837
来自专栏Java帮帮-微信公众号-技术文章全总结

Java设计模式-外观模式

外观模式: 又称门面模式: 外观Facade为子系统的一组接口提供一个一致界面,使得这组子系统易于使用(通过引入一个新的外观角色降低原系统复杂度,同时降低客户类...

3454
来自专栏纯洁的微笑

看程序员怎么解决食堂排队问题

在学校的时候,我不爱去食堂成功,一是由于暗黑料理,更重要的一点是人太多了,队伍往往从窗口排到了门口,点菜、计算价格、付款三种业务由打饭阿姨一人完成,思维切换忙碌...

951
来自专栏Gcaufy的专栏

async/await 带你逃离回调地狱

不曾见过天堂就不会畏惧地狱,async/await是目前尝试过的最好的异步回调解决方案,本文通过详细步骤给大家讲解。

5310
来自专栏JAVA高级架构

两年Java程序员面试经

工作两年有余,本人第一份工作是在一家外包公司,第二份工作是在一家做SAAS平台的公司,第一家公司让我入门,进入了软件开发的行业,了解了一些基础的东西;第二家公司...

3432

扫码关注云+社区

领取腾讯云代金券