面向对象设计的 10 条戒律

不，这不是上帝说的。

这也不是Jon Skeet / Martin Fowler / Jeff Atwood / Joel Spolsky（能够用你最喜欢的技术专家的替换这些名字）说的。

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

10-commandments-of-ood

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

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

最后，给你们推荐一个 前端学习进阶内推交流群685910553（ 前端资料分享），无论你在地球哪一个方位， 无论你参加工做几年都欢迎你的入驻！（群内会按期免费提供一些群主收藏的免费学习书籍资料以及整理好的面试题和答案文档！）

若是您对这个文章有任何异议，那么请在文章评论处写上你的评论。

若是您以为这个文章有意思，那么请分享并转发，或者也能够关注一下表示您对咱们文章的承认与鼓励。

愿你们都能在编程这条路，越走越远。