Суть современного программирования

Если в 80-х годах повсеместно применялось, в основном, процедурное программирование, то с приходом в начале 90-х графических сред наподобие Windows, сопровождающееся значительным усложнением структуры и размеров программного кода, возник вопрос использования новых, более прогрессивных средств. Таковыми оказались объектно-ориентированные языки программирования - такие, как C++, а немного позже к ним добавились новые, например, язык Java или полностью переработанные старые - ObjectPascal.

ПРИМЕЧАНИЕ
Собственно говоря, язык C++ так же является переработанным вариантом процедурного языка C, только появился он гораздо раньше - в 1982 году. Что касается языка Pascal, то в принципе, первой попыткой переложения его на объектно-ориентрованное применение можно считать такую ветвь, как язык Ada.

Увеличение сложности программ привело не только к появлению новых инструментов, упрощающих разработку, но и повлекло за собой кардинальной пересмотр путей подхода к решению поставленной задачи. Так, если во времена DOS, программист, получив задание, сразу приступал к кодированию, то теперь этому предшествует этап анализа и предварительной разработки. Более того, теперь существует несколько специализаций, причем не всех их можно назвать программистами в привычном смысле этого слова. Это системные аналитики, дизайнеры интерфейса, программные инженеры, собственно "кодеры" и другие. Впрочем, такое многообразие больше характерно для крупных коллективов, решающих объемные задачи. В более простом и прагматичном случае все эти обязанности выполняет один человек.

Итак, что же делать разработчику, получившему задачу по созданию того или иного приложения? Прежде всего, требуется проанализировать поставленную задачу, т.е. определить, какой вариант решения поставленного вопроса будет наиболее правильным, и что понадобится для его реализации. В простейшем случае понадобятся только компьютер и установленная на нем среда Delphi. Для решения более сложных задач могут понадобиться другие программы (начиная от приложений баз данных и заканчивая графическим редактором), а возможно - и другие специалисты, как-то другие программисты, 3D-моделисты, художники, технические писатели и т.д. На этом этапе так же важно взаимодействие с заказчиком проекта для внесения полной ясности в понимание того, чего все-таки требуется от программы, возможности внесения изменений, увеличения или уменьшения функциональности и т.п.

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

На этапе детальной разработки следует перейти к определению конкретных составляющих программы - от общей структуры проекта до отдельных диалоговых окон, схемы поведения, вариантов вывода отчетов и т.д. Следует так же продумать реализацию тех или иных алгоритмов, структуру хранения данных и прочие подобные вопросы. Детальная проработка этих вопросов до того, как начнется собственно процесс написания программы, существенно ускорит весь процесс и, возможно, избавит от многократного переписывания целых фрагментов программы.

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

Последним, и самым продолжительным этапом разработки, является сопровождение программы. Дело в том, что никакое тестирование не выловит все огрехи кода в большой программе. Поэтому выявление пользователями различных "недокументированных возможностей", а, попросту говоря - ошибок, может продолжаться ровно до тех пор, пока данное творение используется вообще. Кроме того, заказчику со временем наверняка захочется получить какие-либо дополнительные, ранее не предусмотренные возможности, изменить вид или тип поведения для тех или иных модулей и т.д.

Разумеется, для всего этого придется вновь и вновь возвращаться к написанию исходного кода. Таким образом, можно сказать, что отладка и сопровождение - поздние фазы этапа кодирования. В то же время, не будем забывать, что в целом программа готова уже после того, как закончился этап основного кодирования - именно там, где мы его определили, т.е. до начала тестирования. Но, опять-таки, тестирование тоже бывает разным - в практике выделяют несколько его фаз, а именно:

• Альфа-тестирование. Это предварительный вариант программы, на этапе выпуска альфа-версии функциональность продукта, как правило, не является полной;
• Бета-тестирование. После того, как с одной стороны, исправлены ошибки, выявленные при альфа-тестировании, а с другой - завершено функциональное наполнение продукта, выпускают бета-версию;
• Финишная подгонка, или Pre-Release. С некоторых пор вошло в моду предварять выход окончательной версии предварительным выпуском (PR, RC). На этот момент программа должна на 100% соответствовать тому, что ожидается в окончательной версии (Release), суть же выпуска такой версии - убедиться еще раз, что все в порядке.

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

Использование объектно-ориентированного подхода как раз и служит для того, чтобы разработчику было проще ориентироваться в исходном коде, и минимизировать, или даже локализовать допущенные при кодировании ошибки.

Классы и объекты

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

В ООП описания объектов называются классами (class). Фактически, класс является дальнейшим развитием уже знакомого нам типа данных - записи. Но если запись имела только свойства (поля) и ничего более, то классы могут содержать все, что требуется для полноценного объекта. При этом класс может быть сколь угодно большим и иметь в качестве своих свойств другие классы. Например, класс "машина" может иметь в своем описании такие свойства, как двигатель, шасси и им подобные, представленные другими классами. При этом для каждого такого класса так же могут быть определены собственные свойства и методы.

Самими же объектами в программе называют не классы, а их экземпляры. Т.е. если мы имеем класс TCar, то его экземпляр, представленный в виде переменной типа TCar (скажем, MyCar), как раз и будет объектом. Чтобы использовать объект, его надо предварительно создать. Делается это при помощи специального метода, который определен для всех классов - Create, называемый так же конструктором класса. Соответственно, чтобы получить объект, являющийся экземпляром класса, мало объявить переменную - надо еще и проинициализировать его при помощи конструктора:

varMyCar: TCar;

 ...

MyCar.Create;

Разумеется, каждый класс может иметь множество своих экземпляров. Скажем, кроме объекта MyCar, могут быть еще BossCar, AnyCar, Truck23, Bus144 и т.д. Все эти переменные называются переменными-экземплярами класса.

Другой составляющей ООП являются 3 концепции, применяемые к классам - инкапсуляция, наследование и полиморфизм. И хотя в предыдущей части книги мы уже рассмотрели все эти термины, вспомним их суть здесь еще раз, причем уже применительно к практическому применению классов.

Так, инкапсуляция, или объединение в единое целое всего того, что относится к определенному объекту, на практике выливается в возможность объединить в одном объекте свойства и методы. Наследование позволяет, единожды создав некий обобщенный класс, пользоваться его свойствами и методами из других классов, созданных на его основе - в классах-потомках. Ну а применение полиморфизма на практике позволит переопределить свойства или изменить поведение отдельных методов родительского класса в этих самых классах-потомках.

В результате всего этого достигается более компактный и понятный код. В частности, благодаря инкапсуляции, для изменения состояния объекта достаточно обратиться к его же методу, а не использовать отдельную функцию. Наследование - это замечательная вещь для многократного использования единожды написанного кода. Ну а полиморфизм позволяет в родственных классах одинаково называть методы, отличающиеся в программной реализации, но одинаковые по своей сути.