如何从坏到好的OOP设计？

Question

我正在阅读有关OOP设计中的好坏实践的很多内容.很高兴知道你的设计很糟糕或很好.但是你如何从糟糕到好的设计？我已经从主businesslogic类拆分了接口(xaml)和codebehind.最后一堂课正在变得越来越大.我已经尝试将它分成更小的类,但我现在卡住了.关于如何拆分大班的任何想法？主类有1个不同类型的数据列表.我正在计算总数,但也计算个别类型.我有方法来执行这些计算,这些计算是从代码隐藏中处理的事件中调用的.任何想法从哪里开始？

附加信息:

我们已经进入这个项目大约6个月了.我已经使用面向对象的语言多年(第一个c ++,java和现在的c#),但从来没有像这样的大型项目.我相信我们在开始时做了一些错误的转变,我认为我们需要纠正这些.我目前无法详细说明该项目的任何细节.我打算订一两本关于设计的书.如果我将所有课程分开,我该如何将它们重新组合在一起？也许更好的是继续这种方式到第一个版本并在那之后重建部分,第二个版本？

Answer 1

练习和阅读.重复:)

一些推荐书籍:

• 罗伯特C马丁的清洁代码
• GoF设计模式
• 由Martin Fowler重构

就个人而言,我也喜欢Head First Design Patterns,但风格可能不适合所有人.还有一本名为C#3.0 Design Patterns的书(见ora.com).它有很多相同的东西,但是以更传统的方式.

Answer 2

主类有 1 个不同类型的数据列表。我不仅对总数进行计算，而且对各个类型进行计算。我有执行这些计算的方法，这些计算是从代码隐藏中处理的事件中调用的。有什么想法从这里去哪里吗？

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

在对不同类型执行类似但不同的操作方面，请考虑使用状态模式（将其视为 switch 语句的替代），它使您能够以统一的方式处理实体。

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