Head.First.Object-Oriented.Design.and.Analysis《深入浅出面向对象的分析与设计》读书笔记(六)
2010-07-26 07:18 Virus-BeautyCode 阅读(2085) 评论(3) 编辑 收藏 举报
好的设计产生灵活的软件-下(good design = flexible software part 2)
------------give your software a 30-minute workout
引言 |
如果你在对应用进行修改的时候发现问题,很有可能说明你的软件需要更加灵活和富有弹性。你需要做更多的分析,整体的设计,学习可以使系统更加松耦合的OO原则。在最后,你将会看到提高内聚性如何帮助你解耦。
正文 |
让我们再看一下前面的乐器销售例子,我们将在上面使用OO原则,使得它更加灵活。
在上面图中可以看到,有三个地方需要改进:
-
addinstrument方法,如果有新乐器类型需要添加的话,这个方法要修改代码,因为乐器的type判断的if代码需要添加一个判断。
-
对每一个乐器类型都有一个search方法。以后如果增加乐器类型,还需要打开inventory的代码进行增加search方法,不是一个好的解决方式。
-
每个乐器子类都只有一个构造函数,用于设定乐器类型,没有其他行为
造成这两个问题都是由于我们再方法里面针对实现编程,而没有针对接口编程。
search方法可以进行如下的修改

public List<Instrument> Search(InstrumentSpec searchSpec)
{
List<Instrument> instances = _inventory .FindAll(i => i.Spec.Matches(searchSpec));
return instances;
}
{
List<Instrument> instances = _inventory .FindAll(i => i.Spec.Matches(searchSpec));
return instances;
}
我们创建子类的主要原因是子类的行为有别于父类?但是我们目前的乐器子类和父类有不同的行为吗?他们没有不同的行为,但是还有有两个原因来解释我们为什么需要乐器子类。
- 因为instrument只是一个乐器的抽象概念,不是具体的乐器,因此instrument应该是abstract。因为我们需要乐器子类。
- 每个乐器的属性是不一样的,spec是不一样的,所以需要通过构造函数来赋值。
一个设计的死亡
最困难的一件事就是否定自己的设计。
设计是一个迭代的过程,不要害怕检查自己的设计决定,如果有问题,一定要改进它。虽然改进需要一定时间,但是在软件开发的长期看来,是值得的,会给后期的开发和维护节约很多时间。
结论 |
分析与设计
- 设计良好的软件应该很容易修改和扩展。
- 使用基本的OO原则,例如:封装和继承,使得你的软件更加灵活。
- 如果一个设计不灵活,马上改进它。不要停留在一个不好的设计,即使这个不好的设计还没有到不得不修改的地位。
- 保持每个类的内聚性,每个类应该集中做一个事情。
- 在软件的生命周期中,尽量最求更高的内聚性。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
· 基于Microsoft.Extensions.AI核心库实现RAG应用
· Linux系列:如何用heaptrack跟踪.NET程序的非托管内存泄露
· TypeScript + Deepseek 打造卜卦网站:技术与玄学的结合
· 阿里巴巴 QwQ-32B真的超越了 DeepSeek R-1吗?
· 【译】Visual Studio 中新的强大生产力特性
· 10年+ .NET Coder 心语 ── 封装的思维:从隐藏、稳定开始理解其本质意义
· 【设计模式】告别冗长if-else语句:使用策略模式优化代码结构