Я постараюсь как можно лучше ответить на ваш вопрос как можно лучше.
1
Полезно ли абстрагировать как можно больше функциональных возможностей в интерфейсы?
Давайте начнем с основ
a) Помните, что интерфейсы - это не что иное, как «контракты», обещание, что субъект, реализующий интерфейс, в основном обещает соблюдать и выполнять условия контрактов.
б) Интерфейсы выступают в качестве отличных инструментов проектирования в коде, позволяя, по сути, продюсеру и актерам сосредоточиться на высоком уровне взаимодействия, не беспокоясь о деталях реализации.
С точки зрения непрофессионала CS, интерфейс обещает соответствие, по сути, 3 вещи.
1. обещание, что упомянутая функциональность / операция / функция / метод доступна
2. что этот функционал принимает указанный согласованный вклад
3. что (если реализовано) эта функциональность даст указанные результаты.
Таким образом, когда часть услуги (сообщение класса / мыла и т. Д.) Предлагает нам реализовать интерфейс, она публично соглашается с этими тремя условиями «контракта», и любое отклонение от них является нарушением контракта.
2
Да, вы абсолютно правы, интерфейсы действительно демонстрируют свою мощь, когда дело доходит до Ioc (инверсия управления) в Принципы проектирования SOLID , которые позволяют контейнеру IoC разрешать (предоставлять) и обслуживать подходящий субъект (реализация), который выполняет контракт, часто во время выполнения, поэтому освобождает разработчика системы, чтобы он не беспокоился о деталях реализации.
Но, возможно, преимущества Ioc часто будут реализованы только при реализации шаблона локатора службы , поэтому "как разработчик или группа получат выгоду от использования интерфейсов в качестве инструмента проектирования?" становится важным вопросом.
Один разработчик
В качестве примера я занят написанием новой системы программного обеспечения и в течение дня я сосредоточил свое внимание на том типе функциональности, который я хотел бы предложить своим пользователям, возможно, иметь возможность управлять их списком задач в общем смысле, что влечет за собой возможность «создавать» новые элементы задач, «проверять» существующие элементы и «удалять» элементы из их коллекции задач. Теперь есть несколько способов реализации каждой из этих функций, и я становлюсь ленивым. Я предпочел бы потратить следующую неделю на предоставление только одной из этих функций, но я мог бы забыть свои первоначальные мысли и в конечном итоге реализовать свои собственные функции на основе что касается моего влияния с течением времени, чтобы дисциплинировать себя и придерживаться того, что я изначально придумал, я предпочел скорее составить проект контракта на эту функциональность заранее, фактически не реализовав его, что позволит мне имитировать эти функции, а не фактически их реализовывать. Таким образом, используя интерфейсы, я заложил основы того, чего мне нужно достичь в ближайшие недели, и я могу возвращаться к нему через день и дополнять свои функции, не нарушая своего обещания ... что подводит нас к следующей теме, которая Я не буду слишком углубляться в принципы Open Close (O в SOLID), которые в основном говорят, что мои проекты закрыты для внешних изменений, но открыты для внутренних изменений и, возможно, событий, открытых для расширения (дополнения). поэтому я могу добавлять новые функции в свой сервис todo, не нарушая свои существующие контракты, и я могу изменить их поведение при реализации, но не могу изменить форму существующих функций.
В команде Я работаю с Lindile и Selebalo над внедрением системы виртуальных карт, и поскольку работы слишком много, мы решили, что я сосредоточусь на основной банковской системе (бухгалтерская книга баланса), а Lindile сосредоточится на депозитах ВК, а Selebalo - на депозитах. депозиты ВК. Во время нашей первоначальной сессии проектирования мы разрабатываем изнутри, начиная с основного банковского дела, и описываем, какие операции будут доступны для обновления учетной записи клиента, и после нескольких часов обсуждений мы решаем, что основная банковская система предложит две функциональные возможности, одну для добавления деньги на счет, называемый «кредит», который принимает сумму, и «дебет», который вычитает или уменьшает счет клиента, который также принимает сумму. Но поскольку ядро должно иметь дело со многими другими вещами (кредитные профили клиентов, AML и т. Д.), Кроме дебетов и кредитов, это может занять некоторое время, пока я не скажу, что ребята могут интегрировать и тестировать свои коды, поэтому мы принимаем решение по контракту основной банк, который имеет
public interface ICoreBankingServices{
Balance Debit(decimal amount,Currency c);
Balance Credit(decimal amount, Currency c);
}
Теперь Lindile и Selebalo могут работать в предположении, что я выполню контракт и решу смоделировать или смоделировать результаты дебетовых и кредитных операций до тех пор, пока мы все не будем готовы к интеграции и тестированию, и, следовательно, для них не будет зависеть от моих возможностей развития. работать, и это положительный момент.
Я надеюсь, что эти примеры раскроют некоторые из основных преимуществ использования интерфейсов, инструментов проектирования и механизмов развязки зависимостей.
Я не ожидаю Java, но если игровой персонаж должен сражаться, есть и двигаться, вы на правильном пути. Вам просто нужно следить за уровнем развязки, который вы делаете (так же, как нормализация) за счет увеличения сложности, но нет никаких указаний для этого, и пока вещи не становятся слишком сложными, вы можете описать вещи в много интерфейсов, насколько это логически возможно ... просто не применяют одно и то же мышление, когда речь идет о множественном наследовании реализации, но это личное мнение :)
В конечном итоге вам придется заплатить налоги и узнать немного больше о шаблонах проектирования и о том, что они пытаются решить или упростить, чтобы углубить ваше понимание разработки более совершенных систем.