走出程序化思维

Question

从大学计算机专业毕业后，我已经编程(作为一项工作)大约3-4个月了。

在大学里，我学过面向对象的编程，我觉得我很好地掌握了这一点，直到我开始解决真正的问题。

我似乎什么也做不了，只能想出解决方案的过程化代码--尽管我使用了类和基本的oop技术，但代码内部本质上是过程化的，我知道有更好的解决方案，但我似乎就是无法让模式等与我想要做的事情相匹配。

你需要多长时间/多长时间的练习才能真正开始使用oop技术进行正确的编程-而不是仅仅使用充满过程代码的类。

另外，对于如何能够正确地设计问题的解决方案，有什么建议吗？

Answer 1

我认为这需要大量的练习。

这里有些人说：是对现实世界的对象进行建模。但这也是他们在学校通常告诉你的，据我从操作员那里了解，这真的没有那么有帮助。

当我查看我的代码时，我发现它被各种完全没有真实世界表示的对象淹没了:数据库映射器，对象工厂，表达式构建器，等等。它们听起来可能像现实世界的对象，但它们实际上一点也不像。它们只是帮助我们管理整个程序复杂性的抽象。

我认为OOP的主要难点就是这一点。你不能只看你的问题域，例如处理汽车的问题域，然后说:我知道，我需要一个汽车类！即使您确实需要一个汽车类，这些知识也不能帮助您决定真正将什么放入其中。显然，您不能将处理汽车的所有十万个功能都放在一个类中。那么你是如何管理它的呢？如何将其切分？汽车类的职责应该是什么？谁也应该知道Car类呢？这些都是除了程序的作者之外没有人能真正回答的难题。即使是最有经验的人也很少会在第一时间回答所有的问题。

但是我想有一些好的OOP原则可以遵循。使对象之间的coupling尽可能低。沿着the law of demeter行驶。请记住，SOLID原则是很好的。但最重要的是:始终保持DRY。

另外：不要把自己限制在面向对象的方法上。学习函数式编程、正则表达式、编译器构造、汇编语言和尽可能多的不同高级语言-仅了解OOP不会使您成为一名优秀的程序员，但学习所有这些不同的方法和工具将使您能够从更多不同的角度看待OOP，从而更深入地理解OOP的真正含义。

Answer 2

程序设计客观上并不比面向对象设计差，但它是一个方便的工具。让OOP正常工作的核心方法是将您的程序视为对现实世界对象的交互进行建模，每个现实世界对象都由一个编程对象建模，而这些对象之间的每次交互都是一种方法。

但如果这还不足以让你开始工作，也许你需要的是更多的工具来工作。一个被广泛推荐的资源是GOF book，它非常详细地描述了许多构建程序的方法，重点是OOP。但是需要注意的是，要确保你应用的任何模式都很适合这个问题，因为如果你随意地应用它们，它会给你和你的同事带来无尽的头痛。

Answer 3

我似乎什么也做不了，只能想出解决方案的过程化代码--尽管我使用了类和基本的oop技术，但代码内部本质上是过程化的，我知道有更好的解决方案，但我似乎就是无法让模式等与我想要做的事情相匹配。

不要绝望，一开始这是很正常的。在处理它时要小心，确保您只应用模式来解决您在代码中看到的实际问题。代码应该很简单，你可能会有一个不需要任何高级技术的场景。无论你学到什么，都要记住，你想要的是引入简单的元素，这些元素确实会给你带来好处，而不会以一堆不必要的代码/模式结束。

要花多长时间/多长时间练习才能真正开始使用oop技术进行正确的编程-而不是仅仅使用充满过程代码的类。

这取决于你所说的正确的意思。你可能很早就学会了应用特定的方法，甚至实现了一些非常酷的东西，但imho要真正掌握它需要几年的时间。我只是认为有一些拼图需要很长时间才能真正理解。

另外，对于如何能够正确地设计问题的解决方案，有什么建议吗？

我强烈推荐阅读这两本“电子书”S.O.L.I.D. principles and 31 Days of Refactoring。SOLID在代码的设计方面非常好，特别是在敏捷环境中。重构方面的内容可以帮助您识别现有代码中的改进机会。