如何从糟糕的OOP设计走向良好的OOP设计?

练习和阅读。重复:)

一些推荐书:

• 罗伯特·C·马丁的干净代码
• Martin Fowler的重构

就我个人而言,我也喜欢Head-First设计模式,但这种风格可能并不适合所有人。有一本类似的书叫做C#3.0设计模式(见ora.com)。它有很多相同的东西,但以更传统的方式。

我强烈建议你去接电话 Code Complete . 这是一本很棒的书,它为你这样的问题提供了很多好的建议。

编辑:把这种想法也带到“方法”层面——让你的方法负责一件事,而且只负责一件事。帮助将大型(>50行)方法快速分解为可重用的代码块。

改变对对象的思考方式。每个对象都应该有一个非常具体的责任。如果您有一个名为泛型的类,比如“MainBusinessLogic”,那么您可能做错了什么。

伟大的起点:阅读大卫·韦斯特 .

主类有一个 不同类型。我在做什么 个人类型。我有办法 从中处理的事件调用 代码隐藏。有什么好主意吗 在这里

如果有大量基于列表内容的计算,您是否考虑过将操作移动到自定义列表类中?对特定类型的操作也是如此,也许它们可以存在于类型内部?

state pattern (将其视为switch语句的替换),它使您能够以统一的方式处理实体。

很多OOP都是关于抛弃“自上而下”/“微观管理”的方法,而考虑“自下而上”/“自给自足”的方法。值得记住的是,这两种方法都不是孤立的“正确”。创建可维护的代码是为了找到一个合理的平衡,这需要大量的思考,通常是通过经验来开发的。

我在OO方面做得越好,我似乎越能减小对象的大小。这不像是我想要的小物体大小或任何东西,但它似乎正在发生。

保持它们的小型化、单一责任、易于使用和理解——所有这些都至关重要。每个对象都应该尽可能的防弹,检查您的参数,决不允许对象进入无效状态。在文档中明确定义所有有效状态。

在编码方面,我几乎所有的时间都花在试图弄清楚别人做了什么上。如果我能够使用已知的或有良好文档记录的API发布代码,我的工作将变得微不足道,日程安排也将大大缩短。

首先设计可能很难。考虑编码能力与运动能力相似。我们大多数人在车道上比赛,少数人在当地的运动队比赛。在一个复杂的项目上做好前期设计是一个国家联盟球员的任务,他们是百万分之一。接受这一点并计划改变——迭代是你的朋友。(顺便说一句,我们中的大多数人认为我们很容易达到州一级,但事实并非如此)。

除了Brian建议的 罗伯特·C·马丁的干净代码 ,你可能想读一读“鲍勃叔叔的” SOLID Principles of Object Oriented Design .

Hanselminutes Podcast 145 和干净的代码 .NET Rocks! Show #388 . 他身上还有更多的东西 .NET Rocks! Show #410 ,但他所说的与你的问题并没有真正的关系,我只是把它包括在内,以防你喜欢前两个问题。

在三个播客中,我更喜欢Hanselminutes。

Refactoring

Design Patterns 工作原理与算法类似,但告诉您如何组合对象以执行各种有用的任务。

最后 Martin Fowler 具有多种实用的应用程序设计模式。例如 Passive View

迈克尔·费瑟斯 "Working Effectively with Legacy Code" 应该很好,但我承认我自己没读过。

同样的道理也适用于“ Refactoring to Patterns.

我发现在没有帮助的情况下完成一项复杂的“任务”,然后看看别人是如何完成的,这对我来说是一次很好的学习经历。

一项特别的任务是创建一个类似银行的程序,在这个程序中,我们必须跟踪交易,并能够计算利息收入等。这真的是我的第一个OOP程序,由于它的复杂性,这是一个非常棒的程序。对于初学者来说,用线性的方式去做而不出错会让人非常困惑。

我只能说什么对我有效,我还没有找到任何人能用同样的方式工作,所以我不确定这是否会对你有很大帮助。

基本上,我的方法是尽可能少的类,但不能少。

第三,信息的变化频率如何?如果某些信息的更改非常罕见,则可以使用部分求值(即代码生成)。也就是说,您获取不经常更改的信息,并使用它生成一个临时程序,该程序将执行您的整个程序对该信息的处理,但速度要快得多。代码生成器很容易编写,因为它只处理部分输入信息,即变化缓慢的部分。

我现在看到的很多数据结构都是为了支持UI而存在的。这显然不是在保存用户关心的对象,理想情况下,您也不必关心这些对象。所以我为UI构建了一个DSL,它隐藏了所有的胡说。

因此,当我看到人们都沉浸在类等技术中时,通常是因为他们对数据结构做了太多的处理。

只是我的下一票诱饵。。。

我推荐羽毛的 修改代码的艺术 ,可于 Safari 结束 Refactoring . 它充满了有用和感同身受的章节,比如 和

要考虑的观点:

1. 自动化设计质量测试-寻找提供设计质量指标的工具,作为设计决策的交叉检查。
2. 代码可测试性——您的重构是否有助于或阻碍测试驱动开发、编写单元测试或编写功能测试?一旦集成,测试大型体系结构块会有多困难?
3. 理由-你如何为这些决策辩护,从愤世嫉俗的CYA到管理层,更重要的是,让你的团队相信重新设计。你能简单而连贯地解释吗 做出了改变,6个月后会很容易找到解释吗?

设计中的个人偏好,尤其是重构:

1. 概念类 -当有疑问时,如果有一个清晰的概念,应该将其包装在类中,而不是隐含在一个或多个方法中作为行为。
2. 很多小事情都是有责任的 Responsibility-Driven-Design 写下每个班级职责的方法。如果您觉得这很难,那么您对每个类所做的事情的概念可能会混乱,或者他们做得太多。

尝试编写更多的可测试代码,这本身就迫使我研究和实现改进的OOP实践/设计概念。