[ <<< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | Источники ]


© 2001 А.И. Легалов

Заключительные ассоциации

Сопоставление процедурного и объектно-ориентированного подходов показывает их самодостаточность при написании "чистого парадигматического" кода. Однако необходимость эффективного эволюционного развития программы и повторное использование некоторых ее фрагментов ведут, на практике, к совместному использованию этих парадигм. Программирование уже давно является многоруким независимо от того, каким считается язык: процедурным, объектным или мультипарадигматическим. А то, что объектно-ориентированная методология трактует со своих позиций сочетание различных стилей, не столь важно с точки зрения парадигм. В конце концов, любой компилятор (по крайней мере, для C++) транслирует написанную программу в обычный процедурный код.

Повторяются библейские истории. Было время, когда процедурный и объектный подход мирно сосуществовали под одной крышей, названной строителями этого очага "Структурное программирование" [Дал75]. Однако в дальнейшем им стало тесно, и молодой, объектно-ориентированный, Каин, дав в морду своему брату Авелю, покинул семейный очаг, спровоцировав Великое противостояние и Вавилонское столпотворение. Однако, даже если нам кажется, что разговор идет на одном языке, мы все равно используем смешение стилей, когда пишем реальный код.

Краткое содержание этой серии

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

  1. В предлагаемых заметках анализируется техника построения и использования программных объектов. При этом я попытался абстрагироваться от методологических, ресурсных и функциональных аспектов.
  2. Рассматривается применение техники построения программных объектов в эволюционном программировании (кодировании). Упор сделан на процедурное и объектно-ориентированное программирование. Эволюционное программирование используется при разработке больших программных систем. Оно позволяет расширять функциональные и структурные возможности программы с минимальными изменениями уже написанного кода.
  3. Проведено разделение техники кодирования на процедурную и объектно-ориентированную. Это чисто субъективное решение основано на использовании ряда методов построения программ в "дообъектную" эпоху.
  4. Независимо от техники и парадигм программирования мы создаем программные объекты и отношения между ними, используя такие понятия как агрегат и обобщение. К одному и тому же конечному результату можно прийти различными путями.
  5. Рассмотрена техника создания агрегатов и обобщений при процедурном и объектно-ориентированном подходах. Сделана попытка проиллюстрировать ее серий мелких и тривиальных примеров.
  6. Процедурное агрегирование обладает большей гибкостью по сравнению с объектно-ориентированным, а метафора автономного полнофункционального объекта не всегда удобна, так как вступает в противоречие с ассоциациями, необходимыми при построении эволюционно наращиваемых программ. При этом можно, используя процедурный подход, вообразить, что мы работам с объектами, или изменить язык программирования таким образом, чтобы обычные внешние процедуры "прикидывались" внутренними методами объектов.
  7. Объектное обобщение обладает неоспоримыми преимуществами при создании эволюционно расширяемых альтернатив и агрегатов с неизменяемым интерфейсом. Эти достоинства, на мой взгляд, и предопределили ход дальнейшего практического использования парадигм программирования. Хотя, и у объектных обобщений имеется ряд недостатков, вместо исправления которых проще использовать методы процедурного программирования.
  8. Высокоэффективное эволюционное программирование должно быть многоруким. Иначе, оно не будет эффективным. Поэтому, даже в языках, считающихся чисто объектными, всегда существуют механизмы поддержки процедурного стиля, к коим можно отнести анализ типа объекта во время выполнения (даже, если внешне он прикидывается внутренним методом).
  9. Будущее за мультипарадигматическим программированием (по Страуструпу). Следовательно, и методологии скоро вновь начнут "плыть" в сторону поддержки смешанных способов представления программных объектов, обеспечивая большую гибкость при проектировании.

[ <<< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | Источники ]