面向对象设计的 10 条戒律



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

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