Үлгілер негіздері. Жобалау қағидалары.

SOLID принципі.
Бекарыстанқызы Ақбаян
Үлгі деген не?
• Жобалау үлгісі— бұл бағдарлама архитектурасын құру кезінде нақты бір проблемаларды шешуге жиі
қооданылатын шешім. Бұл нақты код емес – шешім концепциясы.
• Паттерн проектирования — это часто встречающееся решение определённой проблемы при
проектировании архитектуры программ. Паттерн пред- ставляет собой не какой-то конкретный код, а
общую концепцию решения той или иной проблемы, которую нужно будет ещё подстроить под нужды
вашей программы.
Паттерн неден тұрады?
• Үлгі шешетін проблема;
• Үлгі ұсынатын шешу жолын қолдану мотивациясв;
• Шешімді құрайтын класстардың құрылымы;
• Бағдарламалау тілдерінің бірінде берілген мысал;
• Әртүрлі контексттерде жүзеге асыру ерекшеліктері;
• Басқа үлгілермен байланыстары.
Из чего состоит паттерн?
• проблема, которую решает паттерн;
• мотивации к решению проблемы способом, который пред- лагает
паттерн;
• структуры классов, составляющих решение;
• примера на одном из языков программирования;
• особенностей реализации в различных контекстах;
• связей с другими паттернами.
Үлгілерді жіктеу
• Тудырушы үлгілер - бағдарламаға артық тәуелділіктер енгізбестен объектілерді оңай құру жолдарын
қарастырады.
• Құрылымдық үлгілер - объектілер арасында байланыстар орнатудың түрлі жолдарын көрсетеді.
• Әрекеттік үлгілер объектілер арасында тиімді қарым-қатынастар орнатуды қарастырады.
Классификация паттернов

• Порождающие паттерны беспокоятся о гибком создании объектов без внесения в программу лишних
зависимостей.
• Структурные паттерны показывают различные способы построения связей между объектами.
• Поведенческие паттерны заботятся об эффективной комму- никации между объектами.
Үлгілерді кім ойлап тапты?
• Концепцию паттернов впервые описал Кристофер Александер в книге Язык
шаблонов. Города. Здания. Строительство. В книге описан «язык» для
проектирования окружающей среды, единицы которого — шаблоны (или
паттерны, что ближе к оригинальному термину patterns) — отвечают на
архитектурные вопросы: какой высоты сделать окна, сколько этажей должно
быть в здании, какую площадь в микро- районе отвести под деревья и
газоны.
• Идея показалась заманчивой четвёрке авторов: Эриху Гамме, Ричарду Хелму,
Ральфу Джонсону, Джону Влиссиде- су. В 1994 году они написали книгу
Design Patterns: Elements of Reusable Object-Oriented Software, в которую
вошли 23 паттерна, решающие различные проблемы объектно-ориен-
тированного дизайна. Название книги было слишком длин- ным, чтобы кто-
то смог всерьёз его запомнить. Поэтому вскоре все стали называть её “book
by the gang of four”, то есть «книга от банды четырёх», а затем и вовсе “GoF
book”.
Үлгілерді білу не үшін керек?
• Тексерілген шешімдер
• Кодты стандарттау
• Программистерге ортақ сөздік
Зачем знать паттерны?
• Проверенные решения. Вы тратите меньше времени, используя готовые решения, вместо повторного
изобрете- ния велосипеда. До некоторых решений вы смогли бы доду- маться и сами, но многие могут
быть для вас открытием.
• Стандартизация кода. Вы делаете меньше просчётов при проектировании, используя типовые
унифицированные решения, так как все скрытые проблемы в них уже давно найдены.
• Общий программистский словарь. Вы произносите назва- ние паттерна, вместо того, чтобы час
объяснять другим про- граммистам, какой крутой дизайн вы придумали и какие классы для этого
нужны.
Жақсы архитектура сапасы
• Кодты қайта қолдану
• Бағдарламаны кеңейту
Качество хорошей архитектуры
• Повторное использование кода
• Расширяемость
Жобалаудың негізгі принциптері
• Өзгеретіннің барлығына инкапсуляция қолданыңыз
• Әдіс деңгейінде
• Класс деңгейінде
• Интерфейс деңгейінде жазыңыз
• Туынды класстар орнына композиция қолданыңыз
Базовые принципы проектирования

• Инкапсулируйте то, что меняется

• На уровне методов
• На уровне классов
• Программируйте на уровне интерфейса
1. Определите, что именно нужно одному объекту от другого, какие методы он вызывает.
2. Затем опишите эти методы в отдельном интерфейсе.
3. Сделайте так, чтобы класс-зависимость следовал этому интерфейсу. Скорее всего,
нужно будет только добавить этот интерфейс в описание класса.
4. Теперь вы можете сделать и второй класс зависимым от интерфейса, а не конкретного
класса.
• Предпочитайте композицию наследованию
Программируйте на уровне интерфейса
Программируйте на уровне интерфейса

Тағы бір мысал

Предпочитайте композицию наследованию

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

• Роберт Мартин, Agile Software Development, Principles, Patterns, and

Practices.

• S - ingle Responsibility Principle

• O - pen/Closed Principle
• L - iskov Substitution Principle
• I - nterface Segregation Principle
• D - ependency Inversion Principle
S - ingle Responsibility Principle
• Класста өзгеруге жалғыз ғана себеп болу керек
• У класса должен быть только один мотив для изменения.
O - pen/Closed Principle
• Класстарды кеңейтіңіз, бірақ оның бастапқы кодын өзгертпеңіз
• Расширяйте классы, но не изменяйте их первоначаль- ный код.
L - iskov Substitution Principle
• Туынды класстар негізгі класстың әрекеттерін аустырмауы керек, ал толықтыруы керек.
• Подклассы должны дополнять, а не замещать поведение базового класса.
• Типы параметров метода подкласса должны совпадать или быть более
абстрактными, чем типы параметров базового метода.
• Тип возвращаемого значения метода подкласса должен совпадать или
быть подтипом возвращаемого значения базового метода. Здесь всё то же,
что и в предыдущем пункте, но наоборот.
• Метод не должен выбрасывать исключения, которые не свойственны
базовому методу.
• Метод не должен ужесточать пред-условия.
• Метод не должен ослаблять пост-условия.
• Инварианты класса должны остаться без изменений.
• Подкласс не должен изменять значения приватных полей базового класса.
I - nterface Segregation Principle
• Клиенттер өздері қолданбайтын әдістерден тәуелді болмауы керек
• Клиенты не должны зависеть от методов, которые они не используют.
D - ependency Inversion Principle
• Жоғарғы деңгейдің кластары төменгі деңгейдегі класстардан тәуелді болмауы керек. Екеуі де
абстакциядан тәуелді болуы керек. Абстракция детальдардан тәуелді болмауы керек. Детальдар
абстракциядан тәуелді болуы керек.

• Классы верхних уровней не должны зависеть от классов нижних уровней. Оба должны зависеть от
абстракций. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.