▲点击上方“
CocoaChina
”关注即可免费学习iOS开发
译文链接：http://www.codeceo.com/article/10-commandments-of-ood.html
英文原文：10 Commandments of Object-Oriented Design
翻译作者：码农网 – 小峰
不，这不是上帝说的。
这也不是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
