Navespro.ru

Расширяемость

Чем большая программа отличается от маленькой? Ее труднее сделать,
куда более труднее, существенно труднее. А маленькую — легко.
Ну так давайте делать только маленькие программы!

...Разработка ПО по-английски называется development —
дословно, развитие. Есть такой принцип: от простого к сложному.
И есть инкрементальная модель разработки.

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

Важно, чтобы изменения можно было производить локально. Т.е. отдельное
изменение затрагивало небольшую часть программы, иначе нет смысла ее
изменять — проще переписать все заново целиком. Для этого программу
нужно разделить на несколько автономных частей. Возьмем процедуру в
смысле, например, языка Pascal. Является ли она автономной частью? Тут
возможны варианты...

1. ответ: нет, если используются глобальные переменные
   • попробуйте вставить текст этой процедуры в другую программу —
     она не будет работать, необходимо перенести еще и глобальные переменные;
   • при использовании этой процедуры несложно породить ошибку: если процедуре
     не передать фактический параметр, то компилятор будет ругаться, а если
     не инициализировать глобальную переменную?
2. также плоха процедура без комментария о ее предназначении, о том, как ее
   использовать — мало того, что для ее понимания нужно изучить
   ее исходный текст, при изменении ее реализации могут пострадать пользователи,
   использующие процедуру не так, как хотел ее автор, а использующие
   недокументированные возможности.

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

Параметром может быть не только отдельная операция, но и целый тип данных
(скорее — переменная определенного типа данных). Рассмотрим
оконную систему. Она позволяет отображать на экране виджеты (кнопки, полосы
прокрутки и т.п.) и заставляет их реагировать на различного рода события.
Для этого типы данных виджетов должны поддерживать операцию Draw (которая
красиво рисует этот виджет) и Handle (которая реагирует на переданное в
качестве параметра сообщение о событии). Т.о. можно один раз реализовать
оконную систему, отладить и зафиксировать. Далее расширять систему путем
разработки новых виджетов. А оконная система сможет их все использовать,
т.к. они все поддерживают необходимые операции Draw и Handle.

Итак, по скромному мнению автора этой статьи, отличительной чертой
ООП является способность типа данных A работать с типами данных,
объявленных и реализованных позже (т.е. неизвестных для A).Это включает
не только полиморфизм (как позднее связывание методов), но и т.н. отражение
(reflection, элемент метапрограммирования) — способность
создавать во время выполнения программы переменные нужного типа данных,
зная лишь его имя, указанной в виде строки (см. платформы Java и .Net,
а также Oberon System).

Последние новости