Какой паттерн gof лежит в основе jbdc

Паттерны проектирования GoF.

Ответ: Паттерны проектирования (Design patterns) — специальные схемы для уточнения структуры подсистем или компонентов программной системы и отношений между ними.

Паттерны проектирования описывают общую структуру взаимодействия элементов программной системы, которые реализуют исходную проблему проектирования в конкретном контексте. Наиболее известными паттернами этой категории являются паттерны GoF (Gang of Four), названные в честь Э. Гаммы, Р. Хелма, Р. Джонсона и Дж. Влиссидеса, которые систематизировали их и представили общее описание. Паттерны GoF включают в себя 23 паттерна. Эти паттерны не зависят от языка реализации, но их реализация зависит от области приложения.

Шаблоны проектирования — это готовые шаблоны, позволяющие решать частые проблемы разработки. Существуют проблемы, требующие совершенно новых решений, но большинство уже встречалось разработчикам, поэтому их можно решить, применяя проверенные подходы, или шаблоны. В число популярных шаблонов проектирования входят Адаптер (Adapter), Мост (Bridge), Декоратор (Decorator), Фасад (Façade), Фабричный метод, Наблюдатель (Observer), Одиночка (Singleton), Стратегия (Strategy) и Шаблонный метод (Template Method). О шаблонах проектирования см. книгу «Design Patterns» Эриха Гаммы, Ричарда Хелма, Ральфа Джонсона и Джона Влиссидеса (Gamma, Helm, Johnson, and Vlissides, 1995).

Шаблоны имеют ряд достоинств, не характерных для полностью самостоятельного проектирования программы.

Шаблоны снижают сложность, предоставляя готовые абстракции Если вы скажете: «В этом фрагменте для создания экземпляров производных классов применяется шаблон «Фабричный метод»», — другие программисты поймут, что ваш код включает богатый набор взаимодействий и протоколов программирования, специфических для названного шаблона.

Шаблон «Фабричный метод» позволяет создавать экземпляры любого класса, производного от указанного базового класса, причем отдельные производные классы отслеживаются только самим «Фабричным методом». Если вы будете использовать шаблоны, другие программисты легко поймут выбранный вами подход к проектированию без подробного обсуждения кода.

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

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

Каталог паттернов проектирования

Abstract Factory (абстрактная фабрика).Предоставляет интерфейс для создания семейств, связанных между собой, или независимых объектов, конкретные классы которых неизвестны.

Adapter (адаптер). Преобразует интерфейс класса в некоторый другой интерфейс, ожидаемый клиентами. Обеспечивает совместную работу классов, которая была бы невозможна без данного паттерна из-за несовместимости интерфейсов.

Bridge (мост). Отделяет абстракцию от реализации, благодаря чему появляется возможность независимо изменять то и другое.

Builder (строитель). Отделяет конструирование сложного объекта от его представления, позволяя использовать один и тот же процесс конструирования для создания различных представлений.

Chain of Responsibility (цепочка обязанностей). Можно избежать жесткой зависимости отправителя запроса от его получателя, при этом запросом начинает обрабатываться один из нескольких объектов. Объекты-получатели связываются в цепочку, и запрос передается по цепочке, пока какой-то объект его не обработает.

Command (команда). Инкапсулирует запрос в виде объекта, позволяя тем самым вызвать клиентов типом запроса, устанавливать очередность запросов, протоколировать их и поддерживать отмену выполнения операций.

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

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

Facade (фасад). Предоставляет унифицированный интерфейс к множеству интерфейсов

в некоторой подсистеме. Определяет интерфейс более высокого уровня, облегчающий работу с подсистемой.

Factory Method (фабричный метод). Определяет интерфейс для создания объектов, при этом выбранный класс инстанцируется подклассами.

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

Interpreter (интерпретатор). Для заданного языка определяет представление его грамматики, а также интерпретатор предложений языка, использующий это представление.

Iterator (итератор). Дает возможность последовательно обойти все элементы составного

объекта, не раскрывая его внутреннего представления.

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

Memento (хранитель). Позволяет, не нарушая инкапсуляции, получить и сохранить во внешней памяти внутреннее состояние объекта, чтобы позже объект можно было восстановить точно в таком же состоянии.

Observer (наблюдатель). Определяет между объектами зависимость типа один-ко-многим, так что при изменении состоянии одного объекта все зависящие от него получают извещение и автоматически обновляются.

Prototype (прототип). Описывает виды создаваемых объектов с помощью прототипа и создает новые объекты путем его копирования.

Proxy (заместитель). Подменяет другой объект для контроля доступа к нему.

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

