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

• Пользователь может взаимодействовать с объектом только через этот интерфейс. Реализуется с помощью ключевого слова: public.

• Пользователь не может использовать закрытые данные и методы. Реализуется с помощью ключевых слов: private, protected, internal.

Сокрытие реализации целесообразно применять в следующих случаях:

• предельная локализация изменений при необходимости таких изменений,

• прогнозируемость изменений (какие изменения в коде надо сделать для заданного изменения функциональности) и прогнозируемость последствий изменений.

Полиморфи́зм (в языках программирования) — возможность объектов с одинаковой спецификацией иметь различную реализацию.

• внешняя общность проявляется как одинаковый набор методов с одинаковыми именами и сигнатурами (именем методов и типами аргументов и их количеством);

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

Абстра́кция — в объектно-ориентированном программировании это придание объекту характеристик, которые четко определяют его концептуальные границы, отличая от всех других объектов. Основная идея состоит в том, чтобы отделить способ использования составных объектов данных от деталей их реализации в виде более простых объектов, подобно тому, как функциональнаяабстракция разделяет способ использования функции и деталей её реализации в терминах более примитивных функций, таким образом, данные обрабатываются функцией высокого уровня с помощью вызова функций низкого уровня.

• Такой подход является основой объектно-ориентированного программирования. Это позволяет работать с объектами, не вдаваясь в особенности их реализации.

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

• Другими словами, класс-наследник реализует спецификацию уже существующего класса (базовый класс). Это позволяет обращаться с объектами класса-наследника точно так же, как с объектами базового класса.

К5 – граф Куратовского. Теорема Понтрягина-Куратовского о том, что любой граф, содержащий гомеоморфный подграф К5 и К3.3 - не планарен.

К3.3 – полный двудольный граф с 3 вершинами.

1. Порождающие паттерны. Обзор.

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

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

Порождающие шаблоны инкапсулируют знания о конкретных классах, которые применяются в системе. Они скрывают детали того, как эти классы создаются и стыкуются. Единственная информация об объектах, известная системе, — это их интерфейсы, определенные с помощью абстрактных классов. Следовательно, порождающие шаблоны обеспечивают большую гибкость при решении вопроса о том, что создается, кто это создает, как и когда. Можно собрать систему из «готовых» объектов с самой различной структурой и функциональностью статически (на этапе компиляции) или динамически (во время выполнения).

• абстрактная фабрика (abstract factory);

• строитель (builder);

• фабричный метод (factory method);

• ленивая инициализация (lazy initialization);

• объектный пул (object pool);

• прототип (prototype);

• одиночка (singleton).

2. Паттерн Singleton. Пул объектов. Задача наследования.

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

Плюсы

• контролируемый доступ к единственному экземпляру;

• уменьшение числа имён;

• допускает уточнение операций и представления;

• допускает переменное число экземпляров;

• бо́льшая гибкость, чем у операций класса.

Минусы

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

• Усложняет написание модульных тестов и следованию TDD

Применение

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

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

class base

{

protected:

virtual ~base(){} //гарантируем удаление только через FreeInst()

public:

virtual void Do1()=0;

virtual void FreeInst(){delete this;}

};

class Simple : public base

{

protected:

~Simple () {printf("Simple::~Simple\n");}

public:

void Do1(){printf("Simple::Do1\n");}

};

class Singleton : public base

{

static Singleton* _self;

static int _refcount;

protected:

Singleton(){}

~Singleton () {printf("Singleton::~Singleton\n");}

public:

static Singleton* Instance()

{

if(!_self) _self = new Singleton ();

_refcount++;

return _self;

}

void FreeInst() {_refcount--; if(!_refcount) {delete this; _self=NULL; } }

void Do1(){ printf("Singleton::Do1\n"); }

};

Singleton* Singleton ::_self=NULL;

int Singleton :: _refcount=0;

Объектный пул (англ. object pool) —порождающий шаблон проектирования, набор инициализированных и готовых к использованию объектов. Когда системе требуется объект, он не создаётся, а берётся из пула. Когда объект больше не нужен, он не уничтожается, а возвращается в пул.

Применение

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

Переполнение

Если в пуле нет ни одного свободного объекта, возможна одна из трёх стратегий:

1. Расширение пула.

2. Отказ в создании объекта, аварийный останов.

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

Примеры

1. Информация об открытых файлах в DOS.

2. Информация о видимых объектах во многих компьютерных играх(хорошим примером является движок Doom). Эта информация актуальна только в течение одного кадра; после того, как кадр выведен, список опустошается.

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

Ловушки

1. После того, как объект возвращён, он должен вернуться в состояние, пригодное для дальнейшего использования. Если объекты после возвращения в пул оказываются в неправильном или неопределённом состоянии, такая конструкция называется объектной клоакой (англ. object cesspool).

2. Повторное использование объектов также может привести к утечке информации. Если в объекте есть секретные данные (например, номер кредитной карты), после освобождения объекта эту информацию надо затереть.