<p>这也不是Jon Skeet / Martin Fowler / Jeff Atwood / Joel Spolsky（可以用你最喜欢的技术专家的替换这些名字）说的。</p>    <p>我们正在审查一些代码，并开始讨论为什么我们走捷径，不遵循常识原则。虽然每个人在对待关于类应该如何基于功能上下文来构建的问题上都有自己的智慧，但仍然有一些基本原则值得我们在设计类的时候牢牢记住。</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/98b25832ec950a677b31db6b485b8bf3.png"></p>    <p><strong>1.遵循单一职责原则</strong></p>    <p>每个类都应该有一个并且只有一个引起它变化的原因。这不仅适用于类，方法也是如此。不知道你有没有见到过那些长篇大论的冗余的类和方法，当将它们写到纸上的时候，简直就是懒婆娘的裹脚布——又臭又长？好吧，我们要提出的观点是不要这样做。</p>    <p>该原则的要点就是每个类或方法都有一个存在的理由。如果类被命名为Loan，那么它就不应该处理银行帐户的相关细节。如果方法被命名为GetLoanDetails，那么它应该负责获取贷款的详细信息！</p>    <p><strong>2.遵循开放封闭原则</strong></p>    <p>这一条使你能够思考你的系统将如何适应未来的变化。它指出，系统应该允许添加新的功能，但对现有代码的更改要做到最少。因此，设计对于扩展应该是开放的，但对于修改应该是封闭的。在我们的例子中，开发人员做了这样的事情：</p>    <pre>  <code class="language-cpp">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          }      }  }</code></pre>    <p> </p>    <p>LoanProcessor的问题是，当有一种新类型的Loan，例如HomeLoan出现的时候，它将不得不改变。结构最好是这样：</p>    <pre>  <code class="language-cpp">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();      }  }</code></pre>    <p> </p>    <p>这样的话，如果添加了新类型的Loan，那么LoanProcessor也不会受影响。</p>    <p><strong>3.尝试使用组合优于继承</strong></p>    <p>如果不能正确地遵循这一条原则，那么可能会导致脆弱的类层次。这个原则真的很简单，只需要问一个问题——如果我要看子类，那么我能不能说“Child是Parent的一种类型？”或者，它更像“Child某种程度上是Parent的一种类型？“</p>    <p>始终对第一个问题使用继承，因为它将允许使用Child无论Parent在哪里。这也将允许你能够实现另一个称为Liskov替代原则的设计原则。并且在你想部分使用一个类的功能的时候使用组合。</p>    <p><strong>4.封装数据和行为</strong></p>    <p>大多数开发人员只做数据封装，忘记封装基于上下文而变化的代码。不但隐藏类的私有数据很重要，而且创建被良好封装的作用于私有数据的方法也很重要。</p>    <p><strong>5.类遵循松散耦合原则</strong></p>    <p>这与封装正确的行为是相辅相成的。如果行为被很好地封装在类中，那么就只能创建松散耦合的类。我们可以通过依赖于抽象而不是实现来做到松散耦合。</p>    <p><strong>6.使类高度内聚</strong></p>    <p>我们不应该在不同的类之间散开数据和行为。应该努力使类不泄露/打破实现到其他类的细节。这意味着不允许类有代码，因为这样超出了它存在的目的。当然，有一些设计范例，如CQRS，会希望你在不同的类中隔离某些类型的行为，但它们只用于分布式系统。</p>    <p><strong>7.编码接口而不是实现</strong></p>    <p>这促进了松散耦合原则，并使得我们能够改变底层实现或引入新的实现，而不影响使用它们的类。</p>    <p><strong>8.保持DRY（Don’t Repeat Yourself）</strong></p>    <p>也是一个声明不要在两个不同的地方重复相同代码的设计原则。也就是说，特定功能或算法应当，仅，在一个地方实现。如果重复实现的话，则会导致维护问题。与此相反的是WET原则——Write Everything Twice。</p>    <p><strong>9.最少知识原则，也叫做迪米特法则。</strong></p>    <p>这个原则声明对象不应该知道它协作对象的内部细节。它被著名地称为——与朋友交流，不要和朋友的朋友交流。类应该只能调用它正在协作的类的公共数据成员。不应该被允许访问由那些数据成员组成的类的行为或数据。如果不能正确遵守，则会导致紧密耦合，从而创建出更难改变的系统。</p>    <p><strong>10.遵循好莱坞原则：Don’t Call Us, We’ll Call You</strong></p>    <p>这能够打破条件流逻辑的模型，并允许基于事件执行代码。这要么通过事件回调，要么通过注入接口的实现来完成。依赖注入，控制反转或观察者设计模式都是这个原则的好例子。这个原则促进了类之间的松散耦合，并使得实现非常可维护。</p>    <p> </p>    <p> </p>    <p>来自：http://www.jointforce.com/jfperiodical/article/3457</p>    <p> </p>