Насколько сложными должны быть интерфейсы?

Мы работаем над проектом, где будет общая конфигурация, к которой необходимо получить доступ несколькими частями решения.Насколько сложными должны быть интерфейсы?

Команда, ответственная за модуль Config, реализовала интерфейс, который состоит только из 2 классов. 2 класса, которые отвечают за получение, кеширование и предоставление определенных значений (через свойства).

Я считаю, что это плохой дизайн, на мой взгляд, было бы лучше определить все значения конфигурации, которые можно получить через интерфейс, но не фактические классы, реализующие это поведение.

На мой взгляд, для чего-то вроде получения значений конфигурации было бы логичнее дать интерфейс, который показывает мне, какие значения я могу получить, но не класс (какая реализация, например, свойства не контролируются интерфейс).

-edit- Интерфейс выглядит следующим образом:

public interface IConfigurationResolver 
{ 
    GeneralConfiguration GetGeneralConfiguration(string Id); 
    SpecificConfiguration GetSpecificConfiguration(string Id); 
}

Он реализован одним классом. Я имел в виду, что эти интерфейсы действительно просто определяют два класса, каждый из которых несет ответственность за предоставление значений конфигурации, тогда как я думаю, было бы лучше, если бы интерфейс не заботился о таких деталях и должен сам представлять значения конфигурации.

Эти очень опытные разработчики, а я нет, так какова ваша позиция на этом?

источник

2013-05-20 buddybubble

Это почти невозможно прокомментировать это без более широкого понимания приложения: размер, функция, жизненный цикл и т. Д. Все эти факторы могут повлиять на то, что считается лучшей практикой. Поддержание работоспособности менее важно для продукта с коротким жизненным циклом, чем долгосрочный, например. Усилия разработчиков будут лучше потрачены на вещи, отличные от классов конфигурации. – Khior

Конфигурация на самом деле очень важна в этом проекте. Это веб-приложение, которое будет работать как минимум на 5 лет (возможно, намного дольше). Это позволит пользователю работать с разными (но очень похожими) системами. Этим системам потребуется множество параметров и формуляров, которые варьируются от системы к системе и могут со временем меняться. Извините, я не могу сказать, что именно мы здесь говорим – buddybubble

Одним из ТВЕРДЫХ принципов интерфейса принцип сегрегации «много интерфейсов клиентских конкретных лучше, чем один интерфейс общего назначения.»

http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29

Что вы имеете в виду «интерфейс, который состоит только из 2-х классов "? Это только два класса реализуют этот интерфейс?

Я чувствую, что это плохой дизайн, на мой взгляд, было бы лучше определить все значения конфигурации можно получить доступ через интерфейс, но не фактические классы, которые реализуют это поведение.

Не уверен, что я понимаю ваш вопрос - Да, вы должны обращаться к интерфейсу, а не непосредственно к классу?

источник

2013-05-20 11:31:27 DaveHogan

Я думаю, что нет никакого нарушения этого принципа, поскольку конфигурация может рассматриваться как гранулированная сущность в нашем случае. Не имеет смысла разделить его, потому что все ценности могут быть доступны в любом месте. – buddybubble

Хорошо - справедливо. Я не совсем понимаю ваш вопрос, так как название было таким сложным, каким должен быть интерфейс, но суть ваших вопросов подразумевает, что вы спрашиваете, следует ли обращаться к интерфейсу, а не к классу? Можете ли вы дать дополнительную информацию о проблеме? – DaveHogan

Я отредактировал мой вопрос, чтобы уточнить, что я пытался задать :) – buddybubble

Я не вижу никаких проблем с этим подходом. Один принцип ОО скрывается. Пока внутренняя структура класса (-ов) скрыта частными методами или подклассами, нет необходимости использовать какой-либо интерфейс вообще.

Интерфейсы имеют смысл, как только вы хотите предоставить несколько реализаций для поведения sinlge (например, API проверки боба) или если вы хотите ограничить методы, которые должны быть доступны для разных пользователей класса.

источник

2013-05-20 11:36:24

Есть довольно много вещей происходит здесь ...

Ссылки неабстрактных классов в интерфейсе IConfigurationResolver это код запах, нарушив «программу на интерфейс, а не реализация» принципал (What does it mean to "program to an interface"?) ,

Вашего желание явно выявить параметры конфигурации через интерфейс является хорошей, и в соответствии с понятием Намерения, раскрывающего интерфейсом (как описано в Eric Evans’ Domain Driven Design).

Однако, если у вас много значений конфигурации, этот интерфейс может в конечном итоге иметь множество методов. Здесь вы узнаете о своем домене - декомпозиции «юниверса конфигураций» в наборе единых интерфейсов, каждый из которых используется для настройки отдельного аспекта вашего приложения, сам по себе является навыком и относится к «Я» в SOLID. Lowy's Programming .NET components обсуждает проблему рефакторинга контрактов, а в качестве приблизительного руководства предлагается использовать 3-5 методов для каждого интерфейса.

Я предполагаю, что желание «перегруппировать конфигурации» является корнем существования двух методов в текущем интерфейсе.

источник

2013-05-20 13:59:36 Lawrence

Насколько сложными должны быть интерфейсы?

ответ

Смежные вопросы