Шаблоны проектирования (паттерн, pattern) — это эффективные способы решения характерных задач проектирования, в частности проектирования компьютерных программ. Паттерн не является законченным образцом проекта, который может быть прямо преобразован в код, скорее это описание или образец для того, как решить задачу, таким образом, чтобы это можно было использовать в различных ситуациях. Объектно-ориентированные шаблоны зачастую показывают отношения и взаимодействия между классами или объектами, без определения того, какие конечные классы или объекты приложения будут использоваться. Алгоритмы не рассматриваются как шаблоны, так как они решают задачи вычисления, а не проектирования.

Главная польза каждого отдельного шаблона состоит в том, что он описывает решение целого класса абстрактных проблем. Также тот факт, что каждый шаблон имеет свое имя, облегчает дискуссию об абстрактных структурах данных (ADT) между разработчиками, так как они могут ссылаться на известные шаблоны. Таким образом, за счёт шаблонов производится унификация терминологии, названий модулей и элементов проекта.
Правильно сформулированный паттерн проектирования позволяет, отыскав удачное решение, пользоваться им снова и снова.
В отличие от идиом, шаблоны независимы от применяемого языка программирования.

Паттернов или шаблонов проектирование существует великое множество. Вот лишь несколько примеров.
1. Основные шаблоны (Fundamental)
2. Порождающие шаблоны проектирования
3. Структурные шаблоны (Structural)
4. Поведенческие шаблоны (Behavioral)
5. Шаблоны параллельного программирования (Concurrency)

Это лишь малая доля всех шаблонов.
Позже подробней я опишу все шаблоны и приведу конкретные примеры.

з.ы. Цикл моих статей нацелен на программистов С++. Но тем не менее и программисты Delphi могут применять с успехом эти методики.
Поэтому прошу без холиваров, ругани и etc.

Эт я не для eXceed говорю, он итак знает )) Это для поддержания темы, чтобы народ подключился )

Я знаю, что ты скажешь в след. сообщении: "Виталик. Когда будем свой мессагер делать. Я уже написал сетевой стек" - ну это в мягкой обработке. Да. Я туплю. Времени нету Надо летом все это обмозговать .. Только вот дело это неблагодарное с этим флак'ом возиться. Кстати, тут нашел случайно инфу по 8-мому протоколу. Да, и еще описание OSCAR'a продается за $3

Часто можно слышать гордые высказывания "я - программист!".
Начинаешь выяснять и оказывается, что человек закончил 72-часовые курсы Visual Basic... Студентам-первокурсникам нашим неустанно повторяю, что умение кодировать - это не программирование.

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

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

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

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

eXceed, внимательно буду следить за этой темой. Спасибо за нее.

В php, кстати, прикольно система построена. Надо ввести, к примеру, число, а вводим "А11", при выполнении отсекаются все буквы, и принимается только "11"
А вот та же Delphi, float число "0.45" не поймет и вызовет исключение. "0,45" надо И вот какому юзеру нефиг делать и подбирать варианты ..

фуф, высказал накопившееся ..

Application.OnException() и будет вам благо

Как и обещал привожу пример паттерна "Прокси сервер" с архитектурой менеджер - сообщение.

Задача: Спроектировать IM на протоколе ICQ с возможностью быстрого наращивания функционала.
Решение:
1. Описание архитектуры.
В программе используется 3 модуля: а) Пользовательский интерфейс(далее UI) б) Сетевая подсистема с реализацией протокола ICQ. в) Менеджер сообщений.

2. Описание работы модулей.

UI и сетевая подсистема должны содержать в себе еще один менеджер сообщений и карту сообщений модуля. Каждый объект внутри модуля генерирует сообщение. Например пользователь нажал на кнопку и кнопка по указателю передала в менеджер сообщение MSG_BUTTON_CLICK с некоторыми параметрами. Сообщение можно передавать как и отдельной строкой(не удобно, т.к. нужен эффективный парсер) в виде: n(индексный номер сообщение по карте)|body(тело сообщения)|subsystem(подсистема которой сообщение предназначено). Эффективней реализовать карту сообщений и обращаться к уже готовым сообщениям по указателям. После сообщение поступает в менеджер, который согласно внутренней логике принимает решение. Грубо говоря вся логика работы модуля содержится во внутреннем менеджере. Если же сообщение предназначалось сетевой части программы(пользователь нажал кнопку подключения), то необходимо сообщение отправить основному менеджеру программы.
Передача сообщений из подсистем осуществляется под двойной ссылке. Тоесть указатель на указатель сообщения.
Это позволит не передавать данные из модуля в модуль, что экономит память.

Еще раз повторяю: РАБОТА КАЖДОГО МОДУЛЯ УПРАВЛЯЕТСЯ ВНУТРЕННИМ МЕНЕДЖЕРОМ С ИСПОЛЬЗОВАНИЕМ СИСТЕМ СООБЩЕНИЙ!

3. Основной менеджер

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

Основной менеджер может создавать очереди сообщений с приоритетами.
Привожу пример возможной реализации

Есть менеджер. Есть интерфейс задач. Допустим хотим что-то рисовать - заводим задачу. Хотим обрабатывать ввод - задача. Добавили обсчет частиц - задача. Добавили обсчет еще чего - задача. Ко всему этому прикрутили объединение в группы задач, возможно, подзадач. Добавили приоритеты. Запустили.

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

з.ы. Вот вы читали это все. И задавались вопросом: "А зачем это все?"
А затем, что если поменялся бы протокол, то вам пришлось бы изменить карту сообщений + функционал сетевой подсистемы. Больше вы ничего не меняете. Грубо говоря изменения в одном модуле не задевают другие модули. Расширять функционал так же легко. Пишется модуль и у него создается карта сообщений...

Видите, архитектурный подход решил сразу же кучу проблем
з.ы.^2 Все это похоже на предприятие. Менеджер/директор управляет своими подчиненными. Теория управления/кибернетика/менеджмент давно прошли все это. Почему бы обычным программистам не использовать то, что придумано до нас?

Одиночка, Singleton — шаблон проектирования, порождающий объекты.

Цель

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

Применение
* должен быть ровно один экземпляр некоторого класса, легко доступный всем клиентам;
* единственный экземпляр должен расширяться путем порождения подклассов, и клиентам нужно иметь возможность работать с расширенным экземпляром без модификации своего кода;

Примеры

С++

Возможная реализация на C++ (известная как синглтон Мейерса), где одиночка представляет собой статический локальный объект (важно: это решение не потоко-безопасно и приводится только для того, чтобы показать как устроен шаблон, а не для реального использования в крупномасштабных программных проектах).

template<typename T> class Singleton
{

public:
static T& Instance()
{
static T theSingleInstance; // у класса T есть конструктор по умолчанию
return theSingleInstance;
}
};

class OnlyOne : public Singleton<OnlyOne>
{
//.. интерфейс класса
};

Delphi

unit Unit1;

interface

type
TSingleton = class
strict private
constructor Create;

class var
FInstance: TSingleton;

public
class function GetInstance: TSingleton;
end;

implementation

constructor TSingleton.Create;
begin
inherited;
end;

class function TSingleton.GetInstance: TSingleton;
begin
if FInstance = nil then
begin
FInstance := TSingleton.Create();
end;
Result := FInstance;
end;

end.

Вот такой вот забавный Синглтон. позволяет организовывать менеджеры ресурсов, планировщики заданий и etc.
Синглтон является обязательным для изучения. На его основе реализуется паттерн Фабрика объектов. Но это мы рассмотрим позже.

Жду отзывов, комментариев, замечаний.

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

Предположим, что вам понадобился такой класс, объект которого должен существовать в единственном экземпляре. Кроме того, вы не хотите протаскивать этот объект во все места, где он может понадобиться, а желаете чтобы он был легко доступен из любого места программы. Таким классом может быть менеджер памяти, журнал событий (лог), звуковой менеджер, и так далее. В этих случаях приходит на помощь паттерн Singleton.

Я приведу простейшую реализацию Синглтона "Журнал событий".

#include <iostream>

class Log
{
public:

static void Initialize()
{
delete g_Instance;
g_Instance = new Log;
}

static void Shutdown()
{
delete g_Instance;
g_Instance = 0;
}

static Log& Instance()
{
return *g_Instance;
}

void Message(const std::string& message)
{
std::cout << "[Message]: " << message.c_str() << std::endl;
};

private:

static Log* g_Instance;

Log() {}
~Log() {}

Log(const Log&);
Log& operator = (const Log&);
};

Log* Log::g_Instance = 0;

int main()
{
Log::Initialize();

Log::Instance().Message("Log file initialized!");
Log::Instance().Message("GSOM");
Log::Instance().Message("Prepare to shutdown...");

Log::Shutdown();

return 0;
}

Приведенный класс имеет закрытые конструктор по умолчанию, конструктор копирования, деструктор и оператор присваивания. Таким образом ни пользователь, ни наследники класса не смогут самостоятельно создавать или удалять объекты данного класса. Создание и удаление происходит в функциях Initialize и Shutdown. Иными словами, мы имеем все гарантии того, что в программе будет существовать не более одного объекта класса Log. Закрытый оператор присваивания избавит от проблем, связанных с присваиванием самому себе. Как вы наверно уже заметили, единственный объект хранится по простому указателю, а не скажем по std::auto_ptr, и это не случайно. Наш Синглтон имеет закрытый деструктор, и std::auto_ptr просто не сможет удалить объект. А не подружить ли Cинглтон со смарт-поинтером? Нет — ведь в таком случае и у пользователя появится возможность оперировать смарт-поинтерами на Cинглтон. Да, пользователь не сможет создавать объекты, однако у него будет возможность конструировать смарт-поинтеры от указателя, полученного, например, с помощью &Log::Instance(). Конечно, такой случай выглядит весьма сомнительно, однако вспомним старый анекдот — после запирания входной двери на цербер, французский, английский и израильский замок, дополнительно закрыть на швабру все же не помешает.

Существует четыре способа инициализации и уничтожения Cинглтона:

1. Инициализация и уничтожение выполняются соответствующими функциями;
2. Инициализация и уничтожение выполняются посредством идиомы владения. В функции-точке входа на стеке объявляется объект, инициализирующий Синглтон в конструкторе, и уничтожающий его в деструкторе. На мой взгляд это наиболее разумный вариант;
3. Так называемая lazy-инициализация. Инициализация происходит при первом обращении к Синглтону, уничтожение — вызовом соответствующей функции. Достоинство этого способа в том, что если пользователь не использует Синглтон, то и не выделяются никакие ресурсы. Недостаток состоит в том, что если в системе присутствует несколько Синглтонов, использующих друг друга, то может возникнуть ситуация, при которой Сингтоны должны быть проинициализированны в определенном порядке, и вам придется выстраивать этот порядок искусственным путем;
4. Синглтон Меерса. Синглтон инициализируется в конструкторе, уничтожается в деструкторе и кроме того, сам Синглтон является статическим объектом. В данном случае проблема всего одна — стандарт ничего не говорит о порядке конструирования статических объектов. Если у Вас несколько Синглтонов, использующих друг друга, то скорее всего этот метод приведет к проблемам.

Теперь поговорим о недостатках паттерна в целом. Главный недостаток, собственно, один. И кроется этот недостаток даже не в самом паттерне, а в программисте. Дело в том, что не так просто понять, действительно ли в программе будет только один экземпляр класса. Представьте себе, что у вас есть Синглтон «Журнал событий», и что на проект вам выделено три года. Вы спокойненько себе программируете год-другой, и вдруг, в один прекрасный день начальство вам говорит: «Вот в этой подсистеме логи должны вестись на удаленном сервере». И начинается такой неприятный процесс как рефакторинг. А надо было всего-навсего местоположение лога указать в качестве параметра инициализации и, собственно, не делать его Синглтоном.
Единственный вариант, который приходит мне в голову, где может использоваться Синглтон, это ситуация, когда внешнее API вынуждает использовать системные Синглтоны. Например для Windows это WSAStartup / WSACleanup. Однако, это уже завязка на конкретную операционную систему, что не есть хорошо.
Итак, подведем итог. Сущностей, которые могут существовать действительно только в единственном экземпляре, практически не существует. Всегда найдется разумная ситуация, в которой понадобятся несколько экземпляров сущности. Кроме того — рефакторинг для внедрения Синглтона будет менее трудоемок, нежели для избавления от него.

