Документ описывает принципы объектно-ориентированного дизайна и рефакторинга, уделяя внимание тому, как достичь правильного дизайна и взаимодействия объектов. Основное внимание уделяется принципам SOLID и методам рефакторинга, рассматриваются ошибки, возникающие при их нарушении. В заключение поднимается вопрос дублирования кода и необходимости создания гибких интерфейсов.

1. Рефакторинг и объектно-ориентированный дизайнIngate Development2011

2. Обращаться с языком кое-как — значит и мыслить кое-как: приблизительно, неточно, неверно.А. Н. Толстой.Код программы чаще читается, чем пишется.Народная мудрость.Цель: узнать, что такое правильный объектно-ориентированный дизайн программного обеспечения и какими способами его можно достигать.Ingate Development \ 2011

3. О чем поговорим?Обсудим, что такое правильный дизайн и как его добиться.

4. Ответ на вопрос «что» дают принципы объектно-ориентированного дизайна и паттерны.

5. Ответ на вопрос «как» дают техники рефакторинга.

6. Будем в первую очередь разбираться в причинах того или иного варианта определения объектов и их взаимодействия.

7. Поговорим о том, что идеального дизайна не существует и каждому из вас предстоит нелегкая задача поиска баланса между нарушениями разных принципов.Ingate Development \ 2011

8. О чем не будем говорить?Не будем разбирать конкретные паттерны объектно-ориентированного проектирования

9. Не будем перечислять конкретные техники рефакторинга

10. Хотя и паттерны и рефакторинг будем часто использовать в примерах.

11. Не будем разбирать принципы объектно-ориентированного подхода.

12. Не будем анализировать плюсы и минусы объектно-ориентированного подхода. Будем считать, что раз вы сюда пришли, то выбор вы для себя уже сделали.Ingate Development \ 2011

13. ОО дизайнSOLID – этоаббревиатура пяти основных принципов дизайна в объектно-ориентированном проектировании. В дополнение к этому, рассмотрим еще шестой принцип, который не входит в эту аббревиатуру.Ingate Development \ 2011

14. РефакторингРефакторинг (англ. refactoring) — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы.В основе рефакторинга лежит последовательность небольших эквивалентных (то есть сохраняющих поведение) преобразований.Поскольку каждое преобразование маленькое, программисту легче проследить за его правильностью, и в то же время вся последовательность может привести к существенной перестройке программы и улучшению её согласованности и четкости.WikipediaIngate Development \ 2011

15. Single Responsibility PrincipleПринцип единственной обязанностиIngate Development \ 2011

16. Single Responsibility PrincipleВ объектно-ориентированном программировании, принцип единственной обязанности обозначает, что каждый объект должен иметь одну обязанность и эта обязанность должна быть полностью инкапсулирована в класс.WikipediaНе должно существовать более одного мотива для изменения класса.Роберт МартинIngate Development \ 2011

17. Single Responsibility PrincipleIngate Development \ 2011

18. Single Responsibility PrincipleСвязность (cohesion):насколько сильно связаны и сонаправлены различные обязанности модуляСвязанность (coupling):степень, в которой программный модуль зависит от других модулейСтремитесь к слабой связанности, но к сильной связности модулейIngate Development \ 2011

19. Single Responsibility PrincipleИзменения в требованиях обычно влекут за собой изменение обязанностей

20. Чем больше обязанностей у класса – тем больше вероятность его изменения

21. Несколько обязанностей в пределах одного класса делают эти обязанности взаимозависимыми

22. Чем больше классов затронет изменение, тем больше ошибок при этом наделаютIngate Development \ 2011

23. Single Responsibility PrincipleПример нарушения принципаIngate Development \ 2011

24. Single Responsibility PrincipleОписание проблемыОплата наличными не требует операций с кредитками

25. Операции в розничной системе продаж не требуют резервирования товара на складе

26. Операции на сайте не требуют отчисления бонусов торговому менеджеру

27. При этом любые изменения в систему процессинга платежей, систему резервирования товаров или начисления бонусов затрагивает Order, а соответственно и оба модуля Web и SaleSystemIngate Development \ 2011

