避免从C移植到面向对象的陷阱，对您有用的是什么？

我已经使用过程语言进行编程已有一段时间了，我对问题的第一反应是开始将其分解为要执行的任务，而不是考虑存在的不同实体（对象）及其关系。

我在OOP上过一门大学课程，并且了解封装，数据抽象，多态性，模块化和继承的基础知识。

我阅读了/programming/2688910/learning-to-think-in-the-object-directional-way和/programming/1157847/learning-object-directional-thinking，并将查看这些答案中指出的一些书籍。

我认为我的一些中型到大型项目将受益于OOP的有效使用，但是作为一个新手，我想避免耗时的常见错误。

根据您的经验，这些陷阱是什么？解决这些陷阱的合理方法是什么？如果您能解释为什么它们是陷阱，以及您的建议如何有效解决该问题，将不胜感激。

我正在考虑类似“是否有大量观察者和修饰符方法并使用私有变量，或者是否有用于合并/简化它们的技术？”这样的思路。

如果有充分的理由混合使用方法，我不担心将C ++用作纯OO语言。（尽管有节制，但让人想起使用GOTO的原因。）

谢谢！

我学到的一大件事是从外部开始设计类。在开始考虑实现之前就设计接口。这将使该类对您的用户（使用类的用户）直观得多，而不是编写基础算法并构建类并根据需要编写新的公共成员函数。

首先，是暴露过多信息的陷阱。默认值应该private不是public。

在那之后出现了太多的获取/设定者。假设我有一个数据成员。我真的需要其他班级的数据吗？好吧，吸气。我真的真的需要在对象的使用期限内更改此数据吗？然后做一个二传手。

大多数新手程序员都默认为每个数据成员创建一个getter / setter方法。这会使界面混乱，通常是错误的设计选择。

当我越过鸿沟时，我决定采用以下方法：

0）我开始慢，只有中小型程序应用程序，并且没有关键任务工作。

1）一个简单的第1遍映射，即我将如何以OO样式从头开始编写程序-当时对我来说最重要，而且这是主观的-找出了所有基类。我的目标是在基类中尽可能地封装。纯虚拟方法可用于基类中的所有可能对象。

2）然后，下一步是创建派生类。

3）最后一步是-在原始过程代码中，将数据结构与观察者/修饰符代码分开。然后使用数据隐藏并将所有通用数据映射到基类中，在子类中包含整个程序中不通用的数据。对过程观察者/修饰符代码的处理相同-所有“遍地使用”的逻辑都进入了基类。仅对数据子集起作用的视图/修改逻辑进入派生类。

如果您非常了解过程代码和数据结构，这是主观的，但它是快速的。代码检查中的失败是指基类中没有出现一些数据或逻辑，而是在各处使用了数据或逻辑。

看看其他使用OOP获得良好风格感的成功项目。我建议您看一下Qt，这是我在制定自己的设计决策时总会期待的项目。

根据与您交谈的人的不同，OOP中的所有数据都应该是私有的或受保护的，并且只能通过访问器和更改器获得。总的来说，我认为这是一个很好的做法，但是在某些情况下我会偏离该规范。例如，如果您有一个类（比如说用Java），其唯一目的是将一些数据打包到一个逻辑单元中，那么将这些字段设为公开是有意义的。如果它是不可变的封装，只需将它们标记为final并在构造函数中对其进行初始化。这将类（在这种情况下）减少为一个结构（实际上，使用C ++，您实际上应该将其称为结构。工作原理类似于类，但是默认可见性是公共的，并且您的意图更清晰），但是我认为您会发现在这些情况下使用它要舒适得多。

您绝对不希望做的一件事是必须在增变器中检查一个字段的一致性，并将其公开。

肯特·贝克（Kent Beck）的书《实现模式》是如何使用而非滥用面向对象机制的极佳基础。

如果有充分的理由混合使用方法，我不担心将C ++用作纯OO语言。（尽管有节制，但让人想起使用GOTO的原因。）

