О сложном просто или программирование на .NET

На тему из первой статьи снял видео, с комментариями и дополнениями.

В этом видео про: calabonga, программирование, обучение, tutorial, SOLID, ООП, OOP, объектно-ориентирование программирование, патерны, design patterns, Single, Responsability, Open Close, Liskov Substitution, Interface Segregation Principle, Dependecny Injection

В этом видео про: design patterns, Interface Segregation Principle, шаблоны проектирования, development, патерны, принципы, разработка, tutorial, OOP, Dependecny Injection, Liskov Substitution, правила, обучение, Single, Responsability, SOLID, calabonga, ООП, CSharp, программирование, Open Close, объектно-ориентирование программирование

В этом видео про: calabonga, программирование, обучение, tutorial, SOLID, ООП, OOP, объектно-ориентирование программирование, патерны, design patterns, Single, Responsability, Open Close, Liskov Substitution, Interface Segregation Principle, Dependecny Injection

В этом видео про: calabonga, программирование, обучение, tutorial, SOLID, ООП, OOP, объектно-ориентирование программирование, патерны, design patterns, Single, Responsability, Open Close, Liskov Substitution, Interface Segregation Principle, Dependecny Injection

Как-то не получилось у меня с первого раза найти информацию о том, как же надо применять SOLID на практике. Вот и решил самостоятельно написать статью, но...

Как часто вам необходимо знать, какие действия были произведены с определенной сущностью? Например, в какой момент поменялось значение какого-либо свойства?

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

Построение сложных и не очень сложных систем задача не тривиальная. Причем сложность разработки увеличивается прямо пропорционально числу разработчиков, которые в ней участвуют. При таких условиях разработки, принято придерживаться предопределённых правил, шаблонов и договоренностей, не говоря уже о паттернах проектирования, общеизвестных методологий по разработки ПО и, вообще, принципах ООП.

Очень часто в своей работе мне приходилось использовать перечисления (Enum) в качестве информации о состоянии объекта. И всё бы вроде как хорошо, но есть некоторое неудобство, при таком подходе логика по проверке состояния (validation) объекта при смене статуса "размазывалась" по всей системе. И часто получалось, что отследить все правила перехода от одного состояния к другому практически непосильная задача, особенно если проект разрабатывает группа программистов.