不,这不是上帝说的。
这也不是Jon Skeet / Martin Fowler / Jeff Atwood / Joel Spolsky(可以用你最喜欢的技术专家的替换这些名字)说的。
我们正在审查一些代码,并开始讨论为什么我们走捷径,不遵循常识原则。虽然每个人在对待关于类应该如何基于功能上下文来构建的问题上都有自己的智慧,但仍然有一些基本原则值得我们在设计类的时候牢牢记住。
每个类都应该有一个并且只有一个引起它变化的原因。这不仅适用于类,方法也是如此。不知道你有没有见到过那些长篇大论的冗余的类和方法,当将它们写到纸上的时候,简直就是懒婆娘的裹脚布——又臭又长?好吧,我们要提出的观点是不要这样做。
该原则的要点就是每个类或方法都有一个存在的理由。如果类被命名为Loan,那么它就不应该处理银行帐户的相关细节。如果方法被命名为GetLoanDetails,那么它应该负责获取贷款的详细信息!
这一条使你能够思考你的系统将如何适应未来的变化。它指出,系统应该允许添加新的功能,但对现有代码的更改要做到最少。因此,设计对于扩展应该是开放的,但对于修改应该是封闭的。在我们的例子中,开发人员做了这样的事情:
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也不会受影响。
如果不能正确地遵循这一条原则,那么可能会导致脆弱的类层次。这个原则真的很简单,只需要问一个问题——如果我要看子类,那么我能不能说“Child是Parent的一种类型?”或者,它更像“Child某种程度上是Parent的一种类型?“
始终对第一个问题使用继承,因为它将允许使用Child无论Parent在哪里。这也将允许你能够实现另一个称为Liskov替代原则的设计原则。并且在你想部分使用一个类的功能的时候使用组合。
大多数开发人员只做数据封装,忘记封装基于上下文而变化的代码。不但隐藏类的私有数据很重要,而且创建被良好封装的作用于私有数据的方法也很重要。
这与封装正确的行为是相辅相成的。如果行为被很好地封装在类中,那么就只能创建松散耦合的类。我们可以通过依赖于抽象而不是实现来做到松散耦合。
我们不应该在不同的类之间散开数据和行为。应该努力使类不泄露/打破实现到其他类的细节。这意味着不允许类有代码,因为这样超出了它存在的目的。当然,有一些设计范例,如CQRS,会希望你在不同的类中隔离某些类型的行为,但它们只用于分布式系统。
这促进了松散耦合原则,并使得我们能够改变底层实现或引入新的实现,而不影响使用它们的类。
也是一个声明不要在两个不同的地方重复相同代码的设计原则。也就是说,特定功能或算法应当,仅,在一个地方实现。如果重复实现的话,则会导致维护问题。与此相反的是WET原则——Write Everything Twice。
这个原则声明对象不应该知道它协作对象的内部细节。它被著名地称为——与朋友交流,不要和朋友的朋友交流。类应该只能调用它正在协作的类的公共数据成员。不应该被允许访问由那些数据成员组成的类的行为或数据。如果不能正确遵守,则会导致紧密耦合,从而创建出更难改变的系统。
这能够打破条件流逻辑的模型,并允许基于事件执行代码。这要么通过事件回调,要么通过注入接口的实现来完成。依赖注入,控制反转或观察者设计模式都是这个原则的好例子。这个原则促进了类之间的松散耦合,并使得实现非常可维护。
什么是面向对象编程思想,为什么要用面向对象思想。js中的面向对象思想和其他静态语言相比有什么不同。js中prototype,constructor,__proto__这些都是什么鬼?
面向对象设计的6个设计原则:1.单一职责原则,2.里氏替换原则,3.依赖倒置原则,4.接口隔离原则,5.迪米特法则,6.开闭原则
面向对象方法是一种运用对象,类,继承,封装,聚合,关联,消息,多态等概念和原则来构造软件系统的开发思想(方法)。
在ES5中,我们经常使用方法或者对象去模拟类的使用,并基于原型实现继承,虽然可以实现功能,但是代码并不优雅,很多人还是倾向于用 class 来组织代码,很多类库、框架创造了自己的 API 来实现 class 的功能。
在面试时经常会被问到面向过程和面向对象有什么区别,虽然都是编程的一种思想,但是他们的侧重点不同,我们从以下几个方面进行简单总结。
代码封装可以避免代码冗余,避免去哪聚变量污染,本质就是把公共的代码抽离出来在需要的地方随时调用在继承中也有体现
在面向对象的设计中,系统是由对象和让对象状态发生改变的方法,让对象到达另一种状态来达到目的的。当系统渐渐变大,对象渐渐变多,每个对象间的纠缠越来越多的时候一个对象的状态受到多个控制信号的机会就越来越多
JavaScript 是一个强大的面向对象编程语言,但是,并不像传统的编程语言,它采用一个以原型为基础的OOP模型,致使它的语法让大多数开发人员看不懂。另外,JavaScript 也把函数作为首要的对象,这可能会给不够熟悉这门语言的开发人员造成更大的困惑
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!