з.ы. Небольшой оффтоп.

Зачем вообще создавалась эта тема?
Отвечаю на свой же вопрос.
Наш любимый университет(действительно я люблю СГУ. Он стал мне уже родным. Замечательные люди и преподаватели работают здесь) выпускает специалистов по специальностям КЗОИ и ПИЭ. Эти специальности тесно связаны с программированием. Большей части касается ПИЭ, т.к. выпускники часто работают программистами и разрабатывают сложные ИС.
Чесно скажу... Почти все студенты программируют на уровне школы. Это означает, что студенты мыслят процедурами. Согласитесь, что это плохо при разработке сложных ИС. Студенты не имеют ни малейшего понятия о ООП. А ведь ООП создавался для того, чтоб было удобней и проще разрабатывать сложные, много модульные системы и поддерживать больше объемы кода. Больше всего я поражен был, когда преподаватель просто не смог разобраться в коде моей курсовой работы(там небыло ничего сложного. Всего лишь один класс. Правда во всю использовался STL).
Наших студентов не учат использовать мощь ООП. Это сильно огорчает. Часто приходится видеть примитивный и некрасивый код. Когда девушке ставят 5 за программу написанную при помощи простейших процедур, а я приношу программу написанную красиво и элегантно и мне тоже ставят 5 и даже не спрашивают почему я сделал эту вещь так, а не как то по другому, то это меня раздражает. Судя по оценке девушка программирует на моем уровне... Почему так? Почему бы не ввести отдельный предмет посвященный изучению мощи ООП? Ведь это мировой стандарт! Почему наш университет не отвечает этим стандартам?
Эта тема создавалась специально для того, чтоб наши студенты могли проникнутся силой ООП. Понять насколько ООП облегчает жизнь.
Читайте эту тему и изучайте ООП. Тогда вы станете действительно сильными программистами!
з.ы. В ближайшее время выложу паттерн Фабрика объектов и начну новый раздел под названием "ООП для самых маленьких".
Давайте вместе будем развиваться. Я отвечу на любые вопросы связанные с применением ООП.

В целом абсолютно согласен с вашим постом! На эту тему я тоже очень долго думал, и могу соообщить, что мы планируем делать в этом направлении.

Есть дисциплина "Объектно-ориентированное программирование" в учебном плане ПИЭ (по КЗОИ сейчас сразу не вспомню, надо будет план посмотреть). Так вот. У нас эта дисциплина всегда читалась на остаточном уровне (честно признаюсь). Никакого эффекта не было и нет, т.к. и преподаватели приглашенные всегда были, да и уровень оставлял желать лучшего. Могу в оправдание сказать (хотя это и так известно), что мы имеем острейший дефицит профессиональных кадров.

Однако, мы уже нашли выход из этой ситуации и в следующем учебном году именно по ООП ситуация будет потихоньку выправляться. Есть 100-процентная договоренность с В.В. Мироновым, к.ф.-м.н, доцентом о том, что он летом разрабатывает полный учебно-методический комплекс по этой дисциплине (по современным стандартам) => мы его в конце августа смотрим/утверждаем (возможно, и сюда кинем на обсуждение содержательные фрагменты) => Владимир Валерьевич читает эту дисциплину в след. учебном году. Те, кто знает Миронова (и студенты, и преподаватели), все сходятся во мнении, что это исключительно ответственный преподаватель (раз) + имел практический опыт программирования (два) + профессиональный ученый и педагог (три) + всегда в универе, т.е. не приглашенный (четыре). Так что, надеюсь, ситуацию мы постепенно, но выправим.

P.S. eXceed, у вас очень хорошо развитая интуиция и понимание ситуации + спасибо за обсуждение многих важных вопросов на форуме в принципе, а по программированию (эта тема) + по новой теме ООП - в отдельности.

P.S.S. Не в тему, но не могу не сообщить: Assembler у КЗОИ с нового учебного года перестанет быть факультативом, а станет обязательной дисциплиной (мы внесли изменения в учебный план).

--

За это - отдельный респект!