Интерфейс на С++

[_Bers]

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

2_Bers
этот кусок кода и есть простейший template method. называется по-другому только из-за того, что определяет не основу алгоритма, а основу интерфейса. все

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

А так же, в чем смысл использовать не_вирт методы для объектов полиморфного семейства.

[pproger]

2_Bers

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

я несколько раз уже сказал, это то же самое что и шаблонный метод (что ты вроде как понимаешь). зачем нужен шаблонный метод? для описания алгоритма с переопределяемыми шагами. разница (если это можно считать разницей) единственна - nvi это тривиальный tm!

к примеру, есть иерархия

class Animal {
public:
	virtual ~Animal() {}
	virtual void speak() const = 0;
};

class Dog : public Animal {
public:
	void speak() const { std::cout << "Woof!" << std::endl; }
};

class Cat : public Animal {
public:
	void speak() const { std::cout << "Meow!" << std::endl; }
};

какой ужас, в каждом переопределении speak одинаковый код!!!

std::cout << [что-то специфичное] << std::endl;

как избежать? применить nvi (читай - простейший template method)

class Animal {
public:
	virtual ~Animal() {}
	void speak() const { std::cout << getSound() << std::endl; }
private:
	virtual const char *getSound() const = 0;
};

class Dog : public Animal {
private:
	const char *getSound() const { return "Woof!"; }
};

class Cat : public Animal {
private:
	const char *getSound() const { return "Meow!"; }
};

в данной иерархии интерфейсом так и остался метод speak, ибо только он открыт. отсюда и название

[_Bers]

Я имел ввиду, для чего вообще это может быть применено.

Грубо говоря, можно рассматривать процесс разработки с двух сторон:

1. Бизнес-логика независимая, и использует движок, как инструмент для собственных нужд. По мере необходимости, она эксплуатирует возможности движка.

2. Бизнес-логика является лишь одним из компонентов движка. И движок сам толкает методы бизнес-логики.

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

Для этого создаётся компонент, реализующий всю гипотетическую бизнес логику. А разработчику реального компонента останется унаследоваться, и реализовать "уникальные няшки" его конкретного компонента.

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

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

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

[pproger]

2_Bers

Однако, для этого можно применить паттерн "шаблонный метод" без виртуальных функций.

вротмненоги. ну-ка, приведи пример паттерна шаблонный метод без виртуальных функций. или ты думаешь, раз в названии есть слово шаблонный, то это как то связано с шаблонами языка с++?))
жду примера

пс. раз уж пошла такая пьянка - что такое виртуальный полиморфизм?) я знаю только про динамический и статический

[_Bers]

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

2_Bers

вротмненоги. ну-ка, приведи пример паттерна шаблонный метод без виртуальных функций. или ты думаешь, раз в названии есть слово шаблонный, то это как то связано с шаблонами языка с++?))
жду примера

В том числе, и при помощи шаблонов так же можно реализовывать шаблонный метод.

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

"Шаблонный метод" решает проблему структурирования кода.
Проблему автоматизации рутины.

#include "Moduls.hpp"
class API: public Module1, Module2,...,ModuleN
{
public:
     API():Module1()
          ,Module2(*this)
          , ...
          ,ModuleN(*this) {}
};

Здесь API - носитель интерфейса. Он наследует весь интерфейс от своих предков. А модули даже не подозревают о существовании друг друга.

Преимущества: данное решение позволяет относительно гибко и безболезненно изменять строение уже существующего архитектурного сооружения. Если заменить один модуль другим, то другие модули этого даже не заметят. А логика работы может измениться.
К тому же, двигая наиболее "завязанные" модули в конец, а наиболее "независимые" в начало, и перерабатывая серединку, за счет перераспределения ролей и ответственности, можно сократить количество модулей. И отделить "няшки" от рутины.

Мной было применено для ликвидации божественных классов, путем перераспределения ролей и ответственности между модулями на позднем этапе развития.

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

2_Bers
пс. раз уж пошла такая пьянка - что такое виртуальный полиморфизм?)

Полиморфизм, реализуемый при помощи виртуальных функций.

[pproger]

2_Bers
ничего, кроме множественного наследования я не увидел. этот код не имеет ничего общего с паттерном Шаблонный Метод

"Шаблонный метод" решает проблему структурирования кода.

not even close

максимум, что ты мог добиться без динамического полиморфизма - реализовать паттерн Стратегия (который ошибочно можно было бы принять за Шаблонный Метод). но у тебя даже этого нет.

Полиморфизм, реализуемый при помощи виртуальных функций.

т.е ты придумал свой термин?)


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

"Шаблонный метод" решает проблему структурирования кода.

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

[Krok27]

Что тут у вас, ребята? Письками меряетесь? Ну ну. Здорово. Неплохо. Как дети малые ей богу.
Открытая виртуальная функция должна выполнять две вещи - предоставить интерфейс и определить детали поведения (как появилось "и" все архитекторы ПО быстро бегут удалять это "и"). Перед виртуальной функцией тогда стоят две различные задачи - признак недостаточного разделения задач. Поэтому и применяется что-то наподобие шаблонного метода.
Герб Саттер "Новые сложные задачи на С++" стр.120

[pproger]

2Krok27

Что тут у вас, ребята? Письками меряетесь? Ну ну. Здорово. Неплохо. Как дети малые ей богу.

тож чтоль хочешь?)

Поэтому и применяется что-то наподобие шаблонного метода.

это и есть шаблонный метод

[Krok27]

2Krok27
Цитата:
Что тут у вас, ребята? Письками меряетесь? Ну ну. Здорово. Неплохо. Как дети малые ей богу.
тож чтоль хочешь?)

Не, не хочу. Вдруг у кого нибудь больше.

[_Bers]

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

2_Bers
ничего, кроме множественного наследования я не увидел. этот код не имеет ничего общего с паттерном Шаблонный Метод

not even close

максимум, что ты мог добиться без динамического полиморфизма - реализовать паттерн Стратегия (который ошибочно можно было бы принять за Шаблонный Метод). но у тебя даже этого нет.

Данное решение позволяет делать вещи:
1. Разрабатывать компонент системы, абстрагируясь от самой системы.
2. Влиять на поведение всей системы, изменяя поведение отдельных её компонентов, путем подмены отдельных компонентов, времени написания исходного кода. Что является реализацией паттерна "шаблонный метод".
3. Дробить существующие модули на кучку отдельных. Либо объединять их разными способами.

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

т.е ты придумал свой термин?)

Нет. Я называю вещи своими именами.
Красная морковка - это морковка красного цвета.
А виртуальный полиморфизм - это полиморфизм, реализованный при помощи виртуальных функций.

Ваш К. О.

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

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

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

Мухи отдельно, котлеты отдельно.

Идея паттерна - получить возможность комфортно и безболезненно изменять поведение отдельного компонента.

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

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

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

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