Здравствуйте участники форума.

У меня разработана проект на С++, который компилируется и работает.
В ней имеется в заголовочном файле .h описание класса, в .cpp файле реализация.
Например:
файл MyClass.h

class MyClass {
int myMethod();
....
};

файл MyClass.cpp

#include "MyClass.h"
int MyClass::myMethod()
{
...
}

Мне необходимо добавить файлы, которые содержали бы дополнительные методы для данного класса с реализацией.
Например:
файл MyClassFeature.h

#include "MyClass.h"
class MyClass {
int myFeature();
....
};

Вопрос состоит в том, как правильно это сделать? Какие инструменты языка/паттерны вы бы использовали?
При попытке декларации класса повторно в другом файле возникает ошибка.
При этом хочется лишь дополнить класс в другом файле, чтобы отделить одну функциональность от другой.
В другом файле содержится другая часть проекта которая может либо использоваться либо нет. При этом нужно
обязательно иметь доступ к содержимому класса MyClass.

Здравствуйте, Mola, Вы писали:

M>У меня разработана проект на С++, который компилируется и работает.
M>В ней имеется в заголовочном файле .h описание класса, в .cpp файле реализация.
M>...
M>Мне необходимо добавить файлы, которые содержали бы дополнительные методы для данного класса с реализацией.
M>...
M>Вопрос состоит в том, как правильно это сделать? Какие инструменты языка/паттерны вы бы использовали?
M>При попытке декларации класса повторно в другом файле возникает ошибка.
M>При этом хочется лишь дополнить класс в другом файле, чтобы отделить одну функциональность от другой.
M>В другом файле содержится другая часть проекта которая может либо использоваться либо нет. При этом нужно
M>обязательно иметь доступ к содержимому класса MyClass.


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

Здравствуйте, rg45, Вы писали:

R>Здравствуйте, Mola, Вы писали:

M>>...
M>>Мне необходимо добавить файлы, которые содержали бы дополнительные методы для данного класса с реализацией.
M>>...

R>Ты получишь для себя гораздо больше пользы, если расскажешь о самой задаче, а не о тех проблемах, с которыми ты столкнулся, идя по ошибочному пути.

Человек хочет, как в C#, где описание класса можно растащить по нескольким файлам, используя ключевое слово partial.

Здравствуйте, icWasya, Вы писали:


W>Человек хочет, как в C#, где описание класса можно растащить по нескольким файлам, используя ключевое слово partial.

Да, я догадался. В C# эта фича востребована в случаях, когда класс частично авто-сгенерирован, частично дописывается пользователем. В других же случаях я склоняюсь к тому, что partial является скорее вредной возможностью, чем полезной — на мой взгляд, она потакает нарушению важного принципа проектирования "один класс — одна задача".

Здравствуйте, Mola, Вы писали:

M>Мне необходимо добавить файлы, которые содержали бы дополнительные методы для данного класса с реализацией.

// myclass.h

class MyClass {
 void Function1() {}
#include "myclass.inc"
};

// myclass.inc

void Function2() {}

Не очень изящное решение, но иногда используется.

Можно разнести : в .h подключать файл с дополнительными прототипами, в .cpp — с их реализациями.

Хотя ИМХО лучше просто описать новые методы в прежних файлах. Что мешает это делать ?

Здравствуйте, rg45, Вы писали:

R>Да, я догадался. В C# эта фича востребована в случаях, когда класс частично авто-сгенерирован, частично дописывается пользователем. В других же случаях я склоняюсь к тому, что partial является скорее вредной возможностью, чем полезной — на мой взгляд, она потакает нарушению важного принципа проектирования "один класс — одна задача".

Чем тогда плохо обычное наследование? Автогенерённая часть — в базе, дописанная — в наследнике.
Как именно наследоваться — по ООП-шному с виртуальными функциями, по NVI или CRTP — дело хозяйское.

Здравствуйте, Кодт, Вы писали:

R>>Да, я догадался. В C# эта фича востребована в случаях, когда класс частично авто-сгенерирован, частично дописывается пользователем. В других же случаях я склоняюсь к тому, что partial является скорее вредной возможностью, чем полезной — на мой взгляд, она потакает нарушению важного принципа проектирования "один класс — одна задача".

К>Чем тогда плохо обычное наследование? Автогенерённая часть — в базе, дописанная — в наследнике.
К>Как именно наследоваться — по ООП-шному с виртуальными функциями, по NVI или CRTP — дело хозяйское.

Лично мне такой вариант тоже нравится..