Объектно-ориентированное программирование. Отношения между типами и особенности разработки. (Занятие 11)

Сентябрь 7, 2022

Главная
Алгебра
Объектно-ориентированное программирование. Отношения между типами и особенности разработки. (Занятие 11)

Содержание

2. План лекции Отношения между классами Объектно-ориентированный дизайн Принципы дизайна
3. Отношения между классами Наследование Зависимость Ассоциация Агрегация Композиция Метакласс
4. Особенности Использование одним классом структуры и/или поведения другого класса Дочерний класс специализирует родительский класс Образуется отношение
5. Особенности Изменение в одном классе (независимом) может влиять на другой класс (зависимый) Зависимый класс как-то использует
6. Особенности Семантическая связь классов Мощность Один к одному Один ко многим Многие к одному Многие ко
7. Особенности Можно считать частным случаем ассоциации Образуется отношение «целое-часть» между объектами Агрегат (контейнер) – большой внешний
8. Особенности Можно считать частным случаем агрегации Время жизни объектов-частей определяется объектом-контейнером и не может превышать время
9. Особенности Метакласс – это класс, объектами которого являются классы Корневой метакласс – единственный объект, являющийся своим
10. Ещё одна проблема разработки программ в ООП Этапы разработки (условно) Определение модели данных Определение алгоритма в
11. Object-oriented design Объектно-ориентированное проектирование – планирование системы как совокупности взаимодействующих объектов с целью решения программной задачи
12. Характеристики дизайна Coupling (связанность, зависимость) Характеристика взаимосвязи модулей Степень того, насколько модуль зависит от других модулей
13. Виды связанности Связанность содержимого (content coupling)- Один модуль изменяет или полагается на внутренние особенности другого модуля
14. Виды связанности Связанность через внешнее (external coupling) Два модуля используют навязанный извне формат данных, протокол связи
15. Виды связанности Связанность по структурированным данным (data-structured coupling, stamp coupling) Модули используют одну и ту же
16. Виды связанности Связанность по сообщениям (message coupling) Модули общаются только через передачу параметров или сообщений Состояние
17. Виды сфокусированности Случайная (coincidental cohesion) Части модуля сгруппированы «от фонаря» Единственное, что их объединяет – сам
18. Виды сфокусированности По взаимодействию (communication cohesion) Части модуля работают над одними и теми же данными По
19. Плохой дизайн Высокая связанность Эффект кругов по воде (или снежной лавины) при внесении изменений Сборка модулей
20. Хороший дизайн Loose coupling High cohesion Правда, эти требования друг другу противоречат И следует это из
21. Принципы SOLID Single responsibility principle Open/closed principle Liskov substitution principle Interface segregation principle Dependency inversion principle
22. Принципы SOLID http://lostechies.com/derickbailey/2009/02/11/solid-development-principles-in-motivational-pictures/
23. Single responsibility principle Принцип единственности ответственности Каждый класс должен иметь единственную ответственность Эта ответственность должна быть
24. Single responsibility principle public class Service{ public static Image getImage(String fileName) { ... } public static
25. Single responsibility principle public class ImageService{ public static Image getImage(String fileName) { ... } public static
26. Single responsibility principle
27. Open/closed principle Принцип открытости/закрытости Программные сущности (классы, модули и т.п.) должны быть открыты для расширения, но
28. Open/closed principle public class MessageSender { ... public void send(Message msg) { if(msg.getType == MessageType.SMS) sendSMS(msg);
29. Open/closed principle public class MessageSender { ... public void send(Message msg){ msg.send(); } ... } public
30. Open/closed principle
31. Liskov substitution principle Принцип подстановки Барбары Лисковой Пусть q(x) является свойством, верным относительно объектов x некоторого
32. Liskov substitution principle public class Rectangle{ double height, width; // методы set и get } public
33. Liskov substitution principle public class Square extends Rectangle{ public void setHeight(double h) {height = width =
34. Liskov substitution principle
35. Interface segregation principle Принцип разделения интерфейсов Клиенты не должны зависеть от методов, которые они не используют
36. Interface segregation principle
37. Dependency inversion principle Принцип инверсии зависимостей Модули верхних уровней не должны зависеть от модулей нижних уровней.
38. Dependency inversion principle public class Man { private Car car; public void gotoWork() { car =
39. Dependency inversion principle public class Man { private Mode mode; public void setModeOfMovement(Mode newMode) { this.mode
40. Dependency inversion principle
41. Law of Demeter Закон Деметры (принцип наименьшего знания) Каждый модуль должен обладать ограниченным знанием о других
42. Принцип YAGNI You ain’t gonna need it Реализуйте что-то, только если оно вам действительно нужно Не
43. Принцип KISS Keep it simple, stupid Keep it simple and stupid Keep it short and simple
44. Спасибо за внимание!
46. Скачать презентацию

Слайд 2

План лекции
Отношения между классами
Объектно-ориентированный дизайн
Принципы дизайна

Слайд 3

Отношения между классами
Наследование
Зависимость
Ассоциация
Агрегация
Композиция
Метакласс

Слайд 4

Особенности
Использование одним классом структуры и/или поведения другого класса
Дочерний класс специализирует родительский

класс
Образуется отношение «общее-частное» между классами

Реализация на практике

Часть синтаксиса языка
Возможен особый синтаксис для множественного наследования
Особый синтаксис для абстрактных классов
Возможен особый синтаксис для полностью абстрактных классов

Наследование

Слайд 5

Особенности
Изменение в одном классе (независимом) может влиять на другой класс (зависимый)
Зависимый

класс как-то использует независимый
Отношение направленное по своей природе

Реализация на практике

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

Зависимость

Слайд 6

Особенности
Семантическая связь классов
Мощность
Один к одному
Один ко многим
Многие к одному
Многие ко

многим

Реализация на практике

У класса есть поле типа другого класса
Мощность
«К одному» – поле имеет просто тип класса
«Ко многим» – поле имеет тип массива или коллекции класса

Ассоциация

Слайд 7

Особенности
Можно считать частным случаем ассоциации
Образуется отношение «целое-часть» между объектами
Агрегат (контейнер) –

большой внешний объект
Строгая направленность

Реализация на практике

Всё почти так же, как и в случае ассоциации
Ссылки между объектами не могут образовывать циклы

Агрегация

Слайд 8

Особенности
Можно считать частным случаем агрегации
Время жизни объектов-частей определяется объектом-контейнером и не

может превышать время жизни объекта-контейнера
Объект-часть не существует самостоятельно

Реализация на практике

Всё почти так же, как в случае агрегации
Создание и уничтожение объектов-частей происходит только в ходе выполнения операций объекта-контейнера

Композиция

Слайд 9

Особенности
Метакласс – это класс, объектами которого являются классы
Корневой метакласс – единственный

объект, являющийся своим собственным классом

Реализация на практике

Очень сильно зависит от языка
В некоторых языках существует только один метакласс – корневой

Метакласс

Слайд 10

Ещё одна проблема разработки программ в ООП
Этапы разработки (условно)
Определение модели данных
Определение

алгоритма в виде последовательности операций
Реализация на языке программирования
Проблема
Структурной единицей программы является класс
Из-за инкапсуляции модель данных связана с алгоритмом
Разделить данные и алгоритмы между классами можно далеко не единственным способом…

Слайд 11

Object-oriented design
Объектно-ориентированное проектирование – планирование системы как совокупности взаимодействующих объектов с

целью решения программной задачи
Для решения задачи необходимо разделить её на части и выбрать ответственных за них
Инкапсуляция разделяет ответственности (responsibility) между классами
Результат проектирования – распределение ответственностей и активностей по классам

Слайд 12

Характеристики дизайна
Coupling (связанность, зависимость)
Характеристика взаимосвязи модулей
Степень того, насколько модуль зависит от других

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

Слайд 13

Виды связанности
Связанность содержимого (content coupling)-
Один модуль изменяет или полагается на внутренние

особенности другого модуля (например, используются локальные данные другого модуля)
Изменение работы второго модуля приведёт к переписыванию первого
Связанность через общее (common coupling)-
Два модуля работают с общими данными (например, глобальной переменной)
Изменение разделяемого ресурса приведёт к изменению всех работающих с ним модулей

Слайд 14

Виды связанности
Связанность через внешнее (external coupling)
Два модуля используют навязанный извне формат данных,

протокол связи и т.д.
Обычно возникает из-за внешних сущностей (инструментов, устройств и т.д.)
Связанность по управлению (control coupling)+
Один модуль управляет поведением другого
Присутствует передача информации о том, что и как делать

Слайд 15

Виды связанности
Связанность по структурированным данным (data-structured coupling, stamp coupling)
Модули используют одну

и ту же структуру, но каждый использует только её часть (части могут и не совпадать)
Изменение структуры может привести к изменению модуля, который изменённую часть даже не использует
Связанность через данные (data coupling)+
Модули совместно используют данные, например, через параметры
Элементарные фрагменты маленькие и только они используются модулями совместно

Слайд 16

Виды связанности
Связанность по сообщениям (message coupling)
Модули общаются только через передачу параметров

или сообщений
Состояние децентрализовано
Отсутствие связанности (no coupling)
Модули вообще никак не взаимодействуют

Слайд 17

Виды сфокусированности
Случайная (coincidental cohesion)
Части модуля сгруппированы «от фонаря»
Единственное, что их объединяет

– сам модуль
Логическая (logical cohesion)
Части модуля логически относятся к одной проблеме
При этом части могут различаться по своей природе
ВременнАя (temporal cohesion)
Части модуля обычно используются в программе в одно время, рядом
Процедурная (procedural cohesion)
Части модуля всегда используются в определённом порядке

Слайд 18

Виды сфокусированности
По взаимодействию (communication cohesion)
Части модуля работают над одними и теми

же данными
По последовательности действий (sequential cohesion)
Результат работы одной части модуля является исходными данными для другой
Функциональная (functional cohesion)
Части модуля направлены на решение одной чёткой задачи, за которую отвечает модуль

Слайд 19

Плохой дизайн
Высокая связанность
Эффект кругов по воде (или снежной лавины) при внесении

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

Слайд 20

Хороший дизайн
Loose coupling
High cohesion
Правда, эти требования друг другу противоречат
И следует это

из самой природы ООП
Так что придётся искать компромисс

Слайд 21

Принципы SOLID
Single responsibility principle
Open/closed principle
Liskov substitution principle
Interface segregation principle
Dependency inversion principle

Слайд 22

Принципы SOLID
http://lostechies.com/derickbailey/2009/02/11/solid-development-principles-in-motivational-pictures/

Слайд 23

Single responsibility principle
Принцип единственности ответственности
Каждый класс должен иметь единственную ответственность
Эта ответственность

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

Слайд 24

Single responsibility principle
public class Service{
public static Image getImage(String fileName) {

...
}
public static void saveImage (Image img) {
...
}
public static void sendEmailMesage(String email,
String msg) {
...
}
public static void selectDataFromTable(String connect,
String tableName) {
...
}
}

Слайд 25

Single responsibility principle
public class ImageService{
public static Image getImage(String fileName) {

... }
public static void saveImage (Image img) { ... }
}

public class EmailService{
public static void sendEmailMesage(String email,
String msg) {...}
}

public class DataBaseService{
public static void selectDataFromTable(String connect,
String tableName) {
...
}
}

Слайд 26

Single responsibility principle

Слайд 27

Open/closed principle
Принцип открытости/закрытости
Программные сущности (классы, модули и т.п.) должны быть открыты

для расширения, но закрыты для изменения
Сущности могут изменять своё поведение без изменения их исходного кода
Принцип открытости/закрытости по Мейеру
Однажды разработанная реализация класса в дальнейшем требует только исправления ошибок
Новые или изменённые функции требуют создания нового класса
Рекомендуется наследование реализации
Реализация используется повторно
Тип не обязан использовать повторно
Полиморфный принцип открытости/закрытости
Используются полностью абстрактные типы
Реализация может быть изменена, или многие реализации могут использоваться полиморфно
Рекомендуется наследование от полностью абстрактных типов
Тип используется повторно и не изменяется
Реализации должны соответствовать типу

Слайд 28

Open/closed principle
public class MessageSender {
...
public void send(Message msg)

{
if(msg.getType == MessageType.SMS) sendSMS(msg);
else
if(msg.getType == messageType.EMAIL)sendEmail(msg);
}
...
}

Слайд 29

Open/closed principle
public class MessageSender {
...
public void send(Message msg){

msg.send();
}
...
}

public abstract class MessageSender {
public abstract void send();
}

public class SMSMessage
extends MessageSender {
public void send() {
....}
}

public class EMAILMessage
extends MessageSender {
public void send() {
....}
}

Слайд 30

Open/closed principle

Слайд 31

Liskov substitution principle
Принцип подстановки Барбары Лисковой
Пусть q(x) является свойством, верным относительно

объектов x некоторого типа T. Тогда q(y) должно быть верным для объектов y типа S, где S является подтипом типа T
(Р.С. Мартин) Использующие базовый тип функции должны иметь возможность использовать подтипы базового типа не зная об этом
(Б. Мейер) Дочерний класс не должен нарушать контракт родительского класса
Требования к сигнатурам операций дочерних классов
Типы аргументов не должны быть уже
Типы возвращаемых значений не должны быть шире
Не должны выбрасываться новые типы исключений, кроме случаев, когда новое исключение является подтипом исключения из родительской сигнатуры
Область доступа операции не должна сужаться

Слайд 32

Liskov substitution principle
public class Rectangle{
double height, width;
// методы set

и get
}

public class MyClass {
public static Rectangle zoomRectangle(Rectangle rect,
double zoomHeight, double zoomWidth) {
rect.setHeight(rect.getHeight() * zoomHeight);
rect.setWidth(rect.getWidth() * zoomWidth);
return rect;
}
public static void main(String[] args) {
Rectangle r1 = new Rectangle();
r1.setHeight(5);
r1.setWidth(2);
zoomRectangle(r1, 1, 2);
System.out.println("Area: " + r1.getHeight() * r1.getWidth());
}
}

Area: 20

Слайд 33

Liskov substitution principle
public class Square extends Rectangle{
public void setHeight(double h)

{height = width = h;}
public void setWidth(double w) {height = width = w;}
}

public class MyClass {
public static Rectangle zoomRectangle(Rectangle rect,
double zoomHeight, double zoomWidth) {
rect.setHeight(rect.getHeight() * zoomHeight);
rect.setWidth(rect.getWidth() * zoomWidth);
return rect;
}
public static void main(String[] args) {
Rectangle r1 = new Square();
r1.setHeight(5);
r1.setWidth(2);
zoomRectangle(r1, 1, 2);
System.out.println("Area: " + r1.getHeight() * r1.getWidth());
}
}

Area: 16

Слайд 34

Liskov substitution principle

Слайд 35

Interface segregation principle
Принцип разделения интерфейсов
Клиенты не должны зависеть от методов, которые

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

Слайд 36

Interface segregation principle

Слайд 37

Dependency inversion principle
Принцип инверсии зависимостей
Модули верхних уровней не должны зависеть от

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

Слайд 38

Dependency inversion principle
public class Man {
private Car car;
public void

gotoWork() {
car = new Car();
car.go(100, 200);
// какие-то действия
}
}

public class Car {
private int currentX,currentY;
public void go(int x, int y) {
currentY = y;
currentX = x;
}
...
}

Слайд 39

Dependency inversion principle
public class Man {
private Mode mode;
public void

setModeOfMovement(Mode newMode) {
this.mode = newMode;
}
public void gotoWork() {
mode.go(100, 200);
// какие-то действия
}
}

public interface Mode {
void go(int x, int y);
}

public class Car implements Mode {
public void go(int x, int y) {.......};
}

public class Teleport implements Mode {
public void go(int x, int y) {.......};
}

Слайд 40

Dependency inversion principle

Слайд 41

Law of Demeter
Закон Деметры (принцип наименьшего знания)
Каждый модуль должен обладать ограниченным

знанием о других модулях: должен знать только о модулях, которые имеют к нему непосредственное отношение
Каждый модуль должен взаимодействовать только с известными ему модулями и не должен «разговаривать с незнакомыми»
Каждый модуль должен обращаться только к своим непосредственным друзьям
Объект A может вызвать сервис (метод) объекта B, но не может использовать объект B для получения доступа к объекту C, чтобы использовать его методы
Метод m() объекта O может вызывать только методы следующих объектов
Сам объект O
Объекты-параметры метода m()
Любые объекты, созданные в ходе выполнения m()
Объектов, непосредственно ассоциированных с O
Глобальные переменные, доступные O в контексте m()

Слайд 42

Принцип YAGNI
You ain’t gonna need it
Реализуйте что-то, только если оно вам

действительно нужно
Не реализуйте что-то, использование чего вы только предвидите
Требуется разумный баланс со здравым смыслом

Слайд 43

Принцип KISS
Keep it simple, stupid
Keep it simple and stupid
Keep it short

and simple
Простота должна быть одной из основных целей в ходе разработки
Следует уходить от необоснованных сложностей

Слайд 44

Объектно-ориентированное программирование. Отношения между типами и особенности разработки. (Занятие 11)

Содержание

План лекцииОтношения между классамиОбъектно-ориентированный дизайнПринципы дизайна

Отношения между классамиНаследованиеЗависимостьАссоциацияАгрегацияКомпозицияМетакласс

ОсобенностиИспользование одним классом структуры и/или поведения другого классаДочерний класс специализирует родительский

ОсобенностиИзменение в одном классе (независимом) может влиять на другой класс (зависимый)Зависимый

ОсобенностиСемантическая связь классовМощность Один к одномуОдин ко многимМногие к одномуМногие ко

ОсобенностиМожно считать частным случаем ассоциацииОбразуется отношение «целое-часть» между объектамиАгрегат (контейнер) –

ОсобенностиМожно считать частным случаем агрегацииВремя жизни объектов-частей определяется объектом-контейнером и не

ОсобенностиМетакласс – это класс, объектами которого являются классыКорневой метакласс – единственный

Ещё одна проблема разработки программ в ООПЭтапы разработки (условно)Определение модели данныхОпределение

Object-oriented designОбъектно-ориентированное проектирование – планирование системы как совокупности взаимодействующих объектов с

Характеристики дизайнаCoupling (связанность, зависимость)Характеристика взаимосвязи модулейСтепень того, насколько модуль зависит от других

Виды связанностиСвязанность содержимого (content coupling)-Один модуль изменяет или полагается на внутренние

Виды связанностиСвязанность через внешнее (external coupling)Два модуля используют навязанный извне формат данных,

Виды связанностиСвязанность по структурированным данным (data-structured coupling, stamp coupling)Модули используют одну

Виды связанностиСвязанность по сообщениям (message coupling)Модули общаются только через передачу параметров

Виды сфокусированностиСлучайная (coincidental cohesion)Части модуля сгруппированы «от фонаря»Единственное, что их объединяет

Виды сфокусированностиПо взаимодействию (communication cohesion)Части модуля работают над одними и теми

Плохой дизайнВысокая связанностьЭффект кругов по воде (или снежной лавины) при внесении

Хороший дизайнLoose couplingHigh cohesionПравда, эти требования друг другу противоречатИ следует это

Принципы SOLIDSingle responsibility principleOpen/closed principleLiskov substitution principleInterface segregation principleDependency inversion principle

Принципы SOLIDhttp://lostechies.com/derickbailey/2009/02/11/solid-development-principles-in-motivational-pictures/

Single responsibility principleПринцип единственности ответственностиКаждый класс должен иметь единственную ответственностьЭта ответственность

Single responsibility principlepublic class Service{ public static Image getImage(String fileName) {

Single responsibility principlepublic class ImageService{ public static Image getImage(String fileName) {

Single responsibility principle

Open/closed principleПринцип открытости/закрытостиПрограммные сущности (классы, модули и т.п.) должны быть открыты

Open/closed principlepublic class MessageSender { ... public void send(Message msg)

Open/closed principlepublic class MessageSender { ... public void send(Message msg){

Open/closed principle

Liskov substitution principleПринцип подстановки Барбары ЛисковойПусть q(x) является свойством, верным относительно

Liskov substitution principlepublic class Rectangle{ double height, width; // методы set

Liskov substitution principlepublic class Square extends Rectangle{ public void setHeight(double h)

Liskov substitution principle

Interface segregation principleПринцип разделения интерфейсовКлиенты не должны зависеть от методов, которые

Interface segregation principle

Dependency inversion principleПринцип инверсии зависимостейМодули верхних уровней не должны зависеть от

Dependency inversion principlepublic class Man { private Car car; public void

Dependency inversion principlepublic class Man { private Mode mode; public void

Dependency inversion principle

Law of DemeterЗакон Деметры (принцип наименьшего знания)Каждый модуль должен обладать ограниченным

Принцип YAGNIYou ain’t gonna need itРеализуйте что-то, только если оно вам

Принцип KISSKeep it simple, stupidKeep it simple and stupidKeep it short

Спасибо за внимание!

Похожие презентации

План лекции
Отношения между классами
Объектно-ориентированный дизайн
Принципы дизайна

Отношения между классами
Наследование
Зависимость
Ассоциация
Агрегация
Композиция
Метакласс

Особенности
Использование одним классом структуры и/или поведения другого класса
Дочерний класс специализирует родительский

Особенности
Изменение в одном классе (независимом) может влиять на другой класс (зависимый)
Зависимый

Особенности
Семантическая связь классов
Мощность
Один к одному
Один ко многим
Многие к одному
Многие ко

Особенности
Можно считать частным случаем ассоциации
Образуется отношение «целое-часть» между объектами
Агрегат (контейнер) –

Особенности
Можно считать частным случаем агрегации
Время жизни объектов-частей определяется объектом-контейнером и не

Особенности
Метакласс – это класс, объектами которого являются классы
Корневой метакласс – единственный

Ещё одна проблема разработки программ в ООП
Этапы разработки (условно)
Определение модели данных
Определение

Object-oriented design
Объектно-ориентированное проектирование – планирование системы как совокупности взаимодействующих объектов с

Характеристики дизайна
Coupling (связанность, зависимость)
Характеристика взаимосвязи модулей
Степень того, насколько модуль зависит от других

Виды связанности
Связанность содержимого (content coupling)-
Один модуль изменяет или полагается на внутренние

Виды связанности
Связанность через внешнее (external coupling)
Два модуля используют навязанный извне формат данных,

Виды связанности
Связанность по структурированным данным (data-structured coupling, stamp coupling)
Модули используют одну

Виды связанности
Связанность по сообщениям (message coupling)
Модули общаются только через передачу параметров

Виды сфокусированности
Случайная (coincidental cohesion)
Части модуля сгруппированы «от фонаря»
Единственное, что их объединяет

Виды сфокусированности
По взаимодействию (communication cohesion)
Части модуля работают над одними и теми

Плохой дизайн
Высокая связанность
Эффект кругов по воде (или снежной лавины) при внесении

Хороший дизайн
Loose coupling
High cohesion
Правда, эти требования друг другу противоречат
И следует это

Принципы SOLID
Single responsibility principle
Open/closed principle
Liskov substitution principle
Interface segregation principle
Dependency inversion principle

Принципы SOLID
http://lostechies.com/derickbailey/2009/02/11/solid-development-principles-in-motivational-pictures/

Single responsibility principle
Принцип единственности ответственности
Каждый класс должен иметь единственную ответственность
Эта ответственность

Single responsibility principle
public class Service{
public static Image getImage(String fileName) {

Single responsibility principle
public class ImageService{
public static Image getImage(String fileName) {

Open/closed principle
Принцип открытости/закрытости
Программные сущности (классы, модули и т.п.) должны быть открыты

Open/closed principle
public class MessageSender {
...
public void send(Message msg)

Open/closed principle
public class MessageSender {
...
public void send(Message msg){

Liskov substitution principle
Принцип подстановки Барбары Лисковой
Пусть q(x) является свойством, верным относительно

Liskov substitution principle
public class Rectangle{
double height, width;
// методы set

Liskov substitution principle
public class Square extends Rectangle{
public void setHeight(double h)

Interface segregation principle
Принцип разделения интерфейсов
Клиенты не должны зависеть от методов, которые

Dependency inversion principle
Принцип инверсии зависимостей
Модули верхних уровней не должны зависеть от

Dependency inversion principle
public class Man {
private Car car;
public void

Dependency inversion principle
public class Man {
private Mode mode;
public void

Law of Demeter
Закон Деметры (принцип наименьшего знания)
Каждый модуль должен обладать ограниченным

Принцип YAGNI
You ain’t gonna need it
Реализуйте что-то, только если оно вам

Принцип KISS
Keep it simple, stupid
Keep it simple and stupid
Keep it short