Хотя бы в том, что прямая ссылка на класс B может сделать класс A трудно тестируемым юнит тестами, которые требуют использование мока для тестирования логики класса A. Получается реализация меняется, а абстракция остается неизменной.
У меня был случай когда из-за проблем с лицензией приходилось менять Unity IoC контейнер на кастомный. В случаем с логгерами, в принципе log4net с его аппендерами бывает достаточным. Но мало ли что? Вдруг придется… Кроме того, абстракция логгера поможет при юнит тестировании, если есть требования на логирование. Например, в таком-то случае нужно логировать то-то с таким-то уровнем. В моем проекте такое встречается довольно часто.
Принцип SRP как показывает опыт довольно спорный. Это предмет отдельной дискуссии. Вспомните ООП. Там не брезгуют хранить состояние объекта и в то же время наделяют его методами. В нашем случае фигура сознательно наделена способностью себя рисовать. В нашем случае считаю это достаточным.
Если нужно сделать код юнит тестируемым (подставить моки) относительно уровня и контента логируемых сообщений, то да. Иначе, как хотите. Тут нет единой рекомендации. Прямое использование лог фор нет является имхо жестковатым, если хотите проверять в юнит тестах то, что Вы логируете.
Статья развернутая, но имхо для человека, которому дали эту роль придется в его конкретных условиях строить свою команду. Я как-то смотрел презентацию, в которой в довольно убедительной манере рассказывалось про процесс эволюции тим лидера. Начинается с получения роли и иногда желания поруководить и заканчивается полным доверием со стороны команды. Это занимает время, приходит с опытом, а иногда не приходит вообще. Процессы… Они могут вызывать отторжение. Неопытный тим лид может попытаться их жестко навязать. Это может стать проблемой. Согласен с автором в том, что бизнес рулит и все хорошо что хорошо для него в итоге. Процессы так процессы. Или их отсутсвие и анархия. Заказчик самый главный. По поводу защиты интересов команды, тут главное не перестараться и объяснить в случае чего заказчику, что мол больше мы делать не можем. Честно объяснить.
Если привести такой неоднозначный пример, комментов было бы раза в два больше :-) Можно просто в конце статьи привести более подробное рассуждение на тему критериев применимости принципа, в которое включить Вашу мысль.
Согласен, видимо подобные рассуждения нужно поместить в конец статьи вместо этого:
Но всегда нужно помнить о том, что это всего лишь общая рекомендация, и решение по его применению следует принимать исходя из конкретной ситуации.
Дочерний класс можно написать так, что будет невозможно его использовать в Program 1, так как нужно будет «подгребать» UI-ные зависимости. Это может нарушить LSP. А может и не нарушить. Все зависит от того, как был сделан потомок.
Требования часто диктуются клиентами программы. Program1 может вполне себе настоять на изменении алгоритма расчета площади или размерности возвращаемых геттерами длин сторон. Рисование ей по боку. И для того, чтобы не ограничивать ее в этом, лучше разделить ответственности. Если же все вместе всегда применяется, разделять и не за чем.
А какой смысл Вы вкладываете в свои статьи? Целью этой является обсуждение проблемы, я каждый существенный комментарий попытаюсь адресовать, чтобы ищущие люди в интернете могли дополнить свои знания по этой теме.
Не у всех есть возможность купить книгу, целью данной статьи является добавить больше доступной информации по этой теме. Поэтому Ваше мнение очень важно для нас, что называется :-) А также полезно обсудить мысли, высказанные в этой книге. К примеру, само определение принципа, как оказалось, вызывает много диспутов и вопросов.
Эта величина зависит от ситуации. Поэтому и не рекомендуется всегда следовать паттернам. В конкретном случае примера из этой статьи цена должна превышать убытки априори.
Думаю ответственность — это контракт компонента, то есть набор предоставляемых им операций. Это коррелирует с принципом разделения интерфейсов. На каждый компонент должны быть написаны юниты, которые обозначают требования к компоненту. Single Reason to change — это существенные изменения в первоначальных требованиях, меняющие ожидания от компонента. Вот надо научиться правильно этот контракт определять видимо. Про остальные принципы я тоже планирую написать, если меня вконец не забанят :-)
Хотя бы в том, что прямая ссылка на класс B может сделать класс A трудно тестируемым юнит тестами, которые требуют использование мока для тестирования логики класса A. Получается реализация меняется, а абстракция остается неизменной.
Все может поменяться. Обычно интерфейсы меняются реже чем их реализации. Закрыть все от изменений не получится.
Вы правы, возможно я дополню эту главу чем-то подобным, спасибо.
Пример с логгером довольно абстрактный, давайте считать что в изначально дизайн закладывался на использование любого логгера, а не только log4net.
У меня был случай когда из-за проблем с лицензией приходилось менять Unity IoC контейнер на кастомный. В случаем с логгерами, в принципе log4net с его аппендерами бывает достаточным. Но мало ли что? Вдруг придется… Кроме того, абстракция логгера поможет при юнит тестировании, если есть требования на логирование. Например, в таком-то случае нужно логировать то-то с таким-то уровнем. В моем проекте такое встречается довольно часто.
Принцип SRP как показывает опыт довольно спорный. Это предмет отдельной дискуссии. Вспомните ООП. Там не брезгуют хранить состояние объекта и в то же время наделяют его методами. В нашем случае фигура сознательно наделена способностью себя рисовать. В нашем случае считаю это достаточным.
Да, это опечатка. Поправлю, спасибо!
Если нужно сделать код юнит тестируемым (подставить моки) относительно уровня и контента логируемых сообщений, то да. Иначе, как хотите. Тут нет единой рекомендации. Прямое использование лог фор нет является имхо жестковатым, если хотите проверять в юнит тестах то, что Вы логируете.
Но всегда нужно помнить о том, что это всего лишь общая рекомендация, и решение по его применению следует принимать исходя из конкретной ситуации.
Постараюсь учесть.