Объектно-ориентированное программирование (ООП)

 

Сложности процедурно-ориентированной разработки

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

Основная проблема здесь - разрозненность процедур и функций, что ведёт к затруднениям хранения глобальных данных. Разрозненные процедуры не знают с какими значениями им работать, т.е. они могут работать с определённым набором данных, но не знают где его взять. Приходиться либо передавать данные процедуре в виде параметров, что приводит к сильному разрастанию заголовка, либо хранить их как глобальные переменные (зачастую это массивы), что также не желательно.

 

Листинг 1.1

Type MyRez=record

Name:string;

Number:integer;

Source: file of byte;

Count:integer;

end;

Var Name: MyRez;

Procedure Rec(DC:CDC; x,y:integer; w,h:integer; color:TColor; 3D:Boolean; vis:file);

Procedure ExecFunc(text1:file; text2:file; cod:integer; pam1:string; pam2:string; pam3:byte; cloud: TForm; MyBat:TSpeedButton; shell:TColor);

Function FindPazzle(size:integer; temp:string; pam1:string; pam2:string; pam3:byte):MyRez;

 

Здесь мы видим, что у нас есть две процедуры и функция с большим количеством входных и выходных параметров. Коментарии отсутствуют, потому что неочень опытные или начинающие программисты писать их не любят. Всё достаточно запутано. Если этот код попадёт на доработку другому человеку, то, наверное, у него возникнет ряд впросов, которые могут завести доработку в тупик:

· для каких целей используются эти методы;

· можно ли их вызовать в произвольном порядке;

· что будет являться результатом работы;

· налагаются ли какие-либо ограничения на параметры;

· что представляют собой входные/выходные файлы и т.д.

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

 

Листинг 1.2

Var P:integer; // 0..10

Implementation

{$R *.dfm}

procedure TForm1.Timer1Timer(Sender: TObject);

Begin

p:=1;

end;

procedure TForm1.Timer2Timer(Sender: TObject);

Begin

p:=2;

end;

Здесь мы видим обработчики событий двух таймеров. Если они будут иметь разные интервалы срабатывания, то глобальная переменная P будет менять значение с 1 на 2, и наоборот в практически случайные моменты времени. Если от этой переменной зависят внешние процедуры, то может произойти сбой. Который связан с тем, что программист не ожидал появления, например, цифры 2 в какой-то промежуток времени. Показаный пример достаточно условный, но он позволяет понять, что может произойти с глобальной переменной внутри циклов, рекурсии, работы с несколькими таймерами и потоками, если нет должного контроля.

Когда реализуется задача процедурно-ориентированным методом, часто возникает ещё одно узкое место, которое связано с парадигмой данного метода программирования. Оно связано с присваиванием глобальным переменным какого-то значения, точнее, с отсутствием контроля за величиной этого значения. Расмотрим пример, когда такого контроля нет.

Пусть по условию у нас есть переменная G целого типа integer и она может принимать значения в диапазоне 0..10, и используется, как индекс текущего элемента в динамическом массиве. Далее пусть программа, содержащая этот код, предлагает пользователю ввести вручную номер выбранного элемента в массиве, который будет записан в переменную G. Пользователь, не зная выше указанного ограничения, вводит 12. Это число является целым и входит в диапазон возможных значений типа Integer, поэтому программа разрешает присвоение этого значения переменной G. А далее происходит обращение к элементу с таким индексом, но его нет, и тут возникает ошибка времени исполнения.

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