Архитектура программы: как лучше реализовать контейнер и методы управления его содержимым?

@mat_for_c · Регистрация: 26.04.2013

Author24 — интернет-сервис помощи студентам

Доброго времени суток.

Имею такой код:

C++

class A {
private:
   ... // поля класса
   
   int foo_1();
   void foo_2();
 
   bool bar_1();
   void bar_2();
 
public:
   int foo();
   int bar();
};

Получается, что foo дергает foo_1 и foo_2. Аналогично для bar(). Функций конечно же больше, нежели в упрощенном примере, и это немного напрягает. Думаю раскидать по интерфейсам, типо такого:

C++

class A { ... // поля };
 
class foo_A : public A {
private:
   int foo_1();
   void foo_2();
public:
   int foo();
};

Подскажите, это нормальный подход? Или я ерунду буду делать?)

@Undisputed · 02.05.2018, 22:51

Думаю что бы ответить на данный вопрос надо быть знакомым с предметной областью ваших классов.
На обычных foo, bar сложно что либо сказать.
Сильно зависит от того что конкретно делают эти методы и чем занимается ваш класс/классы

@mat_for_c · 02.05.2018, 23:08 **[ТС]**

Сообщение от Undisputed

что конкретно делают эти методы

Грубо говоря - class A - это хранилище (список) блоков (отдельная структура).
Методы foo - отвечают за вставку блока в нужное положение и возвращают количество других объектов, которых уже можно "слепить" из имеющихся блоков.
Методы bar отвечают за создание этих объектов и удаление использованных данных из блоков.

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

Добавлено через 4 минуты
И да, мой класс - dll проект.
т.е. вызов осуществляется так:

C++

1
2
3

int foo(class* A) {
   A->foo();
}

а если разнесу на 2 интерфейса, то будет так:

C++

1
2
3

int foo(class* A) {
   dynamic_cast<foo_A*>(A)->foo();
}

@Undisputed · 02.05.2018, 23:13

mat_for_c,
Судя по описанию у вас есть некий контейнер и методы для управления и получения некоторой информации о содержимом данного контейнера.

Выносить функциональность в другие классы обычно имеет смысл в тех случаях, когда та самая "вынесенная часть" может быть использована иным классом. Таким образом можно избежать дублирования кода.

Если же эти методы имеют отношение только к данному контейнеру, то выносить их за его пределы не нужно...
Попробуйте реорганизовать внутреннюю структуру пересмотрев реализацию методов.

Например, можно попробовать обьединить код нескольких методов в один, но при условии, что в итоге этот метод будет решать одну задачу.

@mat_for_c · 02.05.2018, 23:27 **[ТС]**

Сообщение от Undisputed

Судя по описанию у вас есть некий контейнер и методы для управления и получения некоторой информации о содержимом данного контейнера.

Да, совершенно верно.

Сообщение от Undisputed

можно попробовать обьединить код нескольких методов

Но чем больше кода в ф-ии, его сложнее читать, разве нет? Поэтому я и разбил на мелкие ф-ии, аля foo_1 и т.д., и сделал их приватными, ведь они же не должны быть доступны пользователю (черный ящик как-никак).
Но теперь этих мелких функций полно и явно они не называются foo_[индекс], т.е. глядя на описание класса не совсем понятно, что к чему относится

Добавлено через 2 минуты
Т.е. как вариант, сделать группировку:

C++

...
foo_1();
foo_2();
foo_3();
 
 
bar_1();
...

@Undisputed · 02.05.2018, 23:46

mat_for_c,
Да, внутренние детали желательно скрывать.
Насчёт имен методов это конечно же плохо. Лучше все таки использовать говорящие имена.

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

Добавлено через 1 минуту
mat_for_c,
Насчёт "много кода в одной функции" - это зависит от конкретной функций...
Функции/классы желательно определять по требованиям а не по количеству кода.
И что бы функция выполняла только одно требование.

Добавлено через 1 минуту
А это требование может быть выполнено в и 50 строк кода.
Можно конечно создавать вспомогательные методы но в пределах разумного и то если что то из основного метода можно выделить в подзадачу, это тоже нормальное решение.

@sourcerer · 03.05.2018, 07:11

Комментарий модератора

mat_for_c, пожалуйста, прочитайте правила форума.
Особое внимание обратите на пункт 4.3 (порядок именования тем).

@Undisputed 875 / 461 / 91 Регистрация: 10.06.2014 Сообщений: 2,669
	02.05.2018, 22:51	2
	Думаю что бы ответить на данный вопрос надо быть знакомым с предметной областью ваших классов. На обычных foo, bar сложно что либо сказать. Сильно зависит от того что конкретно делают эти методы и чем занимается ваш класс/классы 0

@Undisputed 875 / 461 / 91 Регистрация: 10.06.2014 Сообщений: 2,669
	02.05.2018, 23:13	4
	mat_for_c, Судя по описанию у вас есть некий контейнер и методы для управления и получения некоторой информации о содержимом данного контейнера. Выносить функциональность в другие классы обычно имеет смысл в тех случаях, когда та самая "вынесенная часть" может быть использована иным классом. Таким образом можно избежать дублирования кода. Если же эти методы имеют отношение только к данному контейнеру, то выносить их за его пределы не нужно... Попробуйте реорганизовать внутреннюю структуру пересмотрев реализацию методов. Например, можно попробовать обьединить код нескольких методов в один, но при условии, что в итоге этот метод будет решать одну задачу. 1

@Undisputed 875 / 461 / 91 Регистрация: 10.06.2014 Сообщений: 2,669
	02.05.2018, 23:46	6
	mat_for_c, Да, внутренние детали желательно скрывать. Насчёт имен методов это конечно же плохо. Лучше все таки использовать говорящие имена. Если нет говорящих имен, то скорее всего вы не правильно подошли к реализации. Думаю лучше сначала определить требования, а потом уже писать методы, которые будут отвечать установленным требованиям (тогда и проблем с именованием будет поменьше) А то у получается вы в методе написали произвольный код которому сложно дать имя (то есть сделали наоборот) Добавлено через 1 минуту mat_for_c, Насчёт "много кода в одной функции" - это зависит от конкретной функций... Функции/классы желательно определять по требованиям а не по количеству кода. И что бы функция выполняла только одно требование. Добавлено через 1 минуту А это требование может быть выполнено в и 50 строк кода. Можно конечно создавать вспомогательные методы но в пределах разумного и то если что то из основного метода можно выделить в подзадачу, это тоже нормальное решение. 1