设计形式:C#面向对象设计形式纵横谈[学习:01.面向对象的设计形式与规范 课程笔记]

率先讲:1. 面向对象设计情势与规则

设计情势简介:

      
每一个情势描述了一个在大家周围不断重复暴发的题目,以及该问题的化解方案的为主。
                                                        ——Christopher
Alexander{建筑师}

软件设计师对设计形式的定义的领悟:

(1)设计情势描述了软件设计过程中某一类常见问题的通常的化解方案。
(2)面向对象设计格局描述了面向对象设计过程中、特定情景下、类与交互通信的靶子里面常见的社团关系。
(3)人是一个经验性的动物

 

GoF23 种设计形式是面向对象设计情势的功底、但不是设计格局的全方位
• 历史性作品《设计情势:可复用面向对象软件的根基》1994
一书中讲述了23种经典面向对象设计形式,创设了情势在软件设计中的地位。该书四位作者被众人并称为Gang
of Four (GoF),“多少人组”,该书讲述的23种经典设计情势又被众人称之为GoF23
种设计格局。

由于《设计格局:可复用面向对象软件的基础》一书确定了设计格局的地点,人们常见所说的设计形式隐含地表示“面向对象设计情势”。但这并不代表“设计情势”就异常“面向对象设计格局”,也不意味着GoF23种形式就表示了独具的“面向对象设计形式”。除了“面向对象设计格局”外,还有此外设计格局。除了GoF23
种设计形式外,还有更多的面向对象设计情势。
• GoF23
种设计格局是读书面向对象设计情势的起源,而非终点;本培训课程的对象是让学员在建立在使得方法的根底上,明白GoF23种设计格局。

 

设计形式与面向对象

面向对象设计情势解决的是“类与相互通信的对象期间的协会关系,包括它们的角色、职责、协作方法多少个地点。

面向对象设计情势是“好的面向对象设计”,所谓“好的面向对象设计”是这些可以满足“应对转移,提升复用”的筹划。{“源代码就是统筹”,“好的情势是透过不停的重构”}

面向对象设计形式描述的是软件设计,由此它是单独于编程语言的,不过面向对象设计情势的结尾落实仍旧要接纳面向对象编程语言来发挥,本课程基于C#言语,但骨子里它适用于援助.NET框架的所有.NET语言,如Visual
Basic.NET、C++/CLI等。

面向对象设计形式不像算法技巧,可以照搬照用,它是成立在对“面向对象”熟稔、深入的接头的根底上的经验性认识。精晓面向对象设计形式的前提是首先领会“面向对象”!

 

基本功:从编程语言直观领会面向对象
{至少在语言层领悟面向对象,实现层领相会向对象}

各个面向对象编程语言相互区分,但都能看出它们对面向对象三大机制的支撑,即:
“封装、继承、多态”
    – 封装,隐藏其间贯彻
    – 继承,复用现有代码
    – 多态,改写对象行为

