C++ 如何正确构造OOP和多文件项目？

作为一名初学者程序员，我刚刚学习了OOP的基础知识，在实践程序的基本包含结构方面遇到了许多问题。我一直在使用各种书面和在线资源自学编程。但是，我的问题是（嗯，其中一个…）：

一方面，我理解抽象、封装和类之间的低耦合度的重要性，但另一方面，我一直在以允许不同文件中的不同类相互了解的方式构建我的程序和设计我的类

当然，这是我的一个主要问题，它导致了草率的、黑客式的代码，只有在我将每个基本的主体OOP抛出窗口并开始用全局变量填充代码、转发所有地方的声明以及公开类成员之后，代码才会按照我希望的方式工作

简单地说：我的编程一团糟。。。C++是我的第一个编程语言，即使我尽我所能设计/写一个面向对象的方法，我最终会得到一个丑陋的文件，包括几乎所有文件中的所有东西，以及一个程序和OOP意大利面代码的奇怪组合，很少能工作。p> 我自称是一名编程新手，我承认学习如何构造程序需要时间，但我几乎智穷了！我知道我的问题源于我对OOP有一点了解。我知道我想编写独立的类来处理单个任务。但同时，我不明白如何正确地提醒每个类程序的其他部分的存在。这有点像知道你应该吃什么样的食物，但不知道如何使用叉子

简而言之，这是我的问题。为了进一步跟进我提出的一些更具体的问题：

在C++多文件项目中，将主（）函数放在它自己的类中是正常的/需要的吗？或者将main（）留在全局范围内是标准做法吗
>P>以前在C++编写的过程程序，在Meal.CPP文件的顶部，在全局范围内定义常量变量或γ定义并不少见。例如，屏幕尺寸或其他有用信息可能会在程序开始时定义。OOP中会发生什么？是否完全避免这种做法？还是制作一个MAIN.H文件，并将其包含在项目中的每个其他头中？我不知道该怎么办
• 在编写我的第一个中型实践OOP程序时，当我开始尝试编写StateMachine类时，我的工作突然停止。我的意图是让StateMachine类包含程序将使用的所有可能的屏幕状态。然而，出现了一个问题，我的StateMachine类似乎不知道我的其他一些State类，尽管它们都包含在内。我以前见过有人做过类的转发声明，有必要吗？我应该到处乱发类的转发声明，还是这是一种代码味道

• 最后，#include和forward声明命令的顺序是否重要

我知道这可能是一个超级基本的问题，但这是我从一个文件程序C++初学者程序到多文件OOP编程的过渡过程中的一个非常困难的时期。是否有一些一般的经验法则来组织你的程序，使一切都正常工作？我一直在使用include-guard，那么有什么理由不能在每个源文件中包含每个头文件？我应该在每个类的每个头文件中包含一个公共的.h文件吗

---

我非常感谢社区能给我的任何帮助/建议。我知道在我开始发展OOP技能之前，这是一个简单但重要的障碍。我一直在努力向我的大脑中钻研保持类彼此独立的重要性，以至于我不确定如何真正设置类/文件，使它们能够真正相互交互！非常感谢你的帮助

好的。。。因此，主要的问题似乎是保持文件的OO组织。 首先也是最重要的是，如果你还没有读过这本书，我会强烈建议你这样做。我还发现前面的答案相当清楚和简单

---

我希望这有助于

您不要将OOP视为带类的普通函数式编程。这是一个错误的方法，它会误导你

设计应用程序的体系结构是非常重要的，有很多关于它的书籍。你的应用程序结构设计得越好，编码就越容易，错误也就越少。这是一个很好的建议，学习一些建模语言的基础知识，让你更容易地绘制和理解东西。UML是一个很好的选择

设计大型产品有两种方法。你可以下降，这意味着你从一个高层次的抽象开始，然后下降，缩小你的问题范围。或者你可以提升，从实现简单易做的小事情开始，然后再提升，将一个或多个小模块连接到一个应用程序中

你可以很容易地在网上找到很多关于这方面的信息。简而言之。现在，请回答您的具体问题

将main保留在全局范围内。就我个人而言，我甚至把它放在一个单独的

main.cpp

文件中，以保持它的整洁，但放在哪里并不重要

尽量避免全局变量。如果需要常量，可以定义它们。是的，您在单个头文件中使用所有定义的方法效果很好。但是，您可能希望按含义将它们分开，而不是将包含10000个定义的文件包含到只需要其中一个定义的.cpp中

<