Человеческий фактор в программировании
Шрифт:
Визуальное проектирование дает возможность думать в двух режимах одновременно. Первый режим — аналитический, последовательный — сопровождается использованием языка и выражением процессов в виде кода. Второй режим — пространственно-визуальный — мы применяем, когда что-то рисуем, или строим с помощью конструктора Lego, или составляем диаграмму. Таким образом, визуальное программирование напоминает апгрейд центрального процессора вашего мозга, позволяя увеличить скорость ваших ментальных процессов и давая возможность решать более сложные задачи или быстрее строить системы.
Среды визуальной разработки также дают возможность изменять ход разработки. Люди, содействующие продвижению объектной технологии, го-ворят, что она обеспечивает «бесшовность»
Вместо того чтобы устраивать поминки по CASE, может быть, есть смысл визуализировать процесс разработки.
Из журнала Software Development, том 3, № 5, май 1995 г.
24
Цели программного обеспечения
Программист, проспавший большую часть последних десяти или двадцати лет, наверное, не знает о том, что такое объектно-ориентированное программирование. Остальные из нас уже сыты этими объектами по горло. Я испытываю некоторое сочувствие к этим ван Винклям [33] нашей отрасли, поскольку в 1986 году, когда я имел неосторожность вернуться в компьютерную индустрию, объектная технология уже была звездой, восходившей с головокружительной скоростью. А ведь за десять лет до этого, в пору моего последнего отсутствия в компьютерной области, объектно-ори-ентированное программирование было неизвестным хмурым карликом, скрытым в космосе непонятных компьютерных методов. Конечно, спустя десяток лет очень легко определять, какие тенденции проявлялись ранее.
33
Рип ван Винкль (Rip van Winkle) — герой одноименной новеллы В. Ирвинга (W. Irving, 1819), житель голландской колонии в Америке, который проспал 20 лет, выпив волшебное вино, поднесенное ему гномами.
Нельзя сказать, что объектно-ориентированный подход является особенно новым. Хотя некоторые авторы связывают провал структурных методов с возникновением объектно-ориентированных, на самом деле, структурное программирование и проектирование появилось почти одновременно с объектами, возникнув из одного первобытного болота неструктурных методов. Дейкстра (Dijkstra), Константин (Constantine), Кэй (Кауе), Даал (Dahl) и Сатерленд (Sutherland) — все эти люди работали параллельно в конце 60-х и начале 70-х годов, разрабатывая и распространяя основные понятия новых способов мышления о программах и программировании.
К середине 80-х годов концепции объектно-ориентированных методов уже сложились, хотя они и были не всегда понятными. Конечно, не было недостатка и в тех, кто уже тогда хорошо освоил ООП и мог решить с его помощью любую задачу. Не хватало только людей, которые могли бы дать ясные объяснения. В соответствии с риторикой того времени следовало сжиться с объектами, чтобы научиться думать и проектировать с их помощью.
«Как же можно объект уподобить информационному кластеру или модулю с информационным сцеплением?», — может спросить дотошный студент.
«Послушайте, — отвечает нетерпеливый преподаватель, — я же сказал вам забыть обо всей этой старой структурной чепухе. Это не работало. И пока вы не очистите кору головного мозга от этих вещей, вы ничего не поймете». (Подразумевается, что преподаватель даже и не знает, о чем спрашивает студент, поэтому пусть студент закроет рот и слушает.)
Многие из педагогов и демагогов, которые в то время занимались 00,
Если бы это было возможно! Предложения этих людей были больше похожи на религиозное обращение, чем на приобретение новых технических навыков и изучение новых понятий. Некоторые гуру объектно-ориентированной парадигмы все еще проповедуют таким образом. «Их нужно привлекать еще молодыми, пока их сознание еще не замутнено процедурами, и тогда вы сможете сделать из них истинных верующих». Приблизительно так говорят эти евангелисты.
Конечно, вплотную занявшись ОО, я быстро понял, что многие из тех ранних поборников были вынуждены занять такую евангелическую позицию. Ничего не зная о структурных методах или реляционных моделях данных, они не могли сказать что-то разумное о связи этих понятий с ОО и поэтому не могли рисковать, отвечая на серьезные вопросы своих более опытных студентов. Когда они все же упоминали принятые в то время методы разработки программного обеспечения, это всегда были нападки, напоминающие легкую игру в стрельбу по хорошо поставленным и структурированным целям.
Некоторая расплывчатость определений и полное отсутствие консенсуса относительно того, что можно считать основными понятиями в ОО, не улучшали положения бедного странника, ищущего объектно-ориентиро-ванного просветления. Однако со временем все установилось, и сегодня есть общепринятая терминология и концепции объектно-ориентированной парадигмы.
В 00 есть множество аспектов. Для некоторых этот подход является способом прожить, для других это образ жизни. Для того чтобы постичь 00 в полном его великолепии, следует понимать не только инкапсуляцию или сокрытие описания, но также и наследование, делегирование, универсальность, динамическое связывание и полиморфизм. (И люди еще говорят, что структурная революция навязала слишком много новых терминов!) Все эти понятия представляют собой важные аспекты данной парадигмы и ее практического применения, но реальная причина того, что в разработке программ объекты ждет большое будущее, намного проще.
В короткой статье невозможно описать все тонкости объектно-ориентированной парадигмы, но главные вопросы, связанные с человеческим фактором в программировании (peopleware), являются довольно простыми. (Написав эти строки, я уже слышу, как стучат клавиши, чтобы подготовить негодующие электронные письма, которые скоро будут переполнять мой ящик.)
Забудьте о шумихе, которую поднимают истинные верующие, говорящие вам, что объектно-ориентированные методы — это новый подход к обдумыванию задач. На самом деле это всего лишь «новый, улучшенный» завтрак из хлопьев — все дело в хорошей упаковке. Классы, которые являются необходимым компонентом объектно-ориентированного программирования, — это всего лишь улучшенные контейнеры для кода. Объектные классы имеют ряд преимуществ в сравнении с функциями и подпрограммами. Во-первых, классы — это большие и средние контейнеры. Чем больше составные блоки, тем большие системы можно построить из данного набора компонентов. Хотя объектные классы имеют большие размеры, они выглядят меньше и проще потому, что все объекты хитрым образом плотно упакованы в соответствии с каким-то одним общим понятием (например, КомпьютерныйКлиент или ЛазерныйПринтер). Благодаря этому образуется необходимая связка, которую легко узнать и перемещать. Да, вы складываете данные и процедуры в один блок, но это как раз те необходимые данные и процедуры, которые все вместе принадлежат одному блоку.
У такого блока даже есть утешительная надпись, во многом напоминающая о реальном мире клиентов и пользователей, что является вторым большим преимуществом объектов. Все остальное — это дополнительные преимущества, лежащие на дне коробки с хлопьями. Брад Кокс (Brad Сох), один из первопроходцев 00, имел обыкновение говорить всем, кто смотрел в его сторону хотя бы с малейшим интересом, что объектно-ориентированная революция в упаковке — это абсолютно то же самое, что и переход от дискретной электроники к микросхемам, то есть от транзисторов к чипам. Это небольшая разница, которая имеет большое значение.