Recommended
Recommended
More Related Content
What's hot
What's hot (18)
Viewers also liked
Viewers also liked (13)
Similar to математическое обоснование Solid принципов. Конференция dotnetconf (Челябинск, апрель 2015)
Similar to математическое обоснование Solid принципов. Конференция dotnetconf (Челябинск, апрель 2015) (20)
More from etyumentcev
More from etyumentcev (19)
математическое обоснование Solid принципов. Конференция dotnetconf (Челябинск, апрель 2015)
- 1. Математическое обоснование SOLID принципов Евгений Тюменцев HWdTech, LLC hwdtech.ru 10-я конференция .NET разработчиков 19 апреля 2015 dotnetconf.ru
- 2. 2 Докладчик Тюменцев Евгений 14 лет преподаю ИМИТ, ФКН ОмГУ ИТ-компании Школа программиста 10 лет разрабатываю ПО разработчик, архитектор, PM, руководство до 70 человек
- 3. 3 SOLID 5 архитектурных принципов 1988 г. Б. Мейер впервые описал 1995-96 г. Р. Мартин популяризировал, ввел термин SOLID
- 4. 4 The Open-Closed Principle Программные объекты должны быть открыты для расширения, но в тоже время закрыты для модификации.
- 5. 5 The Liskov Substitution Principle Функции, которые используют ссылки на объекты базовых классов, должны использовать объекты производных классов, ничего не зная о них.
- 6. 6 The Dependency Inversion Principle Высокоуровневые компоненты не должны зависеть от низкоуровневых компонент. И те, и те должны зависеть от абстракций (оператора расширения).
- 7. 7 The Interface Segregation Principle Класс не должен зависеть от интерфейсов, которые он не использует
- 8. 8 The Single Responsibility Principle Должна быть ровно одна причина для изменения класса
- 9. 9 Нарушают SOLID принципы enum switch if – else – if операторы приведения типа new
- 10. 10 Что-о-о? switch, new? Ты кто такой?
- 11. 11 Выводимость Пусть L – множество формул, B – формула. Тогда L ⊦ B, если ∃ B1, B2, …, Bn , что 1.Bn – это B, 2.Bi – это либо формула из L, либо аксиома, либо общезначимая формула, либо формула полученная при помощи правила вывода
- 13. 13 Modus Ponens (правило вывода)
- 14. 14 Логика Хоара 1969 г. An Axiomatic Basis for Computer Programming 1971 г. Procedures and Parameters: An Axiomatic Approach 1980 г. премия Тьюринга 1990 г. Медаль “Пионер компьютерной техники” 2000 г. рыцарский титул за заслуги в области образования и компьютерной техники, премия Киото Чарльз Хоар
- 15. 15 Тройка Хоара {pred} statement {post} Пример: {x == 42} y=x+1; {y == 43 ^ x == 42}
- 16. 16 Аксиома пустого оператора {P} skip {P}
- 17. 17 Аксиома оператора присваивания Пример: {(y+1)*3+w*(y+1+3) ==z} x=y+1; { x*3+ w*(x+3)==z} {P[E/x]} x := E {P}
- 18. 18 Аксиома оператора цикла {P ^ B} S {P} ╞ {P} while B do S done {B’ ^ P}
- 19. 19 Аксиома условного оператора {B ^ P} S {Q}, {B’ ^P} T {Q}╞ {P} if B then S else T endif {Q} {B ^ P} S {Q}╞ {P} if B then S endif {Q}
- 20. 20 Аксиома композиции {P} S {Q}, {Q} T {R} ╞ {P} S;T {R}
- 21. 21 Аксиомы вывода P1 → P, {P} S {Q}, Q → Q1 ╞ {P1} S {Q1} P1 → P, {P} S {Q} ╞ {P1} S {Q} {P} S {Q}, Q → Q1 ╞ {P} S {Q1}
- 22. 22 Акиомы вывода согласуются с условным оператором Пусть L = {{P} f {Q}}, B – предикат. P^B→P (A3 ИВ) {P^B}f{Q} (аксиома вывода) {P}if (B) then f endif {Q} (аксиома условного оператора)
- 23. 23 Неявные предположения {P ^ B} с {Q} {P} assert(B); c {Q}
- 24. 24 Упрощение кода и аксиома вывода node* insert(node& c, int v) { node *n = new node; n -> val = v; if(c.next) { n -> next = c.next; } else { n -> next = 0; } c.next = n; return n; } null
- 25. 25 Как упростить операцию insert? P = c – последний V с – непоследний {P} insert(c, x) {Q}
- 26. 26 Как упростить операцию insert? P = c – последний V с – непоследний {P} insert(c, x) {Q} Если B = {∀с с – непоследний} – инвариант P^B→P, {P}insert(c,x){Q} ⊦ {P^B}insert(c,x){Q}
- 27. 27 Как упростить операцию insert? P = c – последний V с – непоследний {P} insert(c, x) {Q} Если B = {∀с с – непоследний} – инвариант P^B→P, {P}insert(c,x){Q} ⊦ {P^B}insert(c,x){Q} Но! P^B = c- непоследний {c - непоследний} insert(c,x) {Q}
- 28. 28 Закольц. список с буф. элементом node* insert(node& c, int v) { node *n = new node; n -> val = v; if(c.next) { n -> next = c.next; } else { n -> next = 0; } c.next = n; return n; }
- 29. 29 Закольц. список с буф. элементом node* insert_before(node& c, int v) { node *n = new node; n -> val = v; n -> next = c.next; c.next = n; return n; }
- 30. 30 Следствия аксиомы композиции {P} S {Q}, {Q} T {R} ╞ {P} S;T {R}
- 31. 31 Контрактное программирование • Предусловия • Постусловия • Инварианты
- 33. 33 Рефакторинг {P} S {Q}, {Q} T {R} ╞ {P} S;T {R}
- 34. 34 Повторное использование Повторное использование кода — методология проектирования компьютерных и других систем, заключающаяся в том, что система (компьютерная программа, программный модуль) частично либо полностью должна составляться из частей, написанных ранее компонентов и/или частей другой системы, и эти компоненты должны применяться более одного раза (если не в рамках одного проекта, то хотя бы разных). https://ru.wikipedia.org/wiki/Повторное_использование_кода
- 35. 35 А можно ли по-другому? Выводимость прямо предписывает строить новые тройки из предыдущих!
- 36. 36 Когда происходит повторное использование? Если нужно внести изменение в существующее приложение, то мы пытаемся повторно использовать свой же собственный код, чтобы получить тоже приложение, но с новой функциональностью.
- 37. 37 Чем грозят правки кода? B1, B2, …, A1 B3, A1, …, A2 B5, A2, …, A3 A2, B6, …, A4 A2, A4, …, A5
- 38. 38 Чем грозят правки кода? B1, B2, …, A1 B3, A1, …, A2 B5, A2, …, A3 A2, B6, …, A4 A2, A4, …, A5
- 39. 39 The Open-Closed Principle Программные объекты должны быть открыты для расширения, но в тоже время закрыты для модификации.
- 40. 40 Пример: матрицы class matrix { int size; double *body; public: matrix(int s): size(s) { body = new double[s*s]; } void transform() { … } double det() const { … } };
- 41. 41 Матрицы: добавляем matrix() class matrix { int size; double *body; public: matrix(int s): size(s) { body = new double[s*s]; } void transform() { … } double det() const { … } }; class matrix { public: matrix(): size(0), body(0) { } };
- 42. 42 Придется менять методы class matrix { int size; double *body; public: matrix(): size(0), body(0) { } matrix(int s): size(s) { body = new double[s*s]; } void transform() { if(!body) throw exception(); … } double det() const { if(!body) throw exception(); … } };
- 43. 43 Что случилось? Инвариант класса matrix: size > 0 Конструктор matrix() нарушил инвариант: size = 0
- 44. 44 Что случилось? Инвариант класса matrix: size > 0 Конструктор matrix() нарушил инвариант: size = 0 Предусловия методов изменились с size > 0 на size ≥ 0, но
- 45. 45 Что случилось? Инвариант класса matrix: size > 0 Конструктор matrix() нарушил инвариант: size = 0 Предусловия методов изменились с size > 0 на size ≥ 0, но {size ≥ 0} det {Q} не выводится из {size > 0} det {Q}
- 46. 46 Что случилось? Инвариант класса matrix: size > 0 Конструктор matrix() нарушил инвариант: size = 0 Предусловия методов изменились с size > 0 на size ≥ 0, но {size ≥ 0} det {Q} не выводится из {size > 0} det {Q} Следовательно, надо изменять сами методы
- 47. 47 Конструкторы по умолчанию Конструктор должен устанавливать инвариант класса Конструкторы по умолчанию часто расширяют допустимые значения параметров Стоит несколько раз подумать, прежде чем использовать конструктор по умолчанию
- 49. 49 Импликация на множестве Пусть P1 → P, B = { x | P1(x) = 1}, A = { x | P (x) = 1}. Тогда B ⊂ A. P ⊨ P1. Говорят, что P – более слабое условие, P1 – более сильное. A B
- 50. 50 Построим вывод {S} cb {P}, {P} c {Q}, {Q} ca {R} ⊦ {S} cb; c; ca {R}
- 51. 51 Построим вывод {S} cb {P}, {P} c {Q}, {Q} ca {R} ⊦ {S} cb; c; ca {R} Пусть P → P1, Q1 → Q Известно, что {S} cb {P}, {P1} c {Q1}, {Q} ca {R}
- 52. 52 Построим вывод {S} cb {P}, {P} c {Q}, {Q} ca {R} ⊦ {S} cb; c; ca {R} Пусть P → P1, Q1 → Q Известно, что {S} cb {P}, {P1} c {Q1}, {Q} ca {R} Тогда {P} c {Q} (аксиома вывода) {S} cb; c; ca {R}
- 53. 53 The Dependency Inversion Principle Высокоуровневые компоненты не должны зависеть от низкоуровневых компонент. И те, и те должны зависеть от абстракций (оператора расширения).
- 54. 54 Иначе {S} cb {P}, {P} c {Q}, {Q} ca {R} ⊦ {S} cb; c; ca {R}
- 55. 55 Иначе {S} cb {P}, {P} c {Q}, {Q} ca {R} ⊦ {S} cb; c; ca {R} Пусть P ↛ P1, но P ^ P1 → P1 Известно, что {S} cb {P}, {P1} c {Q}, {Q} ca {R}
- 56. 56 Иначе {S} cb {P}, {P} c {Q}, {Q} ca {R} ⊦ {S} cb; c; ca {R} Пусть P ↛ P1, но P ^ P1 → P1 Известно, что {S} cb {P}, {P1} c {Q}, {Q} ca {R} Тогда {P1} c {Q} ⊦ {P} if (P1) then c endif {Q} {S} cb; if(P1) then c endif; ca {R}
- 57. 57 Правило оператора расширения Оператор расширения должен допускать: 1. Ослабление предусловий 2. Усиление постусловий
- 59. 59 Как выглядит оператор расширения? 1. Статический полиморфизм template <class It, class Op> void for_each(It begin, It end, Op op) { for(; begin != end; ++begin) op(*begin); } int arr[] = {1, 2, 3, 4, 5}; for_each(arr, arr+6, max<int>());
- 60. 60 Как выглядит оператор расширения? 2. Во время выполнения указатель на функцию void (*f) (int i); f pf; pf(5); динамический полиморфизм class Shape { public: virtual void Draw() = 0; }; shape->Draw();
- 61. 61 Как выглядит оператор расширения? 3. Метапрограммирование void Counter::setValue(int value) { if (value != m_value) { m_value = value; emit valueChanged(value); } }
- 62. 62 Что такое класс? Это набор связанных методов, возможно, полиморфных
- 63. 63 The Liskov Substitution Principle Функции, которые используют ссылки на объекты базовых классов, должны использовать объекты производных классов, ничего не зная о них.
- 66. 66 The Interface Segregation Principle Класс не должен зависеть от интерфейсов, которые он не использует
- 67. 67 А не для классов? bool (*validator) (Document const & doc); std::vector<validator> rules = …; for (int i = 0; i < n; ++i) if(!rules[i](document)) return false; return true;
- 68. 68 В каком случае гарантированно удастся избежать жирного интерфейса?
- 69. 69 The Single Responsibility Prinsiple Должна быть ровно одна причина для изменения класса
- 70. 70 Мы пишем книги Нерассказанные факты об императивном программировании oopguide.ru Разработка серверов и серверных приложений actorsmodel.ru
- 71. 71 Спасибо за внимание Евгений Тюменцев HWdTech, LLC etyumentcev@hwdtech.ru slideshare.com/etyumentcev