MrK*_*ish 7 c++ oop abstraction interface header
作为一名初学程序员,刚刚学习了OOP的基础知识,我遇到了很多关于我的练习程序的基本包含结构的问题.我一直在教自己使用各种书面和在线资源进行编程.但是,这是我的问题(好吧,其中一个......):
一方面,我理解抽象,封装和类之间的低度耦合的重要性,但另一方面,我一直在努力构建我的程序并以允许不同的方式设计我的类在不同的文件中的类来了解彼此.
当然,这是我的一个主要问题,导致草率,hackish代码只能按照我想要的方式工作,我将每个基本的主要OOP抛出窗口并开始用全局变量填充我的代码,向前声明一切到处都是,让班级成员公开.
简单地说:我的编程很乱...... C++是我的第一个编程语言,即使我尽力以面向对象的方式设计/编写,我最终会得到一个丑陋的文件,#包括几乎所有的东西每个文件,以及很少有效的程序和OOP意大利面条代码的奇怪组合!
我是一个自称编程的新手,我接受学习如何构建一个程序需要时间,但我几乎要结束了!我知道我的问题源于我对OOP 有点了解的事实.我知道我想编写处理单个任务的独立类.但与此同时,我不明白如何正确地提醒每个类的程序其他部分的存在.这有点像知道你应该吃什么类型的食物,但不知道如何使用叉...
简而言之,这是我的问题.并进一步跟进我提出的一些更具体的问题:
在C++多文件项目中,将main()函数放在自己的类中是正常/需要的吗？或者将main()留在全局范围内是标准的事情吗？
在之前的程序性程序中,我用C++编写,在main.cpp文件的顶部,在全局作用域中有一个常量变量或#defines并不罕见.例如,可能在程序开始时定义屏幕的尺寸或其他有用信息.OOP会发生什么？是否完全避免了这种做法？或者我是否在项目的每个其他标题中创建MAIN.H文件并将其包含在内？我不知道该怎么办......
在编写我的第一个中等规模的练习OOP程序时,当我开始尝试编写StateMachine类时,我的工作开始戛然而止.我打算让StateMachine类包含程序将使用的所有可能的屏幕状态.但是,出现了一个问题,即我的StateMachine类似乎不知道我的其他一些State类,即使它们都是#included.我见过人们之前做过类的前进声明,是否有必要？我应该在整个地方垃圾邮件发送类的前向声明,还是代码味道？
最后,#include和forward声明命令的顺序是否重要？
我知道这可能是一个超级基本的问题,但是在我从单文件程序c ++初学者程序到多文件OOP编程的过渡中,这给我带来了很大的困难.是否有一些一般的经验法则来构建你的程序,以便一切正常？我一直在使用包含警卫,所以有什么理由不能只在每个源文件中包含#include每个头文件？我应该在每个类的每个头文件中都有#included的common.h文件吗？
我非常感谢社区给予我的任何帮助/建议.我知道在我开始发展我的OOP技能之前,这是一个简单而重要的障碍.我一直试图深入了解保持课程彼此分离的重要性,以至于我不确定如何以一种允许他们真正互相交流的方式真正设置我的课程/文件!非常感谢你的帮助!
您不能将 OOP 视为使用类的普通函数式编程。这是一种错误的做法，它会误导你。
设计应用程序的架构非常重要，有很多关于它的书籍。应用程序的结构设计得越好，编码就越容易，错误也就越少。学习一些建模语言的基础知识是一个很好的建议，可以让您更轻松地绘制和理解东西。UML 是一个不错的选择。
设计大型产品有两种方法。你可以下降，这意味着你从一个高抽象层次开始，然后下降，缩小你的问题范围。或者你可以提升，从实现容易做的小事情开始，然后向上，将你的小模块连接到应用程序中。
您可以轻松地在网络上找到大量相关信息。简而言之。现在，针对您的具体问题。
将 main 保留在全局范围内。就我个人而言，我什至将其保留在单独的main.cpp文件中以保持干净，但将其放在哪里并不重要。
尽量避免全局变量。如果您需要常量，定义它们就可以了。是的，您在单个头文件中使用所有定义的方法效果很好。但是，您可能希望按含义将它们分开，而不是将具有 10000 个定义的文件包含到只需要其中一个定义的 .cpp 中。
如果您需要在声明之前使用一个类，则必须前向声明它，否则编译器将不知道它的存在。
包含的顺序确实很重要，因为每个#include内容基本上都会复制粘贴相应文件的文本。因此，如果您#include在class.h中class.cpp，标题的文本将由预处理器复制粘贴到源文件中。前向声明的顺序并不重要，只要您在第一次使用它之前就前向声明它即可。