您如何获得OOP设计的良好实践?[关闭]


12

我意识到我很难创建OOP设计。我花了很多时间来确定此属性是否正确设置为X类。

例如,这是一个有几天的帖子:https : //codereview.stackexchange.com/questions/8041/how-to-improve-my-factory-design

我不相信我的代码。因此,我想改善设计,减​​少设计时间。

您如何学习创建好的设计?您可以推荐我一些书吗?


您目前的水平是多少?我想您知道设计模式吗?
ACNB 2012年

一点也不,实际上,我开始在PluralSight课程中阅读其中的一些内容:pluralsight-training.net/microsoft/Courses/…–
Darf Zon

1
在软件设计中最有影响力的书籍之一是“设计模式:可重用的面向对象软件的元素”。尽管现在有点过时了,但仍然值得一读。您也可以开始阅读[ en.wikipedia.org/wiki/Software_design_pattern](维基百科文章)。这些软件设计模式不仅为您提供了针对常见问题的良好解决方案,而且还是目前专业术语的一部分。
ACNB 2012年

1.写-2.评论(包括阅读文献和P.SE等网站)-3.重构-4.重复
HorusKol 2012年

没有经验可以替代,这种知识也没有捷径

Answers:


14

设计系统是您只能通过做得更好的事情之一。当然,它对了解良好的设计确实有所帮助-推荐的一般的面向对象设计书是《四人帮的设计模式:可重用的面向对象软件的要素》。还有其他关于不同类型系统和不同领域的设计模式和原理的书。

也最好让其他人参与。创建设计后,向其他人介绍您要解决的问题和设计,以进行严格审查。听取他们的反馈并与他们进行对话,重点讨论您做出决定的原因。在实施解决方案时,您会在设计中发现其他问题。记下这些并向他们学习。与其他人一起检查设计和要求的实现也是一个好主意,并对您做事的原因进行严格的讨论。

尽管我通常发现最好与其他人面对面坐下,但是在此处可以与程序员讨论特定的设计问题。还有Stack Exchange网站,供您查看代码审查实施问题。


4

从您询问的codereview问题的外观来看,您正处于过度阶段。我认为在发现良好设计的重要性的人们中这是一个相当普遍的问题。

实际上,这是您掌握的任何技能的自然步骤,甚至可能是必要步骤。当您开始学习某些东西时,您对技能知识的了解越多,所运用的知识就越多,您的结果就越好,似乎您就直奔精通。问题在于,您的新目标不是结果的质量,而是您在技能上积累了多少知识。

真正掌握一项技能需要理解何时使用和何时不使用。过度使用该技能可能是发展这种理解的唯一方法。当然,您可以阅读有关此内容的内容,但是阅读并不能代替经验。

一方面,阅读设计模式是恕我直言的不好的开始。更好地了解OO设计原则,例如SOLIDGRASP。熟悉它们之后,研究常见的设计模式是一个好主意,因为您将看到如何将这些原理应用于形成具体的习惯用法。

据称,当一种语言的使用中出现模式时,该语言实际上就缺乏功能。尽管这一说法非常激进,但其中有很多道理。因此,我建议您查看并尝试其他语言,以更好地了解您要采用的概念,并学习新概念。入围名单包括Squeak,Ruby和Lisp。
至于List,我个人的建议是《计算机程序的结构和解释》,通过向我展示一个人如何毫不费力地创建复杂的问题的可靠解决方案,而在其中没有清晰的抽象和分解的知识,它教会了我很多有关设计的知识。自上而下的方式。

所以这是我的建议:

  1. 编写代码(并尝试了解造成这种情况的原因)
  2. 阅读代码(并尝试了解使它变得更好的原因)
  3. 与他人交流知识。测试您的想法。

这是极好的建议!我完全是在过度运用我的设计模式知识,正如我在这里
TheSilverBullet 2012年

3

正如其他人提到的那样,您只会在实践和经验上获得好处。您可以采取的捷径并不多。

与我们业内其他许多人相比,您回头看自己的东西而又不喜欢自己写的东西,这已经使您处于领先地位。在您尝试提高自己的水平时,我们其他人与会写500行函数的人员一起工作,这些函数具有20个参数,所有参数都是通过引用传递的,其中15个是[输入/输出],而这些人则认为它们是炸弹因为他们搞砸了。

当涉及软件设计时,它不是黑白的,无论设计是好是坏。无论您有多少经验,您都可以返回一些旧代码,然后思考:“编写此代码时我在吸烟吗?” 关键是对事物的不断评估,并经常进行思考练习,以评估使良好代码良好和不良代码不好的原因。

最后,尽管没有什么可以代替实践,但始终阅读博客/书籍/本站点始终是一个好主意,因为其他人会指出您可能未曾考虑过的不同观点。

首先,我会推荐这些书:

  • C#中的敏捷原理,模式和实践 -我本人在本书中排名 3/4。作者提出的主要观点之一,我100%同意,不要从寻找要应用的设计模式开始解决问题。如果替代方案开始变得更复杂,则应使事情尽可能简单,并将代码演变为模式。
  • Head First设计模式 -我没有读过这本书,在IMO中,很多Head First系列专门针对该领域的新手。因此,他们倾向于较为简单的一面,但我已经从其他人那里听到/读了很多关于该书的好评

1
+1:“将事情保持尽可能简单” ...“将代码演变为模式...”
kevin cline 2012年

1

前端设计永远不会比后端设计好。只是测试,编码和重构。当事情变得很丑陋时,您不确定如何清理它,然后看看是否有一些设计模式会有所帮助。练习一会儿,很快其他开发人员就会问您如何提出这样的简洁设计。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.