День 1218. #ЗаметкиНаПолях #DesignPatterns Абстракции в Разработке ПО. Окончание Начало Продолжение Запутанные (или откровенно ложные) правила абстракций Есть некоторые «правила» абстракций, которые могут привести к путанице, если их вырвать из контекста, хотя изначальный их посыл правильный. 1. Интерфейсы — это не абстракции Это правило Марка Симэна, автора книги «Внедрение зависимостей на платформе .NET». Марк описывает множество причин, по которым интерфейс может быть плохой абстракцией. Однако согласно всем определениям, которые мы рассмотрели в первой части, интерфейсы таки являются абстракциями. Просто некоторые из них - плохие абстракции. Значит правило стоит уточнить: «Интерфейсы не всегда являются хорошими абстракциями» 2. Интерфейсы с одной реализацией не являются абстракциями Это утверждение Владимира Хорикова, автора книги «Принципы юнит-тестирования» и курсов на Pluralsight. Аналогично сказанному выше, это правило стоит уточнить: «Интерфейсы с одной реализацией не являются хорошими абстракциями». Смысл этих правил в том, что вы должны иметь возможность взглянуть на интерфейс и определить, является ли он хорошей абстракцией (или, по крайней мере, демонстрирует ли он описанные выше проблемы), не видя никакого другого кода. Одна из проблем с этим заключается в том, что требуются знания реализаций интерфейса, чтобы сделать о нём оценочное суждение. А иногда вы вообще не можете быть уверены, сколько всего реализаций интерфейса существует, если он включён в пакет и может использоваться в других проектах. Вот отрывок из книги Хорикова: «Настоящие абстракции обнаруживаются, а не изобретаются. Открытие по определению происходит постфактум, когда абстракция уже существует, но не имеет чёткого определения в коде». Вернёмся к первоначальному определению абстрагирования, как процесса построения полезной модели. Владимир говорит, что часто разработчики слишком быстро переходят к созданию абстракций вместо того, чтобы посмотреть, как эволюционирует их модель, а затем определять в ней полезные абстракции. Это своего рода преждевременная оптимизация. Но ничто из этого не говорит о том, являются ли интерфейсы абстракциями или даже хорошими абстракциями, исходя из количества их реализаций. В лучшем случае мы можем сказать: Интерфейсы с единственной реализацией в рабочем коде — это код с запашком (code smell), потому что они могут быть плохими абстракциями из-за слишком тесной связи с их единственной реализацией. При этом запахи кода не обязательно говорят о плохом или неправильном коде, просто их стоит изучить немного глубже, потому что они могут быть симптомом проблемы в дизайне ПО. Возможно, интерфейс был создан преждевременно, либо вручную, либо с помощью скаффолдинга, и тесно связан с деталями реализации единственного класса, в настоящее время выполняющего эту работу в системе. Знание того, что существует отношение 1:1 между интерфейсом и его реализацией, может помочь вам изучить дизайн и увидеть, есть ли с ним какие-либо проблемы (например, описанные выше, связанные с SOLID, стабильностью и т. д.). В этом смысле это может быть полезной эвристикой при оценке кода, но в идеале стоит оставить в системе все интерфейсы, которые имеют только одну реализацию, но которые на самом деле являются хорошими абстракциями. Итого Существует несколько определений абстракций. Некоторые аспекты могут оцениваться как истинные/ложные, например, является ли тип в C# абстрактным или конкретным. Другим может потребоваться некоторая субъективная оценка, чтобы определить, является ли данная абстракция хорошей, подлинной, полезной и т. д. А некоторые правила, претендующие на оценку того, является ли что-то абстракцией или нет, на самом деле просто говорят о том, является ли эта вещь хорошей абстракцией (или нет). Источник: ardalis.com/what-ar…elopment Автор оригинала: Steve “Ardalis” Smith