Проектируя систему помимо функциональных и нефункциональных требований, архитектор должен держать в уме ещё и различные "best practices". Вроде слабого связывания и повторного использования.
Идеальное слабое связывание - набор компонент, которые ни от кого (кроме себя) не зависят. :) Утопия. Как только 2 компонента начинают иметь общий функционал, этот функционал выносится в отдельный компонент. Эта итерация повторяется до тех пор пока каждый компонент не начинает исполнять свою уникальную задачу. Казалось бы, все хорошо. И связывание слабое и повторное использование максимальное. На деле всё не всегда так. Операцию по выделению дубликатов можно проводить очень долго, спускаясь по уровню декомпозиции все ниже и ниже. В результате может получится "экономия на спичках" когда небольшой и простой функционал (например логирование) выделяется в отдельный компонент, который после выделения становится чрезвычайно негибким в плане изменений и настроек под конкретный компонент, который его использует.
Поэтому качели "слабое связывание <-> повторное использование" должны оставаться в равновесии, без перекосов.
Привет, Леня. Очень интересно тебя читать, не всегда есть что оставить в коментариях, но подумать уж точно всегда есть над чем. пиши еще!
ОтветитьУдалитья хотел сказать при выделении общего компонента который используется двумя другими можно предусмотреть как он вероятно будет использоваться в будущем. т.е. реализовать чуть чуть больше чем нужно для сегодняшних его пользователей. как думаешь это имеет смысл?
Привет! Спасибо, я рад )
ОтветитьУдалитьСмысл конечно имеет. Проблема в слове "вероятно". В XP даже есть такое правило "то, что наверное понадобится нам в будущем, не понадобится нам никогда". Скорее я бы предусмотрел возможность легкой "переделки" компонента - чтобы его всегда можно было бы расширить, когда это станет необходимым.
Я согласен. но хочется понять что лучше: выделять общий функционал правильно (и как это правильно?сам себе вопрос прежде всего задаю) или не выделять его вовсе.. вот на том же примере с логированием, можно было бы выделить этот функционал так чтобы избежать проблемы негибкости?
ОтветитьУдалить