走出程序化的思维模式

Joh*_*ohn 9 oop design-patterns

从大学毕业后开始学习计算,我已经编程(作为一份工作)大约3-4个月了.

在大学时,我被教授面向对象的编程,我觉得自己很好地掌握了这一点,直到我开始研究真正的问题.

我似乎无法做任何事情,但提出解决方案的程序代码 - 虽然我使用类和基本的oop技术,代码基本上是程序性的内部,我知道有更好的解决方案,但我似乎无法匹配模式等等与什么我想做.

在使用oop技术真正开始编程之前需要多长时间/多次练习 - 而不是仅使用填充过程代码的类.

另外,对于如何正确地设计解决问题的方法,有什么建议吗?

Ren*_*soo 11

我认为这需要很多练习.

这里的一些人说: OOP正在为现实世界的物体建模.但这也是他们在学校通常告诉你的,正如我从OP中所理解的那样,它确实没那么有用.

当我看到我的代码时,我发现它已经被各种绝对没有现实世界表示的对象所淹没:数据库映射器,对象工厂,表达式构建器等.它们可能听起来像真实世界的对象,但它们实际上并不像.它们只是抽象,可以帮助我们管理整个程序的复杂性.

我认为OOP的主要难点就在于此.你不能只看你的问题领域,例如处理汽车并说:我知道,我需要一个汽车课!即使你确实需要一个Car类,这些知识也无法帮助你决定在里面放什么.显然,你不能只把所有涉及汽车的十万个功能放在一个类中.那么你如何管理呢?如何切片?汽车课应该承担什么责任?谁也应该了解汽车类?这些是难以解决的问题,除了程序的作者本人之外,没有人可以真正回答这些问题.即使是经验最丰富的人也很少在第一时间回答所有问题.

但我想有一些一般的好的OOP原则可以遵循.保持对象之间的耦合尽可能低.遵循得墨忒耳定律.该SOLID原则是好记在心上.但最重要的是:保持干燥.

另外:不要局限于面向对象的方法.研究函数式编程,正则表达式,编译器构造,汇编语言以及尽可能多的不同高级语言 - 单独了解OOP并不能使您成为一名优秀的程序员,但研究所有这些不同的方法和工具将允许你可以从更加截然不同的角度看待OOP,让我们更深入地了解这个OOP的真正含义.


Sin*_*ion 4

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

但如果这还不足以让您顺利开展工作,也许您需要更多可用的工具。广受推荐的来源是GOF 书,它详细描述了构建程序的多种方法,重点是 OOP。不过,请注意,请确保您应用的任何模式都非常适合该问题,因为如果您随意应用它们,将会给您和您的同事带来无尽的麻烦。