使用面向对象编程语言(如C#),可以促进程序员以面向对象的思想来思考软件设计结构,从而加剧面向对象的编程范式。

C#是一门援助面向对象编程的不错语言,包括:各个级其余包装援助;单实现连续+多接口实现;抽象方法与虚方法重写。

 

但OOPL并非面向对象的方方面面
{应用面向对象的语言与使用面向对象设计模式是多少个完全不同的情事,明白面向对象语言不可能证实您左右面向设计形式}

通过面向对象编程语言(OOPL)认识到的面向对象,并不是面向对象的整整,甚至只是浅尝辄止的面向对象。
• OOPL的三大机制“封装、继承、多态”
可以发挥面向对象的兼具概念,但这三大机制自我并没有刻画出面向对象的中央精神。换言之,既可以用这三大机制做出“好的面向对象设计”,也足以用这三大机制做出“差的面向对象设计”。不是运用了面向对象的语言(例如C#),就落实了面向对象的计划与开支!因而我们不可以依靠编程语言的面向对象机制,来控制面向对象。

OOPL没有回答面向对象的根本性问题——大家为啥要利用面向对象?大家应该咋样使用三大机制来兑现“好的面向对象”?
我们理应遵照什么的面向对象原则?

任何一个严肃的面向对象程序员(例如C#程序员),都需要系统地学习面向对象的学问,单纯从编程语言上获取的面向对象知识,不可能胜任面向对象设计与开支。

 

从一个演示谈起{什么样的宏图才是面向设计目的设计}
我们需要统筹一个人事管理系统,其中的一个效用是对各类不同品类的职工,总括其当月的薪资——不同品种的员工,拥有不同的薪金总结制度
演示场景:(1)结构化做法(pasical\C)
1。拿到人事系统中装有可能的职工类型
2。按照不同的职工类型所对应的不等的薪饷制度,统计其工资
enumEmployeeType{Engineer;Sales;Manager;…}
// 统计工资程序
If ( type==EmployeeType.Engineer) {……}
else if (type== Employeetype.Sales) {……}

 

示范场景:(2)面向对象设计
1。按照不同的职工类型设计不同的类,并使这个类继承自一个Employee抽象类,其中有一个虚无方法GetSalary。
2。在一一不同的职工类中,按照自己的薪饷制度,重写(override)GetSalary方法。
abstract class Employee{

public abstract intGetSalary();
}
class Engineer: Employee{

public override intGetSalary() {
……
}
}
class Sales: Employee{

public override intGetSalary() {
……
}
}
// 显示工资程序
Employee e=emFactory.GetEmployee(id);
MessageBox.Show( e.GetSalary());

当今需求变动了{}……
乘胜客户公司工作范围的开展,又冒出了更多品类的员工,比如钟点工、计件工……等等,这对人事管理系统提议了挑衅——原有的顺序必须改变。
演示场景:(1)结构化做法
几乎拥有涉嫌到员工类型的地点(当然包括“总计工资程序”)都急需做变更……这么些代码都亟待再行编译,重新部署…….
(2)面向对象做法
只需要在新的文书里增加新的员工类,让其继续自Employee抽象类,一视同仁写GetSalary()方法,然后在EmployeeFactory.GetEmployee方法中依据有关标准,暴发新的职工类型就可以了。其他地点(展现工资程序、Engineer类、Sales类等)则不需要做此外变动。

 

重新认识面向对象

对于眼前的例证,从微观层面来看,面向对象的构建情势更能适应软件的生成,能将转移所带动的影响减为最小

从微观层面来看,面向对象的法子更强调各连串的“责任”,新增员工类型不会影响原本员工类型的实现代码——这更合乎实际的社会风气,也更能操纵转变所影响的限制,毕竟Engineer类不应该为新增的“钟点工”来买单……
• 对象是何等?{不关心内部的环节}。
– 从概念层面讲,对象是某种拥有责任的空洞{}。
– 从原则层面讲,对象是一多元可以被其他对象使用的公共接口
– 从语言实现层面来看,对象封装了代码和多少{封装了作为和气象}。
• 有了这一个认识将来,如何才能设计“好的面向对象”?
– 坚守一定的面向对象设计条件
– 熟习一些非凡的面向对象设计情势

从规划基准到设计情势
• 针对接口编程,而不是指向落实编程–
客户无需通晓所使用对象的一定项目,只需要了然对象拥有客户所企盼的接口。
• 优先拔取对象组合,而不是类继承–
类继承平时为“白箱复用”,对象组合通常为“黑箱复用”。继承在某种程度上损坏了封装性,子类父类耦合度高;而目的组合则只要求被整合的对
象具有非凡定义的接口,耦合度低。
• 封装变化点

使用封装来创造对象之间的分界层,让设计者可以在分界层的边际举行修改,而不会对另一侧暴发不良的震慑,从而实现层次间的松耦合。

使用重构得到格局——设计情势的利用不宜先入为主,一上来就应用设计情势是对设计形式的最大误用。没有一步到位的设计形式。疾速软件开发实践提倡的“Refactoring
to Patterns
是眼下一周边公认的最好的采取设计格局的办法。{源代码就是设计}

 

几条更具体的计划性标准
• 单一任务规范(SRP):
– 一个类应该仅有一个滋生它生成的由来。
• 开放封闭原则(OCP):
– 类模块应该是可扩张的,不过不得修改(对扩张开放,对改变封闭)
• Liskov 替换原则(LSP):
子类必须可以替换它们的基类
• 依赖倒置原则(DIP):
– 高层模块不应当借助于低层模块,二者都应当依靠于肤浅。
– 抽象不应当依靠于实现细节,实现细节应该借助于肤浅。
接口隔离原则(ISP):
– 不应当强迫客户程序依赖于它们并非的法门。

讲座总计

设计情势描述了软件设计过程中某一类常见问题的普通的化解方案。面向对象设计格局描述了面向对象设计过程中、特定情景下、类与互动通信的对象之间常见的协会关系。

深远了解面向对象是学好设计形式的底子,精通一定的面向对象设计条件才能把握面向对象设计格局的精彩,从而实现灵活运用设计形式。
• 三大要旨面向对象设计条件
– 针对接口编程,而不是指向落实编程
– 优先采取对象组合,而不是类继承
– 封装变化点
• 使用重构得到格局。敏捷软件开发实践提倡的“Refactoring to
Patterns”是眼这周边公认的最好的施用设计格局的措施。

相关文章