Как лучше организовать код в проектах C++

В настоящее время я пытаюсь организовать свой код лучше.

Для этого я использовал пространства имен, группируя классы по компонентам, каждый из которых имеет определенную роль и несколько интерфейсов (фактически абстрактные классы).

Я нашел, что это довольно хорошо, особенно когда мне пришлось переписать весь компонент, и я сделал это почти без влияния на другие. (Я думаю, что это было бы намного сложнее с кучей смешанных классов и методов)

И все же мне не 100 лет.% доволен этим. Особенно я хотел бы сделать лучшее разделение между интерфейсами, публичным лицом компонентов и их реализациями в behind. Я думаю, что "интерфейс" самого компонента должен быть более четким, я имею в виду, что новичок должен легко понять, какие интерфейсы он должен реализовать, какие интерфейсы он может использовать и что является частью реализации.

Скоро я начну более крупный проект, включающий до 5 разработчиков, и я хотел бы прояснить свой ум на этот счет.

Итак Что насчет тебя? как вы это делаете? как вы организуете свой код?

5 4
c++ namespaces

5 ответов:

Особенно я хотел бы сделать лучше. разделение между интерфейсами, публичное лицо компонентов, и их реализация в тылу.

Я думаю, что вы ищете фасад шаблон:

Фасад-это объект, который предоставляет упрощенный интерфейс для большого объема кода, такого как библиотека классов. -- Википедия

Вы также можете посмотреть на паттерны посредника и строителя, Если у вас есть сложные взаимодействия в ваших классах.

ИдиомаPimpl (aka compiler firewall) также полезна для сокрытия деталей реализации и сокращения времени сборки. Я предпочитаю использовать Pimpl над интерфейсными классами + фабриками, когда мне не нужен полиморфизм. Однако будьте осторожны, чтобы не злоупотреблять им. Не используйте Pimpl для легковесных типов, которые обычно выделяются в стеке (например, 3D-точка или комплексное число). Используйте его для больших, более долгоживущих классов, которые имеют зависимости от других классы / библиотеки, которые вы хотели бы скрыть от пользователя.

В крупномасштабных проектах важно не использовать директивы #include в заголовочном файле, когда достаточно простого прямого объявления. Только поместите директивы #include в заголовочный файл, если это абсолютно необходимо (предпочитайте помещать #includes в файлы реализации). Если все сделано правильно, правильная дисциплина #include значительно сократит время компиляции. Идиома Pimpl может помочь переместить #includes из заголовочных файлов в их соответствующие файлы реализации.

Связную коллекцию классов / функций можно сгруппировать в собственном пространстве имен и поместить в подкаталог дерева исходных текстов (этот подкаталог должен иметь то же имя, что и пространство имен библиотеки). Затем вы можете создать статический библиотечный подпроект / makefile для этого пакета и связать его с вашим основным приложением. Это то, что я бы назвал "пакетом" на языке UML. В идеальном пакете классы тесно связаны друг с другом, но слабо связано с классами вне пакета. Полезно нарисовать диаграммы зависимостей ваших пакетов, чтобы убедиться в отсутствии циклических зависимостей.
3

Есть два общих подхода:

]}

Если, кроме открытого интерфейса, вам нужны только некоторые вспомогательные функции, просто поместите их в безымянное пространство имен в файле реализации: 

// header:

class MyClass {
// interface etc.
};

// source file:

namespace {
    void someHelper() {}
}

// ... MyClass implementation

Если вы хотите скрыть функции-члены, рассмотрите возможность использования идиомы PIMPL: 

class MyClassImpl; // forward declaration

class MyClass {
public:
    // public interface
private:
    MyClassImpl* pimpl;
};

MyClassImpl реализует функциональность, в то время как MyClass перенаправляет вызовы публичного интерфейса в частную реализацию.

4

Вы можете найти некоторые из предложений в крупномасштабном программном обеспечении C++ полезными. Он немного устарел (опубликован в 1996 году), но все еще ценен, с указателями на структурирование кода, чтобы свести к минимуму проблему "перекомпиляции мира при изменении одного заголовочного файла".

1

Статья Херба Саттера о " Что такое класс? - Принцип интерфейса " представляет некоторые идеи, о которых многие, кажется, не думают при проектировании интерфейсов. Он немного устарел (1998), но, тем не менее, там есть кое-что полезное.

0

Сначала объявите переменные, которые вы можете использовать в одном строковом объявлении также так.

 char Name[100],Name2[100],Name3[100];
 using namespace std;
int main(){

 }

И если у вас есть длинный кусок кода, который можно использовать вне программы, сделайте его новой функцией. likeso.

void Return(char Word[100]){
cout<<Word; 
cin.ignore();    
} 
int main(){ 
Return("Hello");
}

И я предлагаю любые внешние функции и объявления, которые вы помещаете в файл заголовка и связываете его likeso Dev-C++ #include " ресурс.h "

-6