Является ли хорошей практикой делать интерфейсы даже тогда, когда класс не планируется заменять?
Доброй ночи.
Речь о 2м и 5м принципах SOLID. Например, у меня есть класс A, который гарантированно будет один в программе, и получается, что классы, которые его используют, зависят от деталей, а не от абстракций (ведь у класса A нет интерфейса - зачем он, если класс один). Кроме того, класс А специально создан так, чтобы быть связующим звеном между классами меньшего уровня абстракции, которые уже могут быть заменяемы.
Стоит ли стремиться к полному соблюдению данных принципов, создавать интерфейс даже если он гарантированно будет реализован лишь единожды?
Нет, не надо. Не нужно усложнят проект там где это не требуется.
Есть правило первой пули: сначала Вы пишите максимально просто и только когда приходят первые изменения, которые требуют абстракции, тогда только Вы ее выделяете.
Ryabos, "Правило первой пули" - это термин из какой-то книги гуру мира IT, которую я когда-то прочитал и где описывался принцип KISS ("Keep it simple, stupid"). В контексте, "первая пуля" означало "первые проблемы", которые возникали с текущей реализацией кода.
В этой статье хорошо написано, когда нужен интерфейс и зачем он нужен sergeyteplyakov.blogspot.com/2014/12/what-are-inte...
А от себя добавлю, что фанатичное придерживание принципов SOLID может привести к обратному, а именно увеличению сложности проекта.
Ryabos, их цель - сделать код гибким и красивым. Это сложно, и нормально, когда SOLID усложняет код. Код без соблюдения SOLID - плохой код, даже если он прост
Я не помню все 5 принципов, скажу сразу.
Помню, что Роберт Мартин в своей книге про архитектуру и SOLID в частности говорит, что коварная ошибка - преждевременная гибкость системы. Избыточная гибкость. Это плохо.
Ryabos, но отсутствие гибкости гораздо хуже ее наличия. Не бывает преждевременной гибкости, плохо это лишь потому, что тратится больше времени на шлифовку. А с точки зрения правильности разработки, красоты кода и легкости его сопровождения - это хорошо. Все говнокодят в реалиях бизнеса, но это не оправдание.
принцип инверсии - самый крутой принцип.
разработка начинается с головы. Т.е. если у вас задача проектировать программу, то вы начинаете строить ее с самого главного - ее бизнес логики. Вы не будете знать какие сущности логика будет использовать. Это возникнет из процесса. Поэтому, все что бизнес-логике нужно вы определяете интерфейсами.
В таком случае получится, разбиение логики и сущностей которые ее обслуживают.
из-за того, что первая меняется быстро и часто (по разным причинам, даже не зависящих от девелопера) это разбиение очень полезно. Главное, можно отдать разработку обслуживания другим людям, мы не в курсе библиотек которые будут применяться (и можем менять из), мы легко можем тестировать свою логику.
Примерно так.
Интерфейсы хорошо применять на границах слоев программы. Это дает возможность тестирования и разбиения.
