【问题标题】:Recommendations for how to do OOP design [closed]关于如何进行 OOP 设计的建议 [关闭]
【发布时间】:2010-09-19 20:27:10
【问题描述】:

我发现,每当我开始使用 Java/C# 编写应用程序时,一切开始都很好,但随着时间的推移,随着应用程序变得越来越复杂,它只会变得越来越复杂。我已经意识到我不太擅长设计和高级架构。我所有的类都变得相当强耦合,设计一点也不“优雅”。我在“低级”编程方面相当称职。也就是说,我可以在一个函数或一个类中完成任何事情,但是我的高级设计很弱,我真的很想改进它。有没有人提供一些有助于使我成为更好的软件工程师的技术、书籍等?

【问题讨论】:

  • 您可以通过重构问题来开始编写更好的代码的旅程,使其易于阅读。现在有很长的句子用逗号分隔。
  • 我没有问题理解这个问题。
  • 我也不是。但这是为了舒适。如果可以的话,我会把它分成两段。

标签: oop architecture


【解决方案1】:

我将从草绘我的设计开始。该草图可以是显示类之间关系的方框和箭头图,也可以是 UML(甚至可能是标准 UML)的变体。但我发现草图可以帮助我了解设计的好坏,甚至可以帮助我了解如何修复它。

我还会看一本关于设计模式的书。

【讨论】:

    【解决方案2】:

    书籍:

    • 代码完成,作者:Steve McConnel
    • 设计模式,作者 Gamma 等。等。

    【讨论】:

      【解决方案3】:

      编写一个大型项目,让它尽可能大地传播。然后研究如何改进代码。

      如果结构良好,单个大型例程也可能清晰易懂。

      关于好的设计没有一个好的答案。这实际上是程序员可以学到的有价值的东西之一。

      【讨论】:

        【解决方案4】:

        在开始之前尝试制作程序大纲和图表,并让其他人对其进行审查和批评。然后随着程序的增长,不断更新大纲和图表以包含新功能。让其他人对其进行审查和批评。最终,假设您从批评中学习,您将在设计程序方面变得更好。

        书籍和教程只能让您到目前为止。虽然您确实需要学习可用的工具和方法,但知识本身并不能帮助您。实践可以让您在设计方面做得更好,并且不时有一位导师指导您,向您展示如何更好地应用您从书中获得的一些知识。

        【讨论】:

          【解决方案5】:

          请务必阅读书籍,但如果您编写的代码最终会变得愚蠢,请不要感到难过。每个人都这样。问题是,你能重构你必须修复的东西吗?为了能够经常有效地做到这一点,您需要使用TDD 并编写大量单元测试。

          【讨论】:

            【解决方案6】:

            你可以毫不留情地重构来改进现有代码的设计。

            主要思想是,在某些时候代码确实有意义,当将新功能引入代码时,可能必须将某些功能或职责转移到另一个类,这很好。然后您停止开发新功能并开始重构您的代码。

            我建议你阅读:

            Refactoring by Martin Fowler

            【讨论】:

              【解决方案7】:

              我强烈建议您尝试测试驱动开发 (TDD)。您会发现,要使您的代码可测试,并且不需要不断地对测试进行返工,您将需要一个可靠的设计。您会发现,当您添加\更改\删除功能时,您更好的设计将需要对特定测试集进行非常小的更改。糟糕的设计会抹去大量的测试——因为你有紧密的耦合、负责多个关注点的对象等等……

              我发现我在 TDD 方面做得越好,我的架构就越好,最终结果也越好。

              请注意,TDD 需要真正的心理训练。您不应该期望您使用它 1-2 天并立即看到效果。你需要真的很想做,并且真的付出努力——否则你不会受益,而且很可能最终会讨厌它。

              HTH ...

              【讨论】:

                【解决方案8】:

                你可以做几件事

                1. 使用工具进行高级和 低级设计在你面前 真正开始编程。例如。 创建类 UML 图将 帮助你的大脑形象化 图表形式的解决方案,而不是 比代码形式。

                2. 熟悉 Java 设计模式。例如。使用 多态继承开始 with 会让你热身开始使用 标准的 Java 和 J2EE 设计 模式。

                有大量的书籍和网站与我刚刚在此处指出的这两个主题有关。

                【讨论】:

                  【解决方案9】:

                  【讨论】:

                    【解决方案10】:

                    浏览良好的 API 代码。例如 Spring 框架代码。 阅读一些好书,例如设计模式(就像这里提到的其他人一样)和其他一些关于良好实践的书籍。例如在 Java、Head First Design、Effective Java 系列等。 C++ - 有效的 C++ 系列

                    【讨论】:

                      【解决方案11】:

                      显然,阅读一些推荐的书籍会有所帮助。我认为Head First Design Patterns 绝对没有 GoF 书那么抽象。

                      我要问的主要问题是“这段代码是否做了一些非常具体的事情,可以在其他地方重复使用?”如果是这样,请在允许重用的程序集中放入一个类。

                      如果您真的刚刚开始,那么我曾经做的一件事就是将每个数据库表视为一个“对象”。所以每个数据库表代表一个类。纯粹主义者会告诉你这是一场灾难,但我发现这是让自己开始从对象角度思考的好方法。

                      【讨论】:

                        【解决方案12】:

                        我不同意从一本关于设计模式或重构的书入手。

                        在我看来,对于一个可靠的 OO 设计,您应该首先熟悉主要的 OO 设计原则,然后了解您的问题如何在这些基本原则中表示。然后,您可以开始发现应用设计模式和重构技术的机会,以实现这些基本原则。

                        我将从这本书开始:

                        Agile Software Development, Principles, Patterns, and Practices 罗伯特·C·马丁

                        在本书中,Robert Martin 描述了做出良好 OO 设计的fundamental principles,所有这些都与封装、耦合和模块化有关:

                        • 开放/封闭原则
                        • 里斯科夫换人
                        • 依赖倒置
                        • 粒度
                        • 通用闭包
                        • 重用
                        • 无循环依赖
                        • 依赖的稳定性
                        • 抽象和稳定性

                        毕竟,我在 GoF 和 Fowler 中看到的几乎所有设计模式和重构技术都旨在实现这些基本原则中的一个,具体取决于它们在给定场景中的相对优先级。

                        【讨论】:

                          【解决方案13】:

                          【讨论】:

                            【解决方案14】:

                            【讨论】:

                              猜你喜欢
                              • 2021-03-01
                              • 2015-07-11
                              • 1970-01-01
                              • 2021-11-02
                              • 2021-04-26
                              • 2016-06-16
                              • 1970-01-01
                              • 2013-12-12
                              • 1970-01-01
                              相关资源
                              最近更新 更多