Как писать красивый код или основы SOLID

4,969
-1

Published on

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

Published in: Technology
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,969
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
73
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide

Как писать красивый код или основы SOLID

  1. 1. Как писать красивый код или основы S.O.L.I.D.Пинин Денисdpinin@codereign.net
  2. 2. Что такое S.O.L.I.D.?S - Single Responsibility Principle (SRP) (принцип единой ответственности)O - Open/Closed Principle (OCP) (принцип «открыто/закрыто»)L - Liskov Substitution Principle (LSP) (принцип замещения Лискоy)I - Interface Segregation Principle (ISP) (принцип разделения интерфейса)D - Dependency Inversion Principle (DIP) (принцип инверсии зависимостей)
  3. 3. Зачем соблюдать принципы S.O.L.I.D.?• Помогают построить архитектуру приложения, которое со временем будет проще (дешевле) поддерживать и развивать.• Помогаю писать повторно используемый код. Принципы != Правила
  4. 4. Принцип единой ответственности (SRP) Формулировка: не должно быть больше одной причины для изменения класса Почему? Потому что это ведет к хрупкости дизайна (пишем один «функционал» - отваливается другой)
  5. 5. А может не надо?Неееет….
  6. 6. Самый главный нарушительSRP – God Object: Как писать красивый код или основы S.O.L.I.D.Пинин Денисdpinin@codereign.net
  7. 7. Нарушитель побежден!
  8. 8. Принцип открытости/закрытости (OCP) Формулировка: программные сущности(классы, модули, функции и т.д.) должны быть открыты для расширения, но закрыты для изменения Почему? Потому что позволяет быстро и безболезненно реагировать на изменения бизнес-логики
  9. 9. Чем плох этот код? Заказчик: Лог продаж в файлах!? Это же отстой! Изменение требований: лог надо хранить в БД. Разработчик: Нет проблем!
  10. 10. Нарушаем принцип OCP!
  11. 11. А так лучше?
  12. 12. Принцип замещения Лисков (OCP) Формулировка №1: если для каждого объекта o1 типа S существует объект o2 типа T, который для всех программ P определен в терминах T, то поведение P не изменится, если o1 заменить на o2 при условии, что S является подтипом T. (ничего не понятно)Формулировка №2: подтипы должны быть заменяемы базовыми типами. Почему? Потому что клиентский код начинает считать производный класс разновидностью базового, и возможно появление кода, явно использующего этот факт
  13. 13. Ошибочное наследованиеПопробуем протестировать
  14. 14. Прямоугольник или квадрат?
  15. 15. Принцип разделения интерфейса (ISP) Формулировка: клиенты не должны зависеть от методов, которые они не используют Потому что если мы определим большой Почему? универсальный интерфейс, тогда в наследниках возможно появление множества заглушек, а соответственно, много лишнего кода, который неудобно поддерживать
  16. 16. Как бывает в жизни… (я точно видел)
  17. 17. А так надо… (я стараюсь так делать :-) )
  18. 18. Принцип инверсии зависимости (DIP)Формулировка:• Модули верхнего уровня не должны зависеть от модулей нижнего уровня. Оба должны зависеть от абстракции.• Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций. Почему? Потому что возникает паутина зависимостей, превращая реализацию очередного изменения требований в настоящий кошмар.
  19. 19. Класс который слишком много знал…• Знает, как вычислить сумму заказа;• Знает, как и каким калькулятором вычислить сумму скидки;• Знает, что означают коды стран;• Знает, каким образом вычислить сумму налога для той или иной страны;• Знает формулу, по которой из всех слагаемых вычисляется стоимость заказа.
  20. 20. И что с ним стало… до… UI Layer Business Layer DataAccess Layer после… Business Layer UI Layer Interface DataAccess Layer Business Layer Interface DataAccess Layer
  21. 21. От чего мы хотим убежать? Жесткость Хрупкость Неподвижность Жесткость - изменение одной части кода затрагивает слишкоммного других частей; Хрупкость - даже незначительное изменение в коде можетпривести к совершенно неожиданным проблемам; Неподвижность - никакая из частей приложения не может бытьлегко выделена и повторно использована.
  22. 22. Только S.O.L.I.D.? CRPREP CCP ADP SDP SAP
  23. 23. ВОПРОСЫ?

×