State(состояние). Позволяет объекту варьировать свое поведение при изменении внутреннего состояния. При этом создается впечатление, что поменялся класс объекта.

Strategy (стратегия). Определяет семейство алгоритмов, инкапсулируя их все и позволяя подставлять один вместо другого. Можно менять алгоритм независимо от клиента, который им пользуется.

Template Method (шаблонный метод). Определяет скелет алгоритма, перекладывая ответственность за некоторые его шаги на подклассы. Позволяет подклассам переопределять шаги алгоритма, не меняя его общей структуры.

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

Паттерны проектирования(GoF)

Паттерн проектирования — это часто встречаемое решение определённой проблемы при проектировании архитектуры программ.

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

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

Описания паттернов обычно формальны и чаще всего состоят из таких пунктов:

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

Порождающие (Creational)

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

Factory(Фабрика) Сам по себе не является паттерном. Подход, при котором логика создания объектов выносится в отдельный класс.
Фабричный метод(Factory Method) — это порождающий паттерн проектирования, который определяет общий интерфейс для создания объектов в суперклассе, позволяя подклассам изменять тип создаваемых объектов.
Абстрактная фабрика (Abstract factory) — порождающий шаблон проектирования, предоставляет интерфейс для создания семейств взаимосвязанных или взаимозависимых объектов, не специфицируя их конкретных классов. Шаблон реализуется созданием абстрактного класса Factory, который представляет собой интерфейс для создания компонентов системы (например, для оконного интерфейса он может создавать окна и кнопки). Затем пишутся классы, реализующие этот интерфейс.
Прототип (Prototype) Задаёт виды создаваемых объектов с помощью экземпляра-прототипа и создаёт новые объекты путём копирования этого прототипа. Он позволяет уйти от реализации и позволяет следовать принципу «программирование через интерфейсы». В качестве возвращающего типа указывается интерфейс/абстрактный класс на вершине иерархии, а классы-наследники могут подставить туда наследника, реализующего этот тип. Проще говоря, это паттерн создания объекта через клонирование другого объекта вместо создания через конструктор.
Строитель(Builder) — порождающий шаблон проектирования предоставляет способ создания составного объекта. Отделяет конструирование сложного объекта от его представления, так что в результате одного и того же процесса конструирования могут получаться разные представления.
Одиночка (Singleton) — порождающий шаблон проектирования, гарантирующий, что в однопоточном приложении будет единственный экземпляр класса с глобальной точкой доступа.

Структурные (Structural)

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

Адаптер (Adapter) — структурный шаблон проектирования, предназначенный для организации использования функций объекта, недоступного для модификации, через специально созданный интерфейс.
Мост (Bridge) — структурный шаблон проектирования, используемый в проектировании программного обеспечения чтобы «разделять абстракцию и реализацию так, чтобы они могли изменяться независимо». Шаблон мост использует инкапсуляцию, агрегирование и может использовать наследование для того, чтобы разделить ответственность между классами.
Компоновщик (Composite pattern) — структурный шаблон проектирования, объединяющий объекты в древовидную структуру для представления иерархии от частного к целому. Компоновщик позволяет клиентам обращаться к отдельным объектам и к группам объектов одинаково
Декоратор (Decorator) — структурный шаблон проектирования, предназначенный для динамического подключения дополнительного поведения к объекту. Шаблон Декоратор предоставляет гибкую альтернативу практике создания подклассов с целью расширения функциональности.
Фасад (Facade) — структурный шаблон проектирования, позволяющий скрыть сложность системы путём сведения всех возможных внешних вызовов к одному объекту, делегирующему их соответствующим объектам системы.
Приспособленец (Flyweight, "легковесный (элемент)") — структурный шаблон проектирования, при котором объект, представляющий себя как уникальный экземпляр в разных местах программы, по факту не является таковым.
Заместитель (Proxy) — структурный шаблон проектирования, который предоставляет объект, который контролирует доступ к другому объекту, перехватывая все вызовы (выполняет функцию контейнера).

Читать:

Не видно капчу что делать

Поведенческие (behavioral)

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

Есть ли польза от GoF-паттернов?

… a common pattern in software engineering research is the development of system-building techniques, such as object-oriented design, which are strongly advocated in the absence of evidence — K.N. Whitley, “Visual Programming Languages and the Empirical Evidence For and Against,” J. Visual Languages and Computing, vol. 8, pp. 109-142, 1997.

