Каждый объект должен иметь интерфейс и все слабо связанные объекты?

Едва ли. Сервисные компоненты (класс, которые делают вещи для Вашего приложения) являются подходящим вариантом для интерфейсов, но как правило я не потрудился бы иметь интерфейсы для, скажем, основных классов объекта.

, Например: Если Вы работаете над моделью предметной области, то та модель не должна быть интерфейсами. Однако, если та модель предметной области хочет к классам обслуживания вызовов (как доступ к данным, функции операционной системы и т.д.) тогда, необходимо смотреть на интерфейсы для тех компонентов. Это уменьшает связь между классами и средствами, это - интерфейс, или "заключите контракт", который связан.

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

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

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

Ах да, и если Вы действительно идете в большой степени в интерфейсы - остерегаются веб-сервисов. Если необходимо представить методы объекта через веб-сервис, они не могут действительно возвратить или взять интерфейсные типы, только конкретные типы (если Вы не собираетесь написать от руки всю свою собственную сериализацию/десериализацию). Да, это укусило меня достижение...

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

Как пример, все потоковые объекты в.NET происходят из Системы. IO.Stream, который является абстрактным классом. Это облегчает для Microsoft добавлять новые опции. В версии 2 frameworkj они добавили ReadTimeout и свойства WriteTimeout, не повреждая кода. Если бы они использовали интерфейс (скажите IStream), тогда они не были бы в состоянии сделать это. Вместо этого они должны были бы создать новый интерфейс для определения методов тайм-аута, и мы должны будем записать код для условного кастинга к этому интерфейсу, если бы мы хотели использовать функциональность.

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

, Например, в моем приложении CAM мне подключили CuttingPath к Набору Точек. Не имеет никакого смысла иметь интерфейс IPointList, поскольку CuttingPaths всегда будут состоявшими из Точек в моем приложении.

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

Наши приложения были, поддерживают с середины 80-х и перешел к объектно-ориентированному проектированию в конце 90-х. Я нашел, что, что могло изменить значительно превышенный, что я первоначально думал и использование интерфейсов выросло. Например, это раньше было, что наш DrawingPath состоял из точек. Но теперь это состоит из объектов (шлицы, дуги, ЕС), Таким образом, на это указывают на EntityList, который является набором Объекта, реализовывая интерфейс IEntity.

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

Примечание, что в нашей системе DrawingPaths представляются вниз к низкоуровневому пути вырезания, которые всегда являются серией сегментов точки.

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

Скажем, у Вас есть несколько типов потребительских классов, которые варьируются немного, но имеют общую собственность. В этом случае замечательно иметь ICustomer интерфейс к связанному их, логически. Путем выполнения этого Вы могли создать CustomerHander класс/метод, который обрабатывает объекты ICustomer тот же путь вместо того, чтобы создать handerl метод для каждого изменения клиентов.

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