Предложения по созданию класса: расширение класса и повторное использование кода

Question

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

Предположим, у меня есть класс:

class UsedByManyPeople
{
  // ...has many fields
};

Как следует из названия, этот класс используетсямногими разработчиками.Мне нужно добавить 2 функции в этот класс:

1. a convert (), который преобразует UsedByManyPeople в SomeOtherType
2. getFileName (), который возвращает строку

Оба они соответствуют потребностям моего отдела.

---

Решение с первой попытки

Сначала я подумал о простом добавлении 2 новых методов в UsedByManyPeople. Таким образом, класс теперь будет выглядеть следующим образом:

class UsedByManyPeople
{
  // ...has many fields

  public:
    SomeOtherType const convert() const;
    std::string   const getFileName() const;
};

Однако эти 2 функции на самом деле являются специфическими для случая использования моего отдела, а другие отделы даже не имеют определения класса SomeOtherType и не заботятся о getFileName ().

Понятно, что вышеприведенный подход не является хорошим подходом (?).

Как бы вы расширили этот класс?

Альтернативы, которые пришли мне в голову:

---

Подкласс UsedByManyPeople и создайте свой собственный класс.

• Свяжите данные и метод вместе

Например,

class ExtUsedByManyPeople : public UsedByManyPeople
{
  public:
    SomeOtherType const convert() const;
    std::string   const getFileName() const;
};

---

Создание вспомогательных классов, по одному для каждогометод (yikes!) и реализуйте его как статические методы.

• Отделите данные от методов, ответственность за один класс

Например,

class UsedByManyPeopleToSomeOtherTypeConverter
{    
  public:
    static SomeOtherType const convert(UsedByManyPeople const&);
};
class UsedByManyPeopleFileName
{
  public:
    static std::string const getFileName(UsedByManyPeople const&);
};

---

Создайте один класс Helper со всеми методами внутри.

• Отдельные данные от методов, один класс, много обязанностей

Например,

class UsedByManyPeopleHelper
{
  public:
    static SomeOtherType const convert(UsedByManyPeople const&);
    static std::string   const getFileName(UsedByManyPeople const&);
};

Answer 1

Особенно, если методы специфичны для вашего отдела, использующего класс, вы должны реализовать их следующим образом: Создать один класс Helper со всеми методами внутри. Для этого есть несколько причин:

• Один класс помощника может быть находится в другом логическом проекте структура
• Если ваши новые методы не требуют доступа к внутреннему состоянию класса, это ясно выражено. Это обеспечивает лучшую инкапсуляцию. (который вы дополнили const ref, который считает хороший стиль)
• UsedByManyPeople не должен нести ответственность за преобразование себя в другой тип. Это нарушает SOLID

Answer 2

последний вариант больше ни на кого не повлияет и изолирует ваши разовые потребности в одном классе

Answer 3

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

namespace MyDept
{
    SomeOtherType const convert( UsedByManyPeople const& );
    std::string   const getFileName( UsedByManyPeople const& );
}

, который обеспечивает очень похожий интерфейс для вызывающего абонента, как статические вызовы из класса, например

overusedObjectAsSomeOtherType = MyDept::convert( overusedObject );

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

Answer 4

Вы не должны изменять существующий класс UsedByManyPeople. Если у вашего отдела есть предпочтения в отношении того, какие шаблоны использовать, тогда придерживайтесь стиля вашего отдела. В противном случае создайте вспомогательный класс для преобразований. Если вы видите несколько конверсий в будущем, вы можете создать класс для каждого конверсии. Для расширения getFileName вы можете получить класс (если это действительно полезное расширение) или добавить его в свой помощник.

Опять же, стандарт вашего департамента (если таковой существует) должен помочь вам в этом. Если у вас нет стандарта, сейчас самое время его создать.