Паттерны проектирования стали неотъемлемой частью минимального набора знаний современного разработчика. Их упоминание вы с легкостью найдете в описании вакансии как на фронта, так и на бэка. На техническом интервью вам обязательно зададут вопрос о паттернах, а на утреннем созвоне с командой нередко прозвучит что-то типа адаптер, фабрика или обсервер. Хотя последнее, возможно, слегка притянуто за уши. Бесспорно, паттерны проектирования — это очередная тема, о которой говорят все, но о доказанной эффективности которых известно достаточно мало деталей.

Сразу оговоримся, что проблематика паттернов связана с ООП и в большей степени с такими языками как Java и C++. Большинство исследований, о которых пойдет речь дальше, рассматривает вопросы применения паттернов именно в этих языках. Однако это не означает, что, например, в JS паттерны будут работать как-то по другому. Вторая оговорка касается предмета нашего интереса. Несмотря на то, что существуют сотни вариаций паттернов проектирования, наибольшей интерес прикован к GoF . Существуют также и ограничения исследований, о которых мы поговорим в самом конце.

Линейка для паттернов

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

Давайте посмотрим на то, как конкретизируют это понятие в исследованиях. Wedyan и Abufakher [2020] в своем обзоре весьма детально разложили поддерживаемость кода на ряд составляющих.

Первой из них является условная склонность к изменениям. Чем больше строк требуется для модификации кода и чем больше ошибок возникает в результате таких изменений, тем хуже поддерживаемость. Вторая составляющая — склонность к ошибкам. Чем чаще появляются ошибки в коде и чем сложнее их устранить, тем хуже поддерживаемость. Стабильность является следующим фактором. Она связана с тем, как изменения в окружении влияют на появление ошибок в нашем коде.

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

Научные исследования

Теперь, когда мы примерно представляем себе то, как оценить качество кода, можно попытаться понять, как именно GoF паттерны влияют на поддерживаемость кода. Одна из первых попыток была предпринята в 2012 году Zhang и Budgen. В своей работе авторы отмечали, что несмотря на популярность темы паттернов в разработке, существовало достаточно небольшое количество эмпирических исследований, многие из которых лишь косвенно изучали применение паттернов в реальном коде. После анализа 219 публикаций ученые пришли к выводу о том, существуют лишь косвенные подтверждения того, что использование паттернов положительно влияет на поддерживаемость кода. Наряду с этим невозможно аргументировано сказать, когда именно необходимо использовать тот или иной паттерн в коде.

Год спустя появилось обзорное исследование [Ampatzoglou, Charalampidou, Stamelos, 2013] 120 публикаций, посвященных GoF паттернам. Оно и по сей день является наиболее полноценным и цитируемым по данной проблематике. И в нем проявились весьма интересные и неоднозначные результаты.

Так, большинство GoF паттернов положительно влияют на некоторые аспекты поддерживаемости кода. Особняком стоит стабильность кода. На нее подавляющее большинство паттернов влияет негативно. Однако тут стоит разделять стабильность всего кода и стабильность паттернов. Нам известно, что использование GoF паттернов на примере 65 000 лежащих в открытом доступе Java классов положительно влияет на их стабильность [Ampatzoglou et. al, 2015]. Получается, что паттерны сами по себе стабильны, но за эту стабильность расплачивается окружение.

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

Вместо заключения

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

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

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

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

В-третьих, исследования паттернов в основном проводятся на основе опросов профессионалов. Использование объективных метрик весьма незначительно, что добавляет долю субъективности в конечные результаты.

В-четвертых, изучение паттернов в основном производится по отдельности, в отрыве от остального кода. Тогда как на конечное качество кода оказывает их совокупность и синергия.

Что почитать

C. Zhang and D. Budgen, «What Do We Know about the Effectiveness of Software Design Patterns?,» in IEEE Transactions on Software Engineering, vol. 38, no. 5, pp. 1213-1231, Sept.-Oct. 2012, doi: 10.1109/TSE.2011.79.

Apostolos Ampatzoglou, Sofia Charalampidou, and Ioannis Stamelos. 2013. Research state of the art on GoF design patterns: A mapping study. J. Syst. Softw. 86, 7 (July, 2013), 1945–1964. https://doi.org/10.1016/j.jss.2013.03.063

A. Ampatzoglou, A. Chatzigeorgiou, S. Charalampidou and P. Avgeriou, «The Effect of GoF Design Patterns on Stability: A Case Study,» in IEEE Transactions on Software Engineering, vol. 41, no. 8, pp. 781-802, 1 Aug. 2015, doi: 10.1109/TSE.2015.2414917.

Wedyan, Fadi and Somia Abufakher. “Impact of design patterns on software quality: a systematic literature review.” IET Softw. 14 (2020): 1-17.