做出来一个类很容易,只要掌握基本的程序语法定义规则就可以做的出来,那么难点在那里呢?
一个项目要用到多少个类,用多少个对象,
在那要定义类,定义一个什么样的类,
这个类实例化出多少个对象,
类里面有多少个属性,有多少个方法等等,
这就需要读者通过在实际的开发中就实际问题分析设计和总结了。
设计模式描述了软件设计过程中某一类常见问题的一般性的解决方案。
面向对象设计模式描述了面向对象设计过程中、特定场景下、类与相互通信的对象之间常见的组织关系。
例子:我们需要设计一个人事管理系统,其中的一个功能是对各种不同类型的员工,计算其当月的工资——不同类型的员工,拥有不同的薪金计算制度。
(现在需求改变了……随着客户公司业务规模的拓展,又出现了更多类型的员工,比如钟点工、计件工……等等,这对人事管理系统提出了挑战——原有的程序必须改变。)
结构化设计方法:
1.获得人事系统中所有可能的员工类型
2.根据不同的员工类型所对应的不同的薪金制度,计算其工资
(几乎所有涉及到员工类型的地方(当然包括“计算工资程序”)都需要做改变……这些代码都需要重新编译,重新部署…….)
面向对象设计
1.根据不同的员工类型设计不同的类,并使这些类继承自一个Employee抽象类,其中有一个抽象方法GetSalary。
2.在各个不同的员工类中,根据自己的薪金制度,重写(override)GetSalary方法。
(只需要在新的文件里增添新的员工类,让其继承自Employee抽象类,并重写GetSalary()方法,然后在 EmployeeFactory.GetEmployee方法中根据相关条件,产生新的员工类型就可以了。其他地方(显示工资程序、Engineer类、 Sales类等)则不需要做任何改变。)
比较分析:从微观层面来看,面向对象的方式更强调各个类的“责任”,新增员工类型不会影响原来员工类型的实现代码——这更符合真实的世界,也更能控制变化所影响的范围,毕竟Engineer类不应该为新增的“钟点工”来买单……
怎样才能设计“好的面向对象”?
–-遵循一定的面向对象设计原则
--熟悉一些典型的面向对象设计模式
--针对接口编程,而不是针对实现编程
一个项目要用到多少个类,用多少个对象,
在那要定义类,定义一个什么样的类,
这个类实例化出多少个对象,
类里面有多少个属性,有多少个方法等等,
这就需要读者通过在实际的开发中就实际问题分析设计和总结了。
设计模式描述了软件设计过程中某一类常见问题的一般性的解决方案。
面向对象设计模式描述了面向对象设计过程中、特定场景下、类与相互通信的对象之间常见的组织关系。
例子:我们需要设计一个人事管理系统,其中的一个功能是对各种不同类型的员工,计算其当月的工资——不同类型的员工,拥有不同的薪金计算制度。
(现在需求改变了……随着客户公司业务规模的拓展,又出现了更多类型的员工,比如钟点工、计件工……等等,这对人事管理系统提出了挑战——原有的程序必须改变。)
结构化设计方法:
1.获得人事系统中所有可能的员工类型
2.根据不同的员工类型所对应的不同的薪金制度,计算其工资
(几乎所有涉及到员工类型的地方(当然包括“计算工资程序”)都需要做改变……这些代码都需要重新编译,重新部署…….)
面向对象设计
1.根据不同的员工类型设计不同的类,并使这些类继承自一个Employee抽象类,其中有一个抽象方法GetSalary。
2.在各个不同的员工类中,根据自己的薪金制度,重写(override)GetSalary方法。
(只需要在新的文件里增添新的员工类,让其继承自Employee抽象类,并重写GetSalary()方法,然后在 EmployeeFactory.GetEmployee方法中根据相关条件,产生新的员工类型就可以了。其他地方(显示工资程序、Engineer类、 Sales类等)则不需要做任何改变。)
比较分析:从微观层面来看,面向对象的方式更强调各个类的“责任”,新增员工类型不会影响原来员工类型的实现代码——这更符合真实的世界,也更能控制变化所影响的范围,毕竟Engineer类不应该为新增的“钟点工”来买单……
怎样才能设计“好的面向对象”?
–-遵循一定的面向对象设计原则
--熟悉一些典型的面向对象设计模式
--针对接口编程,而不是针对实现编程