SOLID Principles in the real world
Download as PPTX, PDF0 likes911 views
Документ обсуждает принципы проектирования в программировании, особенно принцип SOLID, который включает такие аспекты, как единственная ответственность и открытость для расширения. Автор подчеркивает важность применения этих принципов для упрощения дизайна и уменьшения сложности программных систем. Основной тезис заключается в том, что принципы должны служить инструментом улучшения проектирования, а не стать самоцелью.
![Обо мне
• Microsoft C# MVP 2011-2014
• MSFT Employee 2014- (VS Team)
• Blogger: SergeyTeplyakov.blogspot.com
• Контакты
• Sergey.Teplyakov [sobak] gmail.com
• @STeplyakov](https://image.slidesharecdn.com/solidprinciples-140930034142-phpapp02/85/SOLID-Principles-in-the-real-world-2-320.jpg)
SOLID Principles in the real world
- 1. О принципах проектирования Сергей Тепляков
- 2. Обо мне • Microsoft C# MVP 2011-2014 • MSFT Employee 2014- (VS Team) • Blogger: SergeyTeplyakov.blogspot.com • Контакты • Sergey.Teplyakov [sobak] gmail.com • @STeplyakov
- 3. О чем будем говорить? • О принципах проектирования в целом • О SOLID принципах
- 4. Нужны ли нам принципы проектирования?
- 5. Дизайн – штука сложная!
- 6. Поиск серебряной пули • Ответ на вопрос жизни вселенной и всего такого?
- 7. Мы хотим использовать опыт и знания повторно!
- 8. Классические подходы • Low coupling • High cohesion • Design by Contract
- 9. SOLID принципы • S – Single Responsibility Principle • O – Open-Closed Principle • L – Liskov Substitution Principle • I – Interface Segregation Principle • D – Dependency Inversion Principle
- 10. Опасности принципов • Что «сильнее» композиция или наследование? • Остерегайтесь культа карго
- 11. В чем проблема с текущим описанием? • Принципы слишком неформальны • Берут свое начало в 90-х (С++) • Не ясно, когда им следовать, а когда - нет
- 12. Как следовать этим принципам? Принципы существуют для того, чтобы помогать в устранении дурных запахов в дизайне. Это не духи, которыми надо обильно поливать всю систему. Чрезмерная приверженность принципам ведет к пороку ненужной сложности.
- 13. Single Responsibility Principle • Исходное определение: У класса должна быть только одна причина для изменения • Смысл принципа SRP: Борьба со сложностью • SRP violation means low cohesion! http://bit.ly/SingleResponsibilityPrinciple
- 14. Любой класс из реального мира будет нарушать SRP
- 15. Типичные примеры нарушения SRP
- 16. Смешивание логики и инфраструктуры • Windows сервис ходит в базу • WCF-сервис сам содержит логику обработки запросов • Azure Role содержит логику по перекладыванию данных из одного места в другое. • Смешивание логики и «сохраняемости» (persistence)
- 17. Смешивание логики и представления
- 18. Выделяйте каждому сложному аспекту системы свой класс/модуль
- 19. Я хочу иметь возможность сосредоточиться на сложных аспектах системы по отдельности, поэтому когда мне становится сложно это делать, я начинаю разбивать классы и выделять новые.
- 20. Дизайн – это эволюционный процесс
- 21. Актуальность SRP возрастает вместе с увеличением сложности!
- 22. Пример увеличения сложности: добавление предусловий
- 23. Интерфейс ContextActionBase public abstract class ContextActionBase { public abstract void Execute(); public abstract bool IsAvailable(); public abstract string Text { get; } }
- 25. Эволюция дизайна
- 26. SRP – это способ поиска скрытых абстракций, достаточно сложных, чтобы им отвели отдельную именованную сущность и спрятали в их недрах все детали.
- 27. Open-Closed Principle Классы, модули, функции и т.п.) должны быть открытыми для расширения, но закрытыми для модификации http://bit.ly/OpenClosedPrinciple
- 28. Как вы понимаете OCP?
- 29. Объяснение Боба Мартина • Они открыты для расширения. Это означает, что поведение модуля можно расширить. Когда требования к приложению изменяются, мы добавляем в модуль новое поведение, отвечающее изменившимся требованиям. Иными словами, мы можем изменить состав функций модуля. • Они закрыты для модификации. Расширение поведения модуля не сопряжено с изменениями в исходном или двоичном коде модуля. Двоичное исполняемое представление модуля, будь то компонуемая библиотека, DLL или EXE-файл, остается неизменным (выделено мною).
- 30. Нарушает ли фабрика OCP? abstract class Importer { public abstract void ImportData(); } static class ImporterFactory { public static Importer Create(string fileName) { var extension = Path.GetExtension(fileName); switch (extension) { case "json": return new JsonImporter(); case "xls": case "xlsx": return new XlsImporter(); default: throw new InvalidOperationException("Extension is not supported"); } } }
- 31. Принцип единственного выбора Всякий раз, когда система программного обеспечения должна поддерживать множество альтернатив, их полный список должен быть известен только одному модулю системы. Бербран Мейер
- 33. Определение от Бертрана Мейера • Модуль называют открытым, если он еще доступен для расширения. Например, имеется возможность расширить множество операций в нем или добавить поля к его структурам данных. • Модуль называют закрытым, если он доступен для использования другими модулями. Это означает, что модуль (его интерфейс – с точки зрения скрытия информации) уже имеет строго определенное окончательное описание. На уровне реализации закрытое состояние модуля означает, что модуль можно компилировать, сохранять в библиотеке и делать его доступным для использования другими модулями (его клиентами).
- 34. Open-Closed Principle • Что такое OCP? Это фиксация интерфейса класса/модуля, и возможность изменения или подмены реализации/поведения. • Цели OCP: борьба со сложностью и ограничение изменений минимальным числом модулей. • Как мы реализуем OCP? С помощью инкапсуляции, которая позволяет изменять реализацию без изменения интерфейса и с помощью наследования, что позволяет заменить реализацию, которая не затронет существующих клиентов базового класса.
- 35. Типичный пример нарушения расширяемости (OCP) public static int Count<TSource>(this IEnumerable<TSource> source) { var collectionoft = source as ICollection<TSource>; if (collectionoft != null) return collectionoft.Count; var collection = source as ICollection; if (collection != null) return collection.Count; int count = 0; using (IEnumerator<TSource> e = source.GetEnumerator()) { while (e.MoveNext()) count++; } return count; }
- 36. Расширяемость: OOP vs. FP • В ООП: легко добавлять новый тип, сложно – новую операцию • В ФП: легко добавлять новую операцию, сложно – новый тип Expression Problem!
- 38. Иногда мы хотим вынести логику за пределы иерархии! Решение: Посетитель!
- 39. Пример
- 40. public interface IValidationResultVisitor { void Visit(NoErrorValidationResult vr); void Visit(ContractErrorValidationResult vr); void Visit(ContractWarningValidationResult vr); void Visit(CustomWarningValidationResult vr); } public abstract class ValidationResult { private ICSharpStatement _statement; protected ValidationResult(ICSharpStatement statement) { Contract.Requires(statement != null); _statement = statement; } public abstract void Accept(IValidationResultVisitor visitor); }
- 41. class IsIssueFixableVisitor : IValidationResultVisitor { public bool IsIssueFixable { get; private set; } public void Visit(NoErrorValidationResult vr) { IsIssueFixable = false; } public void Visit(ContractErrorValidationResult vr) { IsIssueFixable = vr.Error == MalformedContractError.VoidReturnMethodCall; } public void Visit(ContractWarningValidationResult vr) { IsIssueFixable = vr.Warning == MalformedContractWarning.NonVoidReturnMethodCall; } public void Visit(CustomWarningValidationResult vr) { IsIssueFixable = false; } }
- 42. ФП подход: сопоставление с образцом public T Match<T>( Func<CodeContractErrorValidationResult, T> errorMatch, Func<CodeContractWarningValidationResult, T> warningMatch, Func<ValidationResult, T> defaultMatch) { var errorResult = this as CodeContractErrorValidationResult; if (errorResult != null) return errorMatch(errorResult); var warningResult = this as CodeContractWarningValidationResult; if (warningResult != null) return warningMatch(warningResult); return defaultMatch(this); }
- 43. Пример использования ValidationResult vr = GetValidationResult(); bool isFixable = vr.Match( error => error.Error == MalformedContractError.VoidReturnMethodCall, warning => warning.Warning == MalformedContractWarning.NonVoidReturnMethodCall, @default => false);
- 44. Как пользуюсь принципами? • Принципы – не самоцель! • Дизайн постоянно эволюционирует. Валидируйте его согласно этим принципам на каждой итерации.
- 45. Цикл постов о SOLID-принципах • http://bit.ly/SingleResponsibilityPrinciple • http://bit.ly/OpenClosedPrinciple • http://bit.ly/LiskovSubstitutionPrinciple • http://bit.ly/InterfaceSegregationPrinciple • http://bit.ly/DependencyInversionPrinciple
- 46. Чего почитать по теме • О культе карго в программировании sergeyteplyakov.blogspot.com/2013/09/blog-post_24.html • Критика книги Боба Мартина «Принципы, паттерны и методики гибкой разработки на языке C#» sergeyteplyakov.blogspot.com/2013/12/about-agile-principles-patterns-and.html • Цикл постов об управлении зависимостями http://sergeyteplyakov.blogspot.com/2013/10/articles.html#dependency_manage ment • Лучшая книга по ООП эвар! – Бертран Мейер «Объектно-ориентированное конструирование программных систем» http://sergeyteplyakov.blogspot.com/2012/03/blog-post_19.html