97 этюдов для архитекторов программных систем

Пришла книга, заказывал на books.ru... Не заметил как пролетело время и пришла повестка... из почты :)

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

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

Но в то же время возникли сомнения, что человеку без опыта эта книга будет интересна. Ведь без опыта нету почвы куда могут авторы посадить своё семя знания. То есть для неискушённого читателя книга может показаться простой и нудной. Но чтобы такое не случилось, думаю стоит попробовать применить советы авторов к текущим проектам/или к прошлым своим проектам. Попробовать посмотреть на свои проекты с точки зрения авторов. Чтобы бы они сказали относительного того, что вы делаете и как вы думаете?

Dependency Inversion Principle, Dependency Injection и Inversion of Control

Кратко напишу так
Dependency inversion principle (DIP) - разрыв ЗАВИСИМОСТЕЙ через абстракцию
То есть, когда мы выводим интерфейс IA и скармлеваем потребителю B, мы отрываемся от зависимости, когда потребитель зависит от изменений конкретного класса A. А рассуждая далее, получаем, что логичней переименовать IA и IB, то есть клиент B определяет, что ему нужно от А:

B использует IB
A реализует IB

Dependency injection - механизм использующий DIP, DIP создает возможность использования DI

Inversion of control (IoC) - Don't call us, we'll call you (Hollywood principle) - принцип, когда основной поток управления (алгоритм) определён, и мы кастомизируем части. Частный случай, когда поток управления скрыт в базовом одном классе - паттерн Template Method. Более сложный вариант - модель Framework и частичная передача управления выполнения нашему приложению.

Очень жаль, что такие понятия путаются. А особенно это замечено в русской википедии. Ну и даже Роберт Мартин в своей книге попутал. Привязав голливудскую фразу к DIP. И вообще в его английском и русском варианте много неточностей, которые мы обнаружили коллективным разумом стади-групп.

Ссылки по теме:
- http://igor.quatrocode.com/2008/09/solid-top-5.html

Проектирование Static Verbs английского языка

Лог переписки English Grammar Study Group. Использованы все принципы проектирования :)

[23:11:49] Ilya говорит: Нашел - эти слова, которые не употребляются в continious по научному называются статические, нединамические (stative verbs). Вот список http://www.perfect-english-grammar.com/stative-verbs.html
[23:12:41] Ilya говорит: Т.е. нельзя сказать I hating или I wishing
[23:21:35] Кирилл говорит: прям не полиморфные глаголы, статика :) Избегаем её всеми силами и несилами :)))
[23:21:47] Ilya говорит: :)
[23:45:22] Denis говорит: sealed к тому же :)
[23:45:46] Denis говорит: хотя нет, need есть наследник - needed ;)
[23:47:08] Кирилл говорит: а может "ed" - это агрегируемая часть класса need :) Neet.ToString() = "Needed"
[23:47:10] Кирилл говорит: )
[23:47:33] Denis говорит: не это врапер
[23:48:06] Кирилл говорит: не, просто булево поле IsInPast = false, и поэтому ToString по-другому работает))
[23:48:26] Denis говорит: class Needed
{
Need need;
ToString() { MakeItInPast() }
}
[23:48:50] Denis говорит: хотя чё-то не так
[23:48:54] Denis говорит: но смысл понятен
[23:49:00] Denis говорит: :)
[23:49:11] Кирилл говорит: class Need
{
bool IsInPast;

}
[23:49:21] Denis говорит: Неее
[23:49:22] Кирилл говорит: override string ToString()
[
[23:49:39] Кирилл говорит: return IsInPast? "Needed" : "Need"
[23:51:02] Denis говорит: фуууу
[23:51:05] Denis говорит: :)
[23:51:08] Кирилл говорит: Я понимаю, но всё же :)
[23:51:45] Denis говорит: понял!

Verb
virtual PresentContinousForm()
{
return "to be" + name + "ing";
}

Need : Verb, IStaticVerb
{
override PresentContinousForm()
{
return PresentSimple();
}
}
[23:52:25] Denis говорит: а нет гоню
[23:52:42] Denis говорит: StaticVerb : Verb

Need: StaticVerb
[23:53:01] Кирилл говорит: мм... IPresentContiniousable, IPresentSimpleable, ... :)))
[23:53:05] Denis говорит: даже ещё хуже!
[23:53:13] Denis говорит: Need - как класс нужен ли?
[23:53:36] Кирилл говорит: таак... Надо подумать. Так как слова - это тоже абстракции, которые что-то означают, то.... да)
[23:53:39] Denis говорит: конструктор - Verb(string name)

и пораждаем need:

need = new StaticVerb("need");
[23:54:12] Кирилл говорит: Ну это смотря что нужно от приложения. Если ИИ строить, то нужны классы на каждое слово)
[23:54:30] Denis говорит: Другой вопрос, будет мина:

fly = new StaticVerb("fly");
[23:54:36] Denis говорит: вроде код корректен, а неверный
[23:54:43] Denis говорит: поэтому нужно где-то словарь заложить
[23:54:49] Denis говорит: а!!!!
[23:54:54] Denis говорит: исопльзуем flyweight! ^)
[23:54:58] Кирилл говорит: Словам нужно атрибуты сделать, либо абстрагировать атрибуты до состояний
[23:55:41] Denis говорит: можно конечно все спрятать в StaticVerbFactory
[23:55:58] Denis говорит: с сылкой на http://www.perfect-english-grammar.com/stative-verbs.html
[23:56:07] Denis говорит: сорри, в VerbFactory
[23:56:16] Кирилл говорит: )))
[23:56:50] Кирилл говорит: А как синонимами управлять... Каждый объект слова должен хранить списки синонимых, антонимых и тд
[23:57:17] Denis говорит: ну это другая юзер стори :)
[23:57:22] Кирилл говорит: :)

Секрет успешной архитектуры в Agile

Обсуждая задачи управление проектами в рамках Scrum с ребятами из Agile Study Group я решил обобщить своё видение на проектирование и построение архитектуры в стиле Agile. И почему оно лучше, чем существующие альтернативы.

Записал подкаст в котором показываю, что классическая разработка (через детальный анализ и проработку архитектуры) и agile-подход (раскидывание релиза на верхнем уровне детализации и итеративная проработка детальных требований по мере проведения итераций) принципиально не отличаются в факторе реакции на изменчивость требованй. Тот и другой подход может дать сбой. И мы сможем получить требование, которое на корне подрубит архитектуру приложения .

Но, я раскрываю секрет, как можно повысить защищённость архитектуры от незапланированных изменений. И главный секрет находится в Команде.