如何打破我的程序编码习惯？

Question

最近，我读到了一篇关于OOP相关问题的有趣评论，其中一位用户反对创建"Manager“类：

在谈论类名时，请从词汇表中删除“管理器”这个词。这个类的名称应该描述它的目的。经理不过是垃圾场的另一个词。任何功能都适用于此。这个词是导致许多极其糟糕的设计的原因。

这个评论体现了我为成为一个好的面向对象的开发人员所做的努力。我在一个只有过程编码的组织里做了很长一段时间的过程代码。我们产生的相对较少的OO代码的主要策略似乎是将问题分解为易于识别为离散单元的类，然后将剩余的/广义的位放在"Manager“类中。

我如何打破我的程序习惯(比如Manager类)？大多数面向对象的文章/书籍等都使用了一些问题的例子，这些问题本身就很容易转化为对象组(例如Vehicle -> Car)，因此并没有为分解更复杂的系统提供太多的指导。

Answer 1

首先，我会停止假装程序代码是错误的。这是适合某些工作的工具。OO也是一些工作的合适工具。功能也是如此。每一种范式只是计算的不同观点，之所以存在，是因为它便于解决某些问题，而不是因为它是唯一正确的编程方法。原则上，这三种范式在数学上都是等价的，所以使用任何一种最好的映射到问题域。IMHO，如果使用多范式语言，如果不同的子问题最好由不同的世界观建模，那么在模块中混合范例甚至是可以的。

其次，我读了一些关于设计模式的文章。如果没有一些实际问题的例子，就很难理解OO，这对解决问题是有好处的。Head First Design Patterns是一个很好的读物，因为它回答了许多OO的“为什么”。

Answer 2

要想精通OO，需要多年的实践和学习，最好是有一位导师。记住，OO只是达到目的的一种手段。话虽如此，以下是一些对我有用的一般指导方针：

• 偏爱组合而不是继承。阅读并重读GoF书的第一章.
• 遵守德米特定律 (“告诉，不要问”)
• 尝试只使用继承来实现多态性。当您从另一个类扩展时，这样做的想法是您将通过对基类的引用来调用该类的行为。ALL基类的公共方法对于子类来说应该是有意义的。
• 别被模特儿挂了。建立一个工作的原型，为您的设计提供信息。
• 拥抱重构。阅读福勒书的前几章。

Answer 3

单一责任原则帮助我将对象分解为有意义的可管理类。

每个对象应该做一件事，并且做得很好，而不向需要使用它的其他对象公开它的内部工作方式。