Бьерн Страуструп. Язык программирования С++. Специальное издание (2011) (1004033), страница 186
Текст из файла (страница 186)
Конечные автоматы, которые будут меньше, быстрее и корректнее чем то, что может произвести большинство программистов, могут генерироваться из спецификаций или на основе визуального манипулирования графическими образами. Подобные приемы хорошо работают в тех областях, где-либо имеется строгий и однозначный теоретический фундамент (математика, конечные автоматы, реляционные базы данных), либо есть готовый каркас, в который можно добавлять (встраивать) небольшие фрагменты кода (графический интерфейс пользователя, моделирование сетей, схемы баз данных). Очевидная польза от такого приема в ограниченных (чаше всего, принципиально ограниченных) областях может навести кое-кого на мысль о том, что полный отказ от традиционного программирования уже не за горами. Это не так. Фундаментальная причина состоит в том, что за полный отказ от программирования придется заплатить тем, что в относительно несложный в частных случаях язык формальных спецификаций придется внести сложность языков программирования общего назначения.
И где в таком случае будет выигрыш? Иногда также забывают, что сам стандартный каркас приложения, позволяюший избавиться от традиционного программирования в какой-либо конкретной предметной области, был спроектирован, запрограммирован и оттестирован традиционным способом. Язык С++ и описанные в нашей книге приемы проектирования и программирования широчайшим образом применяются как раз для разработки подобного рода систем.
В произвольных предметных областях попытка дизайнеров, ради борьбы со сложностью, придерживаться ограниченных высокоуровневых спецификаций приводит к тому, что обедняются используемые средства языка программирования обшего назначения и получается ужасный результируюший код. Для улучшения такого кода программисты вынуждены демонстрировать героизм и отказываться от навязанных высокоуровневых моделей. Лично я не вижу никаких признаков того, что традиционное программирование может быть успешно устранено отовсюду, кроме областей, где имеется твердый математический базис или приемлемые готовые каркасы приложений. Но даже в по.следнем случае эффективность разработок тормозится и сходит на нет, когда приходится выходить за первоначальные рамки и решать более обшие задачи. Ясно, что вредно и полностью отрицать пользу от каркасов и кодогенераторов на основе высокоуровневых спецификаций, и приписывать этим средствам универсальную силу.
Разработка инструментов, библиотек и каркасов является одной из высших форм проектирования и программирования. Построение полезной математической 899 24.2. Проектирование и язык программирования модели предметной области является одной из высших форм анализа. Наконец, самостоятельная разработка инструментов, библиотек и каркасов, которые будут доступны тысячам людей, есть еще и способ избежать зависимости от единственного инструмента, абсолютная привязанность к которому превратит любого программиста в ремесленника. Очень важно, чтобы система формализованных спецификаций или библиотека поддержки автоматизированной разработки могли эффективно взаимодействовать с языком программирования общего назначения.
Иначе получающиеся каркасы слишком уж ограничительны. Большое преимущество имеют системы, которые из высокоуровневых спецификаций генерируют код на общедоступном языке программирования общего назначения. Собственные внутренние языки программирования являются долгосрочным преимушеством лишь для поставщика такого решения. Также плохи автоматизированные решения, генерирующие слишком низкоуровневый код. В оптимальном случае нужен компромисс между удобством и простотой спецификаций высокого уровня (или графических манипуляций со зрительными образами) и выразительностью и богатством языка программирования общего назначения.
Пожертвовать здесь чем-либо одним в ущерб другому, значит пожертвовать интересами пользователей ради интересов непосредственных разработчиков системы. Успех больших разработок, которые всегда являются многоуровневыми и модульными, обуславливается привлечением и гармоничным сочетанием самых разных языков, библиотек, инструментов и технологий. 24.2.5. Применение исключительно классовых иерархий наследования Когда мы обнаруживаем, что нечто новое действительно хорошо работает, мы теряем чувство меры и применяем это уже без разбору.
Другими словами, удачное решение некоторых проблем кажется удачным решением для почти всех проблем. Классовые иерархии и полиморфные операции над их объектами действительно служат удачным решением многих проблем. В то же время, не каждую концепцию задачи можно удачно отобразить некоторой частью иерархии, и не каждый программный компонент реализуем в виде иерархии классов. Почему? Класс отражает некоторую концепцию, а классовая иерархия отражает взаимоотношение между классами.
Теперь скажите, что общего между улыбкой, СП-КОМ приводом, записью оперы, строчкой текста, спутником, моей медицинской картой и часами реального времени? Помещение всего этого в единую классовую иерархию, когда общность состоит лишь в том, что все это артефакты программирования (то есть просто объекты), не имеет фундаментального значения и ведет лишь к путанице Я)5.4.5).
Действительно, загоняя все в единую иерархию, мы создаем искусственное сходство и затушевываем реальное. На самом деле, развивать такие классовые иерархии нужно лишь тогда, когда анализ сущностей приложения выявил фундаментальную общность концепций, или когда в процессе проектирования и программирования открылась полезная общность в применяемых для реализации концепций структурах. В последнем случае нужно четко различать истинную общность (подтипизация с применением открытого наследования) и полезные упрощения реализации (с помощью закрытого наследования; 924.3.2.!).
860 Глава 24. Проектирование и программирование Такой образ мыслей приводит к программе, содержащей несколько несвязанных или слабо связанных классовых иерархий, каждая из которых представляет множество тесно связанных между собой концепций. Это также приводит к понятию конкретного класса 625.2), не входящего в иерархию, ибо помещение его в иерархию лишь испортит производительность и нарушит независимость такого класса от остальных частей системы. Чтобы быть эффективной, важная операция класса, входящего в иерархию, должна быть виртуальной функцией. Кроме того, большинство данных такого класса должны быть защищенными, а не закрытыми.
Это порождает их незащищенность от изменений в производных классах и затрудняет тестирование. Там, где с проектной точки зрения нужна большая инкапсуляция, следует применять невиртуальные функции и закрытые данные (824.3.2.!). Операции, у которых аргументы не равноправны (один из операндов может трактоваться особо как «объект»), искажают логику проектов, ориентированных исключительно на классовые иерархии. Если же при этом аргументы должны трактоваться равноправным образом, операцию лучше не делать функцией-членом. Это не значит, что она должна стать абсолютно глобальной — ее можно ввести в пространство имен (824.4).
24.3. Классы Наиболее фундаментальной идеей объектно-ориентированного проектирования и программирования является взгляд на программу, как на модель определенных аспектов реальности. Классы в программе соответствуют фундаментальным концепциям приложения, и, в частности, фундаментальным концепциям моделируемой реальности.
Объекты реальности и артефакты реализации представляются с помощью объектов этих классов. Анализ взаимоотношений между классами и между разными частями классов— центральная часть проекта системы: ° э24.3.2 Отношения наследования ° з24.3.3 Отношения включения ° 824.3.5 Отношения использования ° 824.3.6 Программируемые отношения ° з24.3.7 Отношения внутри класса Поскольку класс языка Сч--ь — это тип, классы и их взаимоотношения получают значительную поддержку компилятора и в общем случае поддаются статическому анализу. Чтобы класс можно было удобным образом вписать в проект, он не только должен представлять собой полезную концепцию, но еще он должен предоставить подходящий интерфейс. Идеальный класс имеет четко определенную минимальную зависимость от остального мира и интерфейс, который выдает минимум информации, необходимой внешнему миру (924.4.2).