AniNice

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

Прототип - Это порождающий паттерн проектирования, которые позволяет копировать объекты, не вдаваясь в подробности их реализации. У вас есть объект, который нужно скопировать. Как это сделать? Нужно создать пустой объект такого же класса, а затем поочерёдно скопировать значения всех полей из старого объекта в новый. Прекрасно! Но есть нюанс. Не каждый объект удастся скопировать таким образом, ведь часть его состояния может быть приватной, а значит — недоступной для остального кода программы. Паттерн Прототип поручает создание копии самим копируемым объектам. Он вводит общий интерфейс для всех объектов, поддерживающих клонирование...

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

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

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

Суть паттерна Фабричный метод - это порождающий паттерн проектирования, который определяет общий интерфейс для создания объектов в супер-классе, позволяя подклассам изменять тип создаваемых объектов. Паттерн "Фабричный метод" предлогает создавать объекты не напрямую, используя оператор new, а через вызов особого фабричного метода. Не пугайтесь, объекты все равно будут создаваться при помощи new, но делать это будет фабричный метод. На первый взгляд, это может показать бессмысленным: мы просто переместили вызов конструктора из одного конца программы в другой. Но теперь вы сможете переопределить фабричный метод в подклассе, чтобы изменить тип создаваемого продукта...

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

Representation State Transger (REST) - передача репрезентативного состояния или передача "самоописываемого" состояния. Архитектурный стиль взаимодействия компонентов распределённого приложения в сети. Другими словами, REST - это набор правил того как программисту организовать написание кода для серверного приложения. чтобы все его системы легко обменивались данными и приложение можно было масштабировать...

Keep it simple, stupid (или Делай проще тупица) - принцип проектирование, принятый в ВМС. Принцип KISS утверждает что большинство систем работают лучше всего, если они остаются простыми, а не усложняются. Поэтому в области проектирование простота должна быть одной из ключевой целей и следует избегать ненужно сложности. Принцип запрещающий использование более сложный средств, чем необходимо. Изречение часто вызываемое...

Don't repeat yoursalf (или Не повторяйся) - это принцип разработки программного обеспечения, нацеленный на снижение повторения информации разливного рода, особенно в системах со множеством слоев абстрагирования. Принцип DRY формируется как: "Каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы". Часто применяется к "семам баз данных, планам тестирования, сборкам программного обеспечения и документации". Когда принцип DRY применяется успешно, изменена единственного...

You aren't gonna need it (или Вам это не понадобиться) - процесс и принцип проектировании ПО, при котором в качестве основной цели и\или ценности декларируется отказ от избыточности функциональности, то есть отказ добавление функциональности, в которой нет непосредственной необходимости Обоснование Согласно адептам принципа YAGNI,...

SOLID (single responsibility, open–closed, Liskov substitution, interface segregation и dependency inversion) в программировании — введённый Майклом Фэзерсом (Michael Feathers) для первых пяти принципов, которые означали 5 основных принципов ООП и проектирования. Принципы: