如何在 c++ 中构建应用程序模块化地

发布于 2024-10-01 05:45:26 字数 595 浏览 1 评论 0原文

这是一个关于如何构建 C++ 应用程序的问题,而不是关于 C++ 本身的问题

我正在构建一个被设想为图形应用程序的应用程序,但实现的细节需要很大的了解处理抽象功能以方便界面,例如从文件、Web 资源等中读取对象列表。我已经想出了如何毫无困难地实现此功能,但我没有很好的方法来测试它。具体来说,我已经开始实现图形环境,但尚未准备好使用较低级别的功能。

我还构建了很多我想要下层做的事情,但它尚未经过测试。所有这些代码都驻留在一个文件夹中,并存储在定期提交的版本控制系统中。

对于用 C++ 编写任何功能,我还比较陌生,到目前为止,我只从事过类项目,但我已经用 PHP 编写了大量各种类型的程序。

如果这是一个 PHP 项目,那么测试任何功能似乎都很简单:

  1. 我只需以交互方式实现它开始,
  2. 将其编码到一个小文件中
  3. ,编写一些使用该功能的代码,
  4. 将其构建到一个函数中,
  5. 将该函数导入到我的更大文件中。代码体。

对于 C++ 来说,这似乎是一种非常尴尬的方法。我是否把这一切都倒过来了,你如何解决编译程序中的小孤立问题并将它们导入到你的项目中?有没有您认为有帮助的工作流程。

This is a question more about how to build a c++ application than it is about c++, per se

I'm building an application that was envisioned as a Graphical application, but the specifics of the implementation require a great deal of abstract functionality to facilitate the interface, such as reading lists of objects from files, web resources, etc. I have figured out how to implement this functionality without much difficulty, but I have no good way to test it. Specifically, I've begun the implementation of the graphical environment, but it is not yet ready to work with the lower-level functionality.

I have also built a good deal of what I want the lower layer to do, but it is as-yet untested. all of this code resides in a single folder and is stored in a version control system with regular commits.

I'm relatively new to writing anything functional in C++ having only worked on class projects up to this point, but I have written a good number of programs, of various types, in PHP.

If this were a PHP project, it seems it would be simple to test any functionality:

  1. I would simply begin by implementing it interactively
  2. codify it into a small file
  3. write some code that used the functionality
  4. build it into a function
  5. import that function into my larger body of code.

This seems like a really awkward way to do the same with C++. Have I got it all backwards, how do you solve small isolated problems, in your compiled programs and import them into your projects; is there a workflow that you find helpful.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

稚然 2024-10-08 05:45:26

一般来说,您问题的答案是使用类和单元测试。在互联网上搜索敏捷/极限编程。

这个想法是这样的:

  1. 完成所有敏捷故事的内容(我会让您自己阅读)
  2. 您将设计分解为类
  3. 编写单元测试来定义类的“规范”
  4. 编写空占位符函数。
  5. 查看单元测试失败。
  6. 编写代码直到单元测试成功。
  7. 返回步骤 3,并对其余课程重复此操作。

如果您以这种方式编写代码,您将创建可重用且健壮的代码。

老实说,我个人并不相信真正的 TDD(测试驱动开发)——我觉得最好在编写代码后编写单元测试(我感觉到用户尖叫着“敏捷或死亡”即将到来的厄运之火) !”)。

编辑:如果您的问题更多的是关于多个类的实际构建的谎言,那么这很简单。一般来说,每个类都应该封装在2个文件中(源代码和头文件)。只需将这些文件(以及您想要使用的所有其他类的文件)包含在新项目中即可。 #include "xxx.h" 在您需要使用这些类的适当位置,编写使用这些类的代码,然后构建。就是这样。

Generally speaking, the answer to your question is using classes and unit testing. Do an internet search for Agile / Extreme Programming.

The idea is this:

  1. Do all the agile story stuff (I'll let you read about this on your own)
  2. You break out your design into classes
  3. Write unit tests that define the "spec" for your class
  4. Write empty placeholder functions.
  5. See the unit tests fail.
  6. Write code until the unit tests succeed.
  7. Go back to step 3 and repeat for the rest of your classes.

If you write code in this manner, you create reusable and robust code.

Honestly, I don't personally believe in TRUE TDD (test driven development) -- I feel it's better to write your unit tests after you've written your code (I feel the impending flame of doom coming from users screaming "AGILE OR DIE!").

EDIT: If your question is more along the lies of the actual BUILDING of multiple classes, well that's easy. Generally speaking, each of your classes should be encapsulated in 2 files (source code and header file). Just include those files (along with files from all other classes you want to use) in a new project. #include "xxx.h" in the appropriate places where you need to use the classes, write your code that uses those classes, and build. That's it.

戴着白色围巾的女孩 2024-10-08 05:45:26

我想这将是任何面向对象项目的通用策略。

首先确定主要组件,并确保您对所有组件的职责有非常透彻的了解。

写出每个组件的接口,并(逻辑上)检查它是否适合您的问题。

实现各个模块。

就测试而言,制作测试模块(存根):例如制作一个类,将输入发送到 GUI,模仿实际组件发送的输入。由于您对界面有清晰的了解,因此如何生成此结果将无关紧要。

对系统中的每个组件重复此过程,然后将它们组合在一起。

希望有帮助

I guess this would be the general tactic for any OO project.

First determine the main components and make sure you have a very thorough understanding of what everything is responsible for.

Write out the interface for each component, and check (logically) to see that it fits your problem.

Implement each module.

As far as testing is concerned make tester modules (stubs): for example make a class that will send input to the GUI mimicking the input that would be sent by the actual component. Since you have a clear idea of the interface, how this result was produced would be irrelevant.

Repeat this process for each component in your system and then put them together.

Hope it helps

指尖上的星空 2024-10-08 05:45:26

我目前处于类似的情况,我已经实现了一些功能(通过一些 API 进行文件 I/O、工作的主要部分等)。因此,也许我的一些经验会有所帮助:

  • 如果您已经有一些代码,那么绘制您所拥有的图表可能会有所帮助。笔和纸,甚至更好的 UML 可以在这里提供帮助(顺便说一句,可以导入现有类的一个很好的 UML 工具是 Umbrello)。有时我会在最后一次提交后进行这种“设计检查”,它帮助我发现一些微妙的问题,特别是在设计阶段,我每天都在重构类;
  • 如果您已经为组件编写了代码,我认为您可以轻松地为每个组件制定一些要求,并根据这些要求创建一些测试(例如使用“UnitCPPLite”)。目前,我在主文件中进行了测试,并使用一些样板代码在应用程序中完成任何其他操作之前触发测试执行(尽管这仍然不是最佳的);
  • 最后,我会在 ComtriS 的建议中添加“包含防护”的想法(如果您尚未使用它们),以防止多次包含头文件。所以,在实践中,我通常会得到这样的结果:

src/CFoo.h:

// class 'CFoo': header file
#ifndef CFOO_H
#define CFOO_H

#include <only_what_you_need_in_declaration_interface>

class CFoo {
    private:
        // class data
    public:
        // constructors, destructors, getters, setters, etc.
        void doWork();
    };
#endif /* CFOO_H */

src/CFoo.cpp:

// class 'CFoo': implementation file
#include "CFoo.h"
#include <what_you_need_in_addition_for_internal_workings_of_methods>

// code for other methods...

void CFoo::doWork() {
    // work
}

希望它有帮助。

I am currently in a similar situation, where I have implemented bits-and-pieces of functionality (file I/O through some API, main parts of the work, etc.). So maybe some of my experiences would be helpful:

  • If you have some code already, it may help to draw a diagram of what you have. Pen-and-paper, or even better UML can help here (btw, a good UML tool which can import existing classes is Umbrello). Sometimes I do this kind of "design check" after the last commit, and it helped me to spot some subtle problems, especially in the design stages, where I was refactoring classes daily;
  • If you have written code for the components, I think you can easily formulate some requirements for each one, and from these you can create some tests (e.g. with 'UnitCPPLite'). Currently, I have the test in the main file, with some boilerplate code which triggers the test execution before anything else is done in the application (although this is still not optimal);
  • Finally, I would add to the recommendation of ComtriS the idea of "include guards" (if you don't use them already), to prevent multiple inclusion of the header files. So, in practice, I typically end-up with something like this:

src/CFoo.h:

// class 'CFoo': header file
#ifndef CFOO_H
#define CFOO_H

#include <only_what_you_need_in_declaration_interface>

class CFoo {
    private:
        // class data
    public:
        // constructors, destructors, getters, setters, etc.
        void doWork();
    };
#endif /* CFOO_H */

src/CFoo.cpp:

// class 'CFoo': implementation file
#include "CFoo.h"
#include <what_you_need_in_addition_for_internal_workings_of_methods>

// code for other methods...

void CFoo::doWork() {
    // work
}

Hope it helps.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文