在我看到这一点之前，我真的没有想到我可以提供很多对话。我必须不同意这种看法。OOP只是可以在C ++中使用的范例之一。坦率地说，我认为这不是其最强大的功能之一。

从面向对象的角度来看，我认为C ++实际上有点不足。例如，在这方面，具有非虚拟功能的想法就是反对。我曾与那些不同意我的人争论过，但就我而言，非虚拟成员根本不适合该范式。多态是OO的关键组成部分，具有非虚函数的类在OO上不是多态的。因此，作为一种面向对象的语言，与Java或Objective-C之类的语言相比，我认为C ++实际上相当弱。

另一方面，在通用编程中，C ++相当不错。我听说它也提供了更好的语言，但是对象和泛型函数的结合是非常强大和富有表现力的。此外，它可以在编程时间和处理时间上都非常快。我认为C ++确实在这方面表现出色，尽管可以承认C ++可能更好（例如，对概念的语言支持）。有人认为他们应该坚持OO范式，并在goto语句的顺序上以不道德的程度对待其他人，因为他们根本没有考虑这种范式，这的确被遗漏了。

模板的元编程能力也非常出色。例如，查看Boost.Units库。该库为尺寸量提供类型支持。我在目前工作的工程公司中广泛使用了此库。它只是为可能的程序员甚至规范错误的一个方面提供了更多的即时反馈。如果不使用显式转换，则无法编译使用公式的程序，其中'='运算符的两边在维度上不相等。我个人没有使用任何其他可能实现这种语言的经验，当然也没有使用同样具有C ++功能和速度的语言。

元编程是一种纯粹的功能范例。

所以说真的，我认为您已经带着一些不幸的误解进入了C ++。除了OO之外，其他的范式也不能避免，它们应该被利用。对于正在处理的问题，请使用自然的范例。不要将对象强加于本质上不是对象容易发生的问题上。就我而言，OO甚至不是C ++的一半。

我想接受有关此问题的答案，但是我无法决定要使用复选标记的答案。因此，我投票反对原始作者，并将其创建为摘要答案。感谢所有花了几分钟的人，我发现您提供的见解为我提供了一个很好的指导，并让我放心，我并没有脱离轨道。

@nightcracker

首先，是暴露过多信息的陷阱。默认值应该是私有的，而不是公共的。在那之后出现了太多的获取/设定者。

我觉得我过去曾观察到这个问题。您的评论使我还记得，通过隐藏基础变量及其实现，我可以自由更改其实现，而不会破坏任何依赖于它们的内容。

多米尼克·古尔托（Dominic Gurto）

在开始考虑实现之前就设计接口。Gene Bushuyev接口的设计和实现通常在连续的迭代过程中齐头并进，直到最终的接口明确为止。

我认为多米尼克的评论是一个理想的理想，但我认为吉恩的评论确实触及了现实。到目前为止，我已经在实践中看到了这一点……并感觉好一点，这并不罕见。我认为，随着我成为一名程序员的成熟，我会倾向于更完整的设计，但是现在我仍然受苦于编写一些代码。

想要最好的

我开始慢，只有中小型程序应用程序，并且没有关键任务工作。在原始过程代码中，将数据结构与上位/修饰符代码分开

这很有道理...我喜欢让事情一直在工作的想法，但是可以通过类重构一些非关键的东西。

下午

您绝对不想做的一件事是必须在增变器中检查一个字段的一致性，并将其保留为公开

我已经知道一段时间了，这是封装数据的优势之一...能够强制保持一致性，并且对于这种情况，条件/范围/等等。

疯狂的埃迪

有人认为他们应该坚持OO范式，并在goto语句的顺序上以不道德的程度对待其他人，这是因为他们不看这种范式而错过了。模板的元编程能力也非常出色。

我最初在Crazy Eddie的答案中错过了很多东西，我想是因为我没有读过其中提到的某些主题……例如元编程。我认为CE帖子中的重要信息是C ++是功能和样式的融合，因此每种功能和样式都应发挥最大的潜能...包括当务之急。

再次感谢所有回应！

最大的陷阱是认为OOP是灵丹妙药，或者是“一个完美的范例”。