Лаборатория Январева

Написание этой заметки совпадает у меня с формальным изучением RUP (Rational Unified Process) и проектированием систем в UML. В мировом масштабе сейчас лидирует объектно-ориентированная парадигма написания ПО, на старте находятся фреймворки и паттерны проектирования (GoF).

Благодаря своей родной кафедре я сумел познакомиться с логической и функциональной парадигмой написания программ в Лиспе, Рефале и Прологе. Некоторый класс задач гораздо удобнее решать с использованием этих языков.

Сам я пишу Web-сайты на PHP, знаю, что многие делают также и очень этим довольны, несмотря на то, что люди, пишущие в нем не очень часто используют классы. Кроме того, в Web-программировании набирает большие обороты Ruby-on-Rails.

Хочу немного поразмышлять по этому поводу.

Анализ

Как известно, в самых первых ЭВМ программисту приходилось самостоятельно прописывать адреса данных в памяти, а затем к ним обращаться. Далее появились переменные, и программы стало писать проще, поскольку переменные брали на себя большую долю стандартных операций (на уровне языка). Переменные чаще всего инкапсулировали в себя несколько байт данных памяти.

Функции позволяют стандартным образом преобразовывать несколько переменных.

Классы объединяют в себя множество организованных данных и функций. При это объекты - это области данных.

Итак, можно заметить следующие тенденции в эволюции процесса написания ПО:

• Каждый последующий уровень организует в себе несколько предыдущих.
• Есть цикл (данные->функции->данные). Это уже не так тривиально, но довольно естественно. Представим себе ситуацию, когда у нас хорошо организованы данные. Естественно хорошо организовать (спроектировать) процесс их обработки. Представим себе, что хорошо спроектирован процесс обработки (много хороших функций). Естественно ограничить область их действия некоторым классом данных.

Паттерны проектирования - следующий этап, на мой взгляд, не до конца осознанный. Сами авторы говорят, что паттерн проектирования - это набор классов, который решает определенную задачу (!), но при этом они же говорят, что строили каталог паттернов на основе анализа существующих систем. Т.е. шли не от задачи, а от практики.

Гипотеза о проблемно-ориентированном проектировании

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

1. Спроектировать систему так, чтобы она решала одну-единственную содержательную бизнес-задачу. Здесь можно использовать классические средства проектирования. Пусть решением будет создание классов A, Б, В.

2. Выявить задачи, стоящие перед системой. После выявления задачи модифицировать набор классов.

• Например, система должна поддерживать модульность. Ага - значит используем паттерн, допустим, Strategy и вводим управляющий класс (Шаблон Strategy позволяет передавать управление одной из доступных стратегий). Получаются классы А, Буп, Б1, Б2, Б3, В.
• Система в целях производительности должна поддерживать отсроченную загрузку данных. Решение - использование паттерна Proxy. Классы: А, Буп, Б1, Б2, Б3, Вproxy, B.

Применение

Попробуем применить данную модель для создания собственной CMS. Итак:

1. Напишем систему, которая выводит текущую страницу. Пусть это будет элемент X.

2.1. Напишем систему, которая будет выводить любую страницу по её названию.

• Опять - паттерн Strategy. Создаем элемент Y (управляющий), который умеет выдавать HTML-код текущей страницы, скажем, путем обращения к БД. В нужный момент вызываем его из X и возвращаем результат.

2.2 Напишем систему, которая умеет выводить не только страницы, но и гостевую книгу (а в перспективе и форум и т.д.).

• Паттерн Strategy, но в другом исполнении. Управляющим элементом будет элемент X (объединяем обычную функиональность и функциональность элемента паттерна). Создаем элемент Y1, который умеет выдавать код гостевой книги. В зависимости от запроса управляющий элемент X вызывает или Y или Y1.

Для не очень знающих людей могу сказать, что похожим образом архитектура выглядит во многих популярных CMS: PHP-Nuke, Joomla! и т.д.

Современные языки и фреймворки в свете гипотезы о проблемно-ориентированной разработке

Ой, писать много Ладно, освещу в следующем посте. Здесь лишь скажу, почему никогда не умрет PHP и Loader.load(”mymodule.swf”) во Флеше. Вести повествование буду на примере PHP.

PHP реализовал гениальную вещь еще до широкого распространения объектно-ориентированного стиля - он позволил реализовывать паттерн Strategy на функционалом уровне и очень просто. Одной строчкой.

include(”modules/”.$mymodule.”.php”);

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

Strategy - потрясающе мощный шаблон, на котором строится любая модульность. На мой взгляд, чем проще реализовать шаблон средствами некоторого языка программирования, тем больше вероятность, что он будет реализован, когда понадобится. Наиболее элементарный случай - простая делегация последующего исполнения некоторому модулю. И именно это реализуется в PHP одной строкой!

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

Аналогично во Флеше - куда проще подгрузить ролик, который пусть сам дальше разбирается, что клиенту от него нужно. Полное делегирование функциональности.

Квинтэссенция

Именно по причине наличия вышеупомянутых примеров, я предпочитаю говорить об элементах, а не об объектах. Если рассматривать весь процесс проектирования и базироваться на понятии задач, не всегда использование программных объектов является подходящим. Множество не ОО-языков живет и здравствует, потому что просто хорошо решает часто возникаемые задачи. При этом они используют паттерны проектирования, но совсем не объекты. Бывает и так.

Запись создана в Суббота, 3 Ноябрь 2007 г. в 4:13 пп. Рубрика: Мысли. Вы можете подписаться на комментарии к этой записи RSS 2.0. Вы можете оставить отзыв, или отправить trackback со своего сайта.