Лучше ли для каждого свойства класса соответствовать интерфейсу? - PullRequest
0 голосов
/ 23 февраля 2011

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

Ответы [ 4 ]

1 голос
/ 23 февраля 2011

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

1 голос
/ 23 февраля 2011

Теоретически у вас должен быть интерфейс или абстрактный класс для любого класса, который содержит бизнес-логику, чтобы вы могли тестировать его модулем и / или легко менять реализации. Классы, которые используются для представления данных - классы моделей - не должны реализовывать интерфейс, чтобы быть «лучшей практикой» (он должен где-то заканчиваться).

1 голос
/ 23 февраля 2011

Мне бы пришлось заняться экстремальным программированием и практикой ЯГНИ (тебе это не понадобится).Извлекайте интерфейс только тогда, когда вам нужен для другого класса.В противном случае это просто увеличивает накладные расходы.

Исключением, конечно, является случай, когда вам необходимо добавить объект Mock в схему тестирования, а подклассы не достигают того, что вы хотите.

ЭтоТема связана с Emergent Design.Я считаю, что это знак отличных дизайнеров.

1 голос
/ 23 февраля 2011

Как обычно, это зависит. Если вы пишете публичный API, этот подход очень мощный. Примером этого является API Progistics / Connectship. В то время, когда я использовал это, был один конкретный класс. Остальная часть открытого интерфейса была всеми интерфейсами. Они смогли разорвать всю реализацию продукта и переписать его, оставив интерфейсы без изменений.

Конечно, с этим связана стоимость. Вы должны потратить много времени и усилий на создание элегантного API, если вы хотите использовать его в камне (конечно, это тот случай, если вы решите использовать интерфейсы или нет).

С другой стороны, если вы пишете слой доступа к данным для внутреннего бизнес-приложения, вы можете не получить столько вознаграждений.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...