Типы бетона или интерфейсы для типов возврата?

Question

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

Каковы лучшие выборы для возвращаемого типа метода: конкретный тип или интерфейс?

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

Темная сторона этого: сцепление. Ангелический: конкретный тип содержит интерфейс, с которого вы сначала вернетесь, и дополнительную функциональность.

Какое у вас правило большого пальца?

Есть ли какой-либо принцип программирования для этого?

---

БОНУС: Это пример того, что я имею в виду ReadOnlyCollection or IEnumerable for exposing member collections?

Answer 1

Мои Эмпирические правила:

1) Первоначально, у меня есть метод возвращает тип интерфейса, потому что его всегда легко изменить его к конкретному типу позже, если это необходимо. Сложнее вернуться в другую сторону.

2) Даже если метод объявлен вернуть конкретный тип, я бы закодировать звонящие использовать тип интерфейса, когда это возможно:
InterfaceType i = xyz.methodThatReturnsConcreteType();.

3) Если у меня есть код вызова делает разницу тоже (внутренние против публичных API-интерфейсов):

• Если у меня есть код, который вызывает метод в вопросе (т.е. внутреннего API), то в большей степени готов Я должен вернуть конкретный тип.
• Если я не управляю кодом, вызывающим этот метод (например, public API), тем скорее я верну тип интерфейса. Возвращение конкретного типа - это обязательство, и, вообще говоря, чем меньше я обещаю, тем проще.

Другие соображения:

• Тестирование может быть проще с интерфейсами, так как я могу использовать фиктивный объект, который реализует интерфейс.
• Там есть шанс, что я хотел бы возвращать proxy object (теперь я действительно достигает оправданий)

Резюмируя,

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

Answer 2

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

Answer 3

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

public AccelerationResponse PressAccelerator(float force) {} 

Скорее всего, вы хотите вернуть интерфейс, а не класс. Вы можете интерпретировать этот ответ по-разному в зависимости от определенных условий.

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