28. Single Responsibility PrincipleРефакторингIngate Development \ 2011

29. Open/Closed PrincipleПринцип открытости/закрытостиIngate Development \ 2011

30. Open/Closed PrincipleСущности в программе (классы, модули, функции и т.п.) должны быть открыты для расширения, но закрыты для изменения. WikipediaIngate Development \ 2011

31. Open/Closed PrincipleIngate Development \ 2011

32. Open/Closed PrincipleОткрыты для расширенияНовая функциональность может быть добавлена в будущемЗакрыты для измененияИзменения в исходниках или бинарных сборках не требуются для добавления функциональностиПринцип впервые описан Бертраном Мейером в 1988 г.Ingate Development \ 2011

33. Open/Closed PrincipleПример нарушения принципаIngate Development \ 2011

34. Open/Closed PrincipleОписание проблемыДобавление новых правил каждый раз требует изменения калькулятора

35. Каждое изменение может наплодить багов и требует повторного тестирования

36. Добавление новых классов в меньшей степени чревато проблемами:

37. Нет кода, который зависит от новых классов (пока)

38. Новые классы не имеют исторической связанности, которая затрудняет их проектирование и тестированиеIngate Development \ 2011

39. Open/Closed PrincipleТри подхода к достижению OCPИспользование параметров

40. Дайте клиентам возможность контролировать поведение через дополнительные параметры

41. В сочетании с делегатами/лямбда-выражениями можно добиться очень хорошего результата

42. Использование наследования

43. Потомки определяют (доопределяют) поведение базового класса / интерфейса

44. Использование паттерна «Стратегия»

45. Клиентский код зависит от абстракции

46. Используется модель «plug in», которая позволяет переопределять поведение, заменив абстракциюIngate Development \ 2011

47. Open/Closed PrincipleРефакторингIngate Development \ 2011

48. Open/Closed PrincipleПонимание приходит с опытомЕсли ваш собственный опыт в предметной области подсказывает вам, что определенные изменения будут повторяться – примените OCP сразу при проектировании

49. Если модуль изменяется в первый раз – нарушьте принцип и просто измените реализацию

50. Если модуль изменяется повторно – примените рефакторинг для достижения OCP

51. Бесплатный сыр бывает только в мышеловке:OCP всегда усложняет дизайн

52. И помните:нет такого дизайна, который бы был закрыт от всех измененийIngate Development \ 2011

53. Liskov substitution principleПринцип подстановки ЛисковойIngate Development \ 2011

54. Liskov substitution principleФункции, которые используют ссылки на базовые классы, должны иметь возможность использовать объекты производных классов, не зная об этом.Роберт МартинНазван так в честь Барбары Лисковой, которая описала этот принцип впервые в 1988 г.Ingate Development \ 2011

55. Liskov substitution principleIngate Development \ 2011

56. Liskov substitution principleПотомки (дочерние классы) не должны:убирать поведение предков

57. нарушать контрактные обязательства предковИ вообще код при использовании потомков не должен знать, что он оперирует не предком, а чем-то еще.Ingate Development \ 2011

58. Liskov substitution principleОбычнопод наследованием понимают отношение«ISA»

59. Strawberry IS A berry

60. Клубника – это ягода

61. С точки зрения принципа подстановки Лисковой правильнее говорить об отношении«IS SUBSTITUTABLE FOR»

62. Strawberry IS SUBSTITUTABLE FOR berry

63. Клубника может быть использована как ягода

64. И тогда не будет неожиданностей…

65. Волчья ягода – это ягода

66. Волчья ягода может быть использована как ягодаIngate Development \ 2011

67. Liskov substitution principleТипичное нарушение принципаabstractclassBase {publicabstractvoid Method1();publicabstractvoid Method2();}classDerived : Base {publicoverridevoid Method1() {thrownewNotImplementedException(); } publicoverridevoid Method2() {// do something}} Ingate Development \ 2011

68. Liskov substitution principleТипичное нарушение принципаpublicvoidPrint(Employeeperson) {if(person isProgrammer) {_printer.PrintProgrammer(person);} elseif (person isManager) {_printer.PrintManager(person);}} Ingate Development \ 2011