ООП шиворот-навыворот: играем Гамму
Наткнулся у Эрика Гаммы, одного из Банды четырёх (который оказывается с прошлого года трудится над Microsoft Visual Studio) на идеи, которые словно списаны с Метакода:)
Значит, мы двигаемся в правильном направлении.
"Методики ООП отражают разные подходы. Вы можете сформулировать задачу письменно, выделить из получившейся фразы существительные и глаголы, после чего создать соответствующие классы и операции. Другой путь - сосредоточиться на отношениях и разделении обязанностей в системе. Можно построить модель реального мира или перенести выявленные при анализе объекты на свой дизайн".
Немного поразбираем Гамму:
"Не объявляйте переменные как экземпляры конкретных классов. Вместо этого придерживайтесь интерфейса, определенного абстрактным классом. Это одна из наших ключевых идей".
Отсутствие переменных -- это в принципе одна из ключевых идей функционального программирования.
"Композиция объектов - это альтернатива наследованию класса. В этом случае новую, более сложную функциональность мы получаем путем объединения или композиции объектов. Для композиции требуется, чтобы объединяемые объекты имели четко определенные интерфейсы.
Поскольку подклассу доступны детали реализации родительского класса, то часто говорят, что наследование нарушает инкапсуляцию. Это подводит нас ко второму правилу объектно-ориентированного проектирования: предпочитайте композицию наследованию класса.
Хорошо бы, чтобы можно было получить всю нужную функциональность, просто собирая вместе уже существующие компоненты. На практике, однако, так получается редко, поскольку набор имеющихся компонентов все же недостаточно широк".
Но функциональное программирование как раз компенсирует этот недостаток вычислительными мета-механизмами.
"С помощью делегирования композицию можно сделать столь же мощным инструментом повторного использования, сколь и наследование. Делегирование показывает, что наследование как механизм повторного использования всегда можно заменить композицией".
А я о чем говорил!:)
"Трудно представить себе, как предложить "полный" набор паттернов, из которого можно было бы вывести пошаговые инструкции по созданию приложения. Нам кажется маловероятным, что когда-либо будет создан полный язык паттернов для проектирования программ".
Фактически Гамма постоянно говорит о мета-программировании, однако немного ограничивает себя объектным подходом.
Про пошаговые инструкции: в заключение Гамма упоминает Кристофера Александера -- уникального человека, который написал книгу "The Pattern Language", ставшую культовой у архитекторов, а затем и проектировщиков.
Из нее, собственно, концепция паттернов проектирования и выросла.
"По мнению Александера основной задачей при декомпозиции системы является выполнение следующих двух условий:
- максимизация связей внутри компонентов (высокое сцепление, high cohesion) и
- минимизация связей между компонентами (низкая связанность, low coupling).
Сегодня эти проблемы широко известны в программной индустрии и описаны в любой книге по проектированию и построению программных систем, но, если верить Александеру, они присущи проектированию любых сложных систем...
В отличие от "чистых" системщиков Александер стремится создавать некие целостности, способные к относительной самостоятельности в поведении и развитии, тогда как взгляд с функциональных позиций обречен на выхватывание и гиперболизацию одного качества, стороны, свойства и т.п.
Открытая система не поддается схематизации, ее невозможно свести только к механической совокупности элементов. Иначе говоря, открытая система не создается с помощью конструктора. Она не только самоорганизуется, но зависит от среды".
http://www.taby27.ru/tvorcheskie_raboty/pro-arxitektorov-dizajnerov-xudozhnikov/kristofer-aleksander.html
Но мне как раз кажется, что в пошаговых инструкциях ничего плохого нету. Тут важно не путать пошаговые инструкции и конструкторы/схематизаторы. Условно говоря, пошаговые инструкции должны быть пошаговыми мета-инструкциями.
Работа "Язык шаблонов: города, здания, строительство" квалифицируется критиками как своеобразная "порождающая грамматика" подхода Александера".
Но порождающие грамматики -- это любимейшее развлечение функциональных программистов! Вот например в тему, про цепки Маркова и DSL-языки (http://habrahabr.ru/post/134291/).
"Некоторые тезисы, вроде отрицания проектирования на бумаге, по мнению критиков, свидетельствуют о высокомерии архитектора".
А вот это замечательное ЧСВ Александера мы как раз и задействуем, дабы обойтись без промежуточного шага -- построения формальной модели системы как дополнительного технического "технического задания" кодировшикам.
На входе имеем ТЗ на естественном языке, которое напрямую, без излишних промежуточных абстракций транслируется человеком пошаговыми мета-инструкциями в исходный код. Необязательно причем результирующий код должен быть функциональным. Сойдет совершенно любой императивный язык, дело исключительно в стиле вычислений.
Отсюда, очереное уточнение:) Какими должны быть эти пошаговые мета-инструкции, дабы любой вменяемый разработчик мог, эээ "механически" им следуя, создать из исходного ТЗ на естественном языке систему любой сложности, "покрыв" это ТЗ минимально необходимым функционалом. Фактически, такой набор инстукций и является грамматикой, порождающей конечный код.
В темку, можно почитать и про анти-паттерны.
"Божественный Объект, от англ. God Object - небольшая часть кода, где сконцентрировано всё. Буквально всё. Возможно, там даже прячется немаленьких размеров галактика. Весь прочий код программы - исключительно декорация вокруг Божественного Объекта".
Об этом Божественом Объекте Александер и говорит:
"Можно строить здания, нанизывая паттерны в достаточно произвольном порядке. Такое здание будет просто собранием паттернов. В нем нет плотности. Нет основательности. Но можно объединять паттерны и так, что в одном и том же физическом объеме они будут перекрывать друг друга. Тогда здание получается очень плотным, в небольшом пространстве сосредотачивается много функций. За счет такой плотности здание приобретает основательность".
Иными словами, при проектировании системы очень важно постоянно удерживать чувство её основательности.
Значит, мы двигаемся в правильном направлении.
"Методики ООП отражают разные подходы. Вы можете сформулировать задачу письменно, выделить из получившейся фразы существительные и глаголы, после чего создать соответствующие классы и операции. Другой путь - сосредоточиться на отношениях и разделении обязанностей в системе. Можно построить модель реального мира или перенести выявленные при анализе объекты на свой дизайн".
Немного поразбираем Гамму:
"Не объявляйте переменные как экземпляры конкретных классов. Вместо этого придерживайтесь интерфейса, определенного абстрактным классом. Это одна из наших ключевых идей".
Отсутствие переменных -- это в принципе одна из ключевых идей функционального программирования.
"Композиция объектов - это альтернатива наследованию класса. В этом случае новую, более сложную функциональность мы получаем путем объединения или композиции объектов. Для композиции требуется, чтобы объединяемые объекты имели четко определенные интерфейсы.
Поскольку подклассу доступны детали реализации родительского класса, то часто говорят, что наследование нарушает инкапсуляцию. Это подводит нас ко второму правилу объектно-ориентированного проектирования: предпочитайте композицию наследованию класса.
Хорошо бы, чтобы можно было получить всю нужную функциональность, просто собирая вместе уже существующие компоненты. На практике, однако, так получается редко, поскольку набор имеющихся компонентов все же недостаточно широк".
Но функциональное программирование как раз компенсирует этот недостаток вычислительными мета-механизмами.
"С помощью делегирования композицию можно сделать столь же мощным инструментом повторного использования, сколь и наследование. Делегирование показывает, что наследование как механизм повторного использования всегда можно заменить композицией".
А я о чем говорил!:)
"Трудно представить себе, как предложить "полный" набор паттернов, из которого можно было бы вывести пошаговые инструкции по созданию приложения. Нам кажется маловероятным, что когда-либо будет создан полный язык паттернов для проектирования программ".
Фактически Гамма постоянно говорит о мета-программировании, однако немного ограничивает себя объектным подходом.
Про пошаговые инструкции: в заключение Гамма упоминает Кристофера Александера -- уникального человека, который написал книгу "The Pattern Language", ставшую культовой у архитекторов, а затем и проектировщиков.
Из нее, собственно, концепция паттернов проектирования и выросла.
"По мнению Александера основной задачей при декомпозиции системы является выполнение следующих двух условий:
- максимизация связей внутри компонентов (высокое сцепление, high cohesion) и
- минимизация связей между компонентами (низкая связанность, low coupling).
Сегодня эти проблемы широко известны в программной индустрии и описаны в любой книге по проектированию и построению программных систем, но, если верить Александеру, они присущи проектированию любых сложных систем...
В отличие от "чистых" системщиков Александер стремится создавать некие целостности, способные к относительной самостоятельности в поведении и развитии, тогда как взгляд с функциональных позиций обречен на выхватывание и гиперболизацию одного качества, стороны, свойства и т.п.
Открытая система не поддается схематизации, ее невозможно свести только к механической совокупности элементов. Иначе говоря, открытая система не создается с помощью конструктора. Она не только самоорганизуется, но зависит от среды".
http://www.taby27.ru/tvorcheskie_raboty/pro-arxitektorov-dizajnerov-xudozhnikov/kristofer-aleksander.html
Но мне как раз кажется, что в пошаговых инструкциях ничего плохого нету. Тут важно не путать пошаговые инструкции и конструкторы/схематизаторы. Условно говоря, пошаговые инструкции должны быть пошаговыми мета-инструкциями.
Работа "Язык шаблонов: города, здания, строительство" квалифицируется критиками как своеобразная "порождающая грамматика" подхода Александера".
Но порождающие грамматики -- это любимейшее развлечение функциональных программистов! Вот например в тему, про цепки Маркова и DSL-языки (http://habrahabr.ru/post/134291/).
"Некоторые тезисы, вроде отрицания проектирования на бумаге, по мнению критиков, свидетельствуют о высокомерии архитектора".
А вот это замечательное ЧСВ Александера мы как раз и задействуем, дабы обойтись без промежуточного шага -- построения формальной модели системы как дополнительного технического "технического задания" кодировшикам.
На входе имеем ТЗ на естественном языке, которое напрямую, без излишних промежуточных абстракций транслируется человеком пошаговыми мета-инструкциями в исходный код. Необязательно причем результирующий код должен быть функциональным. Сойдет совершенно любой императивный язык, дело исключительно в стиле вычислений.
Отсюда, очереное уточнение:) Какими должны быть эти пошаговые мета-инструкции, дабы любой вменяемый разработчик мог, эээ "механически" им следуя, создать из исходного ТЗ на естественном языке систему любой сложности, "покрыв" это ТЗ минимально необходимым функционалом. Фактически, такой набор инстукций и является грамматикой, порождающей конечный код.
В темку, можно почитать и про анти-паттерны.
"Божественный Объект, от англ. God Object - небольшая часть кода, где сконцентрировано всё. Буквально всё. Возможно, там даже прячется немаленьких размеров галактика. Весь прочий код программы - исключительно декорация вокруг Божественного Объекта".
Об этом Божественом Объекте Александер и говорит:
"Можно строить здания, нанизывая паттерны в достаточно произвольном порядке. Такое здание будет просто собранием паттернов. В нем нет плотности. Нет основательности. Но можно объединять паттерны и так, что в одном и том же физическом объеме они будут перекрывать друг друга. Тогда здание получается очень плотным, в небольшом пространстве сосредотачивается много функций. За счет такой плотности здание приобретает основательность".
Иными словами, при проектировании системы очень важно постоянно удерживать чувство её основательности.