Добрый день

Ситуация типичная. Есть абстрактный базовый класс, все вполне "академично"

C++ (Qt)
class taskScheduler {
public:
  virtual void start( void ) = 0; 
  virtual void stop( void ) = 0; 
  virtual void addTask( void ) = 0; 
  ...
};
 

И есть порожденный класс

C++ (Qt)
class defautrScheduler : public taskScheduler {
  void start( void ); 
  void stop( void ); 
  void addTask( void ); 
  ...
};
 

Ну разумеется все пользующие видят taskScheduler *, а реально создается defautrScheduler. Ладно, но вот выяснилось что нужна ф-циональность checkForAbort - куда ее лепить? Я пошел по пути наименьшего сопротивления - расширил базовый класс. Оправдаться очень легко - является ли проверка на отмену (checkForAbort ) "неотъемлемой" частью taskScheduler? Да, конечно! (ну а почему нет?). Но все же у меня смутное чувство недовольства. Эдак что угодно можно признать "совершенно необходимым" и слить в базовый класс, который очень скоро превратится в хз что. 

Мнения? (понимаю что мой пост может "слишком субъективен")

Спасибо

А как определить является ли? Это можно (с успехом) утверждать и подогнать под это все что угодно.

Прошу показать на примере того же ф-ционала (юзверь отменяет операцию)

Сама по себе формулировка "выяснилось что нужна ф-циональность checkForAbort" слишком расплывчатая.
Видимо, вы сами не вполне осознаете, кому и зачем понадобился этот checkForAbort.

На самом деле все просто: база хранит только общее для всех потомков.
Если checkForAbort нужен всем - тогда в базу.
Если одному - только этому одному потомку.
Если части наследников - значит нужно сделать дополнительный интерфейс, и наследовать от базы и от дополнительного интерфейса тех, кому этот функционал действительно нужен.

На плюсах оч хорошо действует правило: "то, чего быть не должно - не должно быть в принципе".
Смысл в том, что бы сделать так, что бы этого метода не было у тех классов, кому этот метод не нужен.

Вы никогда не задумывались, почему Шолохов описывает природу не так как Толстой?
Сейчас, вы пытаетесь выяснить, как правильно описывать природу. Есть ли ответ на этот вопрос... думаю что нет.

Для чего в интерфейсе - реализация? Она должна быть в defaultSheduler:

C++ (Qt)
class taskScheduler {
public:
  virtual void start( void ) = 0; 
  virtual void stop( void ) = 0; 
  virtual void addTask( void ) = 0; 
  ...
  typedef bool (*abortProcCallback)( int percent );
 
  void setAbortProc( abortProcCallback ) = 0; 
  bool isAborted( void ) const = 0;
};

Можно. Все можно. Главное, что бы вас это устраивало.

На мой взгляд, здесь подходит трехуровневая иерархия:

C++ (Qt)
 taskScheduler
 abortedTaskScheduler
 concreteTaskScheduler
 

Есть два хороших фактора при разработке:
1. Делать так, как сделать проще и быстрее.
2. Делать так, что бы на сопровождении не отгребсти проблем.

Если 9 из 10 возможных наследников захотят иметь такой метод, а 1 из 10 не нуждается, но и не против, то очевидно, что добавление такого метода в базовый интерфейс - это самое просто и быстрое решение, которое не создает проблем.


При разработке класса не нужно думать о его возможной эволюции вообще.

Все, о чем стоит думать в момент создания класса:
1. Дизайн использования (как это работает на практике)
2. Требования к механизму (условия эксплуатации)
3. Гарантии рабостопособности и стабильности.

Ваш пример можно перефразировать:

Механизм ImageProcess, должен уметь обрабатывать картинки с альфа-каналом, при этом, картинки могут быть как с альфа-каналом, так и без него. Таким то, и таким то образом.

Лично я:

1. Вообще не стал бы городить тут интрфейсов, ибо по задаче в этом нет необходимости.
2. Дизайн проект. Как пользователи хотя бы приблизительно хотели бы это видеть?

Допустим, действия наиболее частые и характерные для любого множества картинок я бы определил в жесткий "стандартный интерфейс" - в набор паблик методов ImageProcess:

ImageProcess ip("Example.png"); //любое множество картинок умеет загружаться с диска

ip.ScaleXY(100,100); //любое множество картинок можно масштабировать

//некий специфичный обработчик. Умеет делать узко-специализированные действия над буфером цветов картинки
AlphaSpecific as;

ip.Work(as); //AlphaSpecific знает о существовании ImageProcess. Вытряхивает из него нужные данные и работает.

Мы обеспечиваем удобные для пользователя интуитивно понятные методы работы с наиболее распространенными вариантами.
Эти методы должны перекрыть порядка 95% использования.

И предоставляем пользователям способ, как удобно организовать оставшиеся 5% специфических обработок:
Пользователь порождает от ISpecific класс обработки, и кормит своего потомка ImageProcess::Work(ISpecific*);

Для этого и существует документ "требования к механизму".
Одну и ту же задачу можно решить десятком различных способов. Какой из них выбрать?
Тут даже думать не нужно: самое простое в плане реализации, которое удовлетворяет требованиям к механизму.

У меня был случай на практике: класс Picture. Содержал в себе весь джентельменский набор для тех самых 95% случаев использования: масштабирование, угол поворота, прозрачность по альфе, и тп вещи.

Моя первая реакция: мне угнетало такое большое количество разных методов в одном классе. Какой-то божественный класс.
Я ещё тогда подумал: а как можно сократить количество паблик-методов, не потеряв удобства использования?

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


То есть, если функционал Scale стабильно часто требуется пользователям, то его в любом случае придется реализовать.
Вопрос только: где он будет?

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

Пускай это будет "божественный объект". Но если при этом, он будет проще в плане изготовления и использования, если такой код в будущем будет проще сопровождать - все равно это лучше, чем на ровном месте из каких то полуфилософских-религиозных соображений городить архитектуру только ради архитектуры. И усложнять код делая фичу ради фичи.

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


Итого:
1. Проблемы нужно решать по мере их наступления. А не пытаться заранее решать ещё не существующие проблемы.
2. Делать нужно так, как можно сделать проще и быстрее.