Главная » C#, Компоненты » Компоненты: достоинства и недостатки

0

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

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

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

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

Наконец, накопив достаточное количество компонентов, можно действительно быстро создать визуальный интерфейс программы, фактически, не написав более ни строчки кода!

Чем же придется заплатить за все это? Как это не удивительно звучит, но платить придется объектно-ориентированным подходом. Возможность гибкого управления поведением компонентов с помощью событий провоцирует написание "событийно-ориентированного" кода. Пусть, например, нам нужен компонент для отображения цветных строк. Объектно-ориентированный подход обязывает нас создать наследника класса ListBox и, перекрыв метод Paint, реализовать отрисовку цветных строк. Возможность реализовать событие onPaint и не создавать никаких классов подталкивает многих программистов к использованию событий в ущерб объектно-ориентированному подходу. Я специально говорю "подталкивает", т. к. никто не мешает создать новый компонент, умеющий рисовать цветные строки на основе существующего компонента ListBox. Такой подход и будет наиболее верным — ведь такие компоненты можно использовать повторно!

Еще одна плата за удобство — необходимость иметь гибкие компоненты. Нет смысла писать компонент, рисующий только строки красного цвета. Такой компонент будет затруднительно использовать где-либо, кроме той программы, для которой он изначально предназначался. Гораздо правильнее написать компонент, рисующий строки заданного цвета, а сам цвет вынести в его свойства (или как-то хранить внутри самой строки). Вот такой компонент можно использовать в любой программе. Такая гибкость требует некоторых дополнительных усилий, необходимость затратить которые не всегда очевидна при разработке одной программы, но вполне окупается при повторном использовании компонента.

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

Литература:

Агуров П. В. C#. Разработка компонентов в MS Visual Studio 2005/2008. – СПб.: БХВ-Петербург, 2008. — 480 е.: ил.

По теме:

  • Комментарии