Интерфейсы и контракты

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

Если вы читали фундаментальную книгу Эриха Гаммы (Erich Gamma), Ричарда Хелма (Richard Helm), Ральфа Джонсона (Ralph Johnson) и Джона Влиссидеса (John Vlissides) (известных, как “банда четырех”) Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional, 1995 г.), то знаете, что многие шаблоны проектирования используют “контракты” в стиле интерфейсов.

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

Если в течение последних лет приходилось заниматься разработкой с использованием СОМ и CORBA, то наверняка это была интерфейсно-ориентированная разработка.

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

Например, Visual Studio 2003 предоставляет удобную среду для создания веб-служб. Всего лишь аннотируя методы класса определенным образом, эти методы можно представить как методы веб-службы. Однако при этом IDE-среда воспитывает подход, в котором подразумевается, что интерфейс — это результат аннотирования методов класса, а не наоборот.

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

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

К сожалению, среда Visual Studio поощряет нарушение этого правила, облегчая возможность добавления новых методов в класс и аннотирования их как методов веб-службы.

В хорошо спроектированной интерфейсно-ориентированной системе, такой как система с архитектурой, ориентированной на службы (service-oriented architecture — SOA), сначала должен разрабатываться интерфейс в качестве контракта между компонентами. Контракт управляет реализацией, а не наоборот.

К сожалению, слишком много инструментов в прошлом и даже в настоящем стимулируют такую разработку “задом наперед”. Но это не значит, что вы должны безропотно следовать их ошибочному пути.

В конце концов, контракт, примененный к типу, определяет набор требований к этому типу. Не имеет смысла, чтобы сами типы определяли требования, предъявляемые к ним. В среде .NET интерфейсы являются типами.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100