8.Grasp-паттерны: информационный эксперт, низкая связность, высокое зацепление. Антипаттерны.

Информационный эксперт (Information expert) – это GRASP-принцип, утверждающий, что код должен быть написан там, где естественным образом есть максимум информации для решения имеющейся проблемы. Например, в вашей первой лабораторной работе, где нужно создавать круги на форме по нажатию на клавишу мыши и выделять их той же клавишей мыши, имея координаты мыши e.X и e.Y написать примерно такой код:

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

f o r (const auto &s : shape s ) {

s−>onClick ( e .X, e .Y) ;

}

Принцип слабого зацепления (Low coupling) – это GRASP-принцип, требующий снижать связность между объектами как меру того, насколько сильно один класс зависит от его предположений о каком-то другом конкретном классе. Например, мы скажем, что класс A слишком сильно связан с классом B, если класс A так использует класс B, что попытка заменить B на какой-то класс C связана с такими большими проблемами и усилиями, что за это никто из команды программистов даже не готов браться. При этом речь идёт именно о связности между классами, а не между объектами. Например, если два объекта связаны циклически, но через интерфейсы, то это ещё не говорит о нарушении принципа низкой связности, как это было бы, храни они прямые ссылки друг на друга по родным классам.

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

Программирование копи-пастом (Copy and Paste Programming)

Данный анти-паттерн является, наверное, самым древним в программировании. Когда от программиста требуется написание двух схожих функций, самым «простым» решением является написание одной функции, её копирование и внесение некоторых изменений в копию.

Во-первых, ухудшается переносимость кода

Во-вторых, понижается качество кода

В-третьих, усложняется поддержка кода

Золотой молоток (Golden hammer)

Золотой молоток — уверенность в полной универсальности любого решения. На практике это — применение одного решения для всех возможных и невозможных задач..

9. Бесклассовое (прототипно-ориентированное) ооп

Сам подход к созданию новых объектов путем клонирования существующих получает своё развитие в так называемом бесклассовом или прототипно-ориентированном программировании. В «привычном» ООП мы сначала создавали классы, а потом на основе класса можно было создавать объекты. В бесклассовом ООП, как ни странно, классов нет (хотя объекты, разумеется, есть), и для создания типовых и разнообразных объектов используются три механизма:

✎ создание пустого объекта без свойств и методов;

✎ добавление в любой объект новых свойств и методов;

✎ создание копии любого объекта.

Таким образом там, где в классовом ООП мы сначала создавали бы класс, наполняли бы его свойствами и методами, а затем создавали бы множество объектов – в бесклассовом ООП мы сначала создаём пустой объект, наполняем его свойствами и методами, а потом создаём множество клонов. Как и везде, в результате мы получаем, плюс-минус километр, одно и тоже – множество объектов с одинаковыми наборами свойств, но с потенциально разными значениями этих свойств. Конечно, дальше в каждый из таких «экземпляров» могут быть добавлены новые свойства, но правило «все объекты одного класса обязательно имеют одинаковый набор свойств» при этом не нарушается – ведь классов то нет!

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

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