Приватные методы

[m_ax]

Вот-вот, это то, про что я писал еще 5 страниц назад.

Есть у нас класс типа

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

Мы как то здесь уже обсуждали хороший архитектурный пример, как аналогичное решается в реализации boost::tokenizer. Где подход, использованный там,  позволяет легко менять поведение токенайзера без всякого наследования и при этом, не меняя интерфейса самого класса tokenizer.  


http://www.prog.org.ru/topic_22338_45.html

Обсуждение начинается с поста #50

 

[Racheengel]

Этих ConcreteCrap'ов может быть хоть мильён, каким надо таким и инициализируй SomeCrap.  И пользователям SomeCrap не важно, как внутренности ConcreteCrap'а устроены, что там приватно, что публично, можно ли от него наследоваться или нет, есть там поля m_shitValue или всё магией создаётся. Главное чтобы в GetSomeShit() возвращалось ожидаемое по логике класса значение.

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

Что касается переопределений в наследниках... ИМХО, человек, наследующийся от чего-либо, должен иметь возможность использовать унаследованный функционал в полном объеме, поскольку он может иметь больше актуальных знаний о предметной области и текущей архитектуре. Пример - опять же, появление нового стандарта/метода/оборудования, о котором изначальный разработчик мог и не подозревать, разве не так?

[Пантер]

Нет, не так. Класс проектируется со своей внутренней логикой и предоставляет только нужные части для переопределения. Иначе внутренняя логика может полностью "поехать".

[m_ax]

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

Извините, а чья это вина? Кто принимал решение использовать этот класс? Не тот ли  практик, что проектировал архитектуру, стремился сделать её как можно гибче и расширяемой? Или у практиков таких понятий нет? Сразу садимся писать class MainWindow, а дальше разберёмся по-ходу?    

[Old]

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

[Racheengel]

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

В чем же его неудачность? Этот пример - выжимка из реальной проблемы, которую я наблюдал.

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

ммм... ООП как раз и подразумевает наследование, не так ли?

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

Прошу прощения, но я там кроме холивара, ничего не увидел. В чем суть, если в двух словах? Переопределить оператор () ?

[Racheengel]

Извините, а чья это вина? Кто принимал решение использовать этот класс? Не тот ли  практик, что проектировал архитектуру, стремился сделать её как можно гибче и расширяемой?

Архитектуру проектировал Гугу-Теоретик. По его представлениям, класс не должен был расширяться, ибо 10 лет как существовал единственный стандарт, в котором Гугу шарил. И Гугу считал свой код непогрешимым, поэтому столкал все, что можно, в приваты.

Или у практиков таких понятий нет? Сразу садимся писать class MainWindow, а дальше разберёмся по-ходу?   

Это не практик, а быдлокодер...

[Old]

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

[Racheengel]

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

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

[Old]

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

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

P.S. Кстати, вы эпохальное решение "финдреплейсера" видели? Попробуйте его расширить хоть как нибудь.

[m_ax]

В чем же его неудачность? Этот пример - выжимка из реальной проблемы, которую я наблюдал.

Ну я об этом чуть выше написал, так что позвольте сразу перейти к последнему вопросу)

Прошу прощения, но я там кроме холивара, ничего не увидел. В чем суть, если в двух словах? Переопределить оператор () ?

Ну хорошо, не увидели, ладно.. В двух словах:
Вот Вы садитесь разрабатывать архитектуру приложения, так, чтоб с заделом на будущее. Этот этап, пожалуй, самый ответственный и требует определённого времени  и анализа - это выделение сущьностей (классов), их взаимодействие (их интерплей), их интерфейса, критический анализ и разбор возможных решений, который бы позволил наименее безболезненно в будущем расширить функционал.  Вы, как главный архитектор, должны (нет, просто обязаны) предугодать возможность, что завтра, например, вдруг измениться стандарт (по вашей терменологии). Вот это всё продумывается N-ное время вдали от компьютера с ручкой  в руке и туевой хучей листов бумаги (нет, не туалетной). И вот на этой теоретической (не практической) стадии проектирования у вас в голове должно стрельнуть - ан нет, этот класс SomeCrap не отвечает нашим амбициозным требованиям.. Как бы нам его переделать, так, чтобы в случае чего мы могли применить к нему новый стандарт?

И вот случай с boost::tokenizer как раз иллюстрирует это) Его разработчики дали возможность конечным пользователям изменять его поведение, в определённых пределах, разумеется)

Я понимаю, что Ваш пример в достаточной степени абстрактный, но если предположить (а мне больше ничего не остаётся, поскольку нет иных сведений) что приватный метод CalculateSomeShit определяется особенностями текущего конкретно "стандарта" и подразумевается, что этот стандарт не сегодня-завтра может измениться, то, проводя "пальцевую" аналогию с boost::tokenizer его реализация могла бы быть следующей:

Код

C++ (Qt)
template <class T, class Standart>
class SomeCrab
{
public:
    T get_some_shit() const
    {
        T result = 0;
        result += Standart::CalculateSomeShit(m_shit_value);
        return result;
    }
private:
    T m_shit_value;
};
 
template <class T>
struct currennt_standart
{
    static T CalculateSomeShit(const T & x)
    {
        return sqrt(x*0.001);
    }
};
 
template <class T>
struct new_standart
{
    static T CalculateSomeShit(const T & x)
    {
        return cos(x)  + sin(x);
    }
};
 
SomeCrab<double, current_standart<double>> someCrab;
SomeCrab<double, new_standart<double>> newSomeCrab;
...
 

       
Всё.. От Вас требуется выделить, обозначить интерфейс тех минимальных частей (сущностей), которые полностью зависят от стандарта и предоставить возможность легко его модифицировать. Но здесь, конечно, тоже существует определённая грань - глупо пытаться состряпать  супер класс на все случаи жизни)    

[Racheengel]

P.S. Кстати, вы эпохальное решение "финдреплейсера" видели? Попробуйте его расширить хоть как нибудь.

Это кто такой, почему не знаю?

[Old]

Это кто такой, почему не знаю?

Я про тот парсер, который был предложен Igors, в теме на которую ссылался m_ax.
А финдреплейсерами я называю почти все решения этого автора, уж очень ему функции findReplace с использованием QString удаются.

[Racheengel]

Я понимаю, что Ваш пример в достаточной степени абстрактный, но если предположить (а мне больше ничего не остаётся, поскольку нет иных сведений) что приватный метод CalculateSomeShit определяется особенностями текущего конкретно "стандарта" и подразумевается, что этот стандарт не сегодня-завтра может измениться, то, проводя "пальцевую" аналогию с boost::tokenizer его реализация могла бы быть следующей:

Ок, вы заменили наследование конструированием классов с помощью шаблонов. Конечно, для интерфейса с десятком методов типа get_some_shit() шаблон получится не маленьким (Игорь, не надо про говно ), но для небольших классов мы сами время от времени делаем что-то подобное.

Но возвращаясь к примерам выше - Вы исходите из того, что в Standart::CalculateSomeShit(m_shit_value); передается значение m_shit_value. В моем же случае Гугу даже этого решил избежать, и использование m_shit_value было им захардкожено в CalculateSomeShit(void) Я не уверен пока, что эту проблему можно разрешить подобным образом, не вижу пока хорошего варианта решения (ну, кроме "переделать все нафиг")...

[_Bers]

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

помоему, у вас тут противоречие.