ООП vs структурное программирование

← →
Pat © (2004-12-15 00:15) [0]

Люди!!! Нужно доказать, что ООП по всем параметрам лучше, чем структурное программирование :-) А именно, ситуация примерно следующая: имеется одна программка, написанная лет так 5 назад на Делфи. Собственно, она делает некоторые математические вычисления. Написан модуль с набором функций, которые со всем очень даже неплохо справляются. Далее этот проект перешел в руки другому программисту. Возникла ситуация, когда надо добавить еще некоторую функциональность. Так вот, "вдруг" посыпались глюки - перестало правильно работать даже то, что раньше работало на ура. Отловили глюк достаточно быстро - оказалось, что в другом модуле была заведена дублирующая глобальная переменная. Вот после этого и пришли в голову мысли - а почему бы не переписать это дело с использованием ООП. Только вот попросили обосновать почему именно нужно переходить на ООП и переписывать программу.
Внимание вопрос © "Что?Где?Почем? :-) Необходимо перечислить преимущества ООП перед структурным программированием.

P.S. Где-то пол года назад была ветка о целесообразности оформления математических модулей в объект. Собственно, поэтому и всплыл такой вопрос....

← →
DrPass © (2004-12-15 00:19) [1]

> Нужно доказать, что ООП по всем параметрам лучше, чем структурное
> программирование :-)

Это тебе нужно адвоката нанимать - только у них хорошо получается выдавать ложь за истину

← →
Ihor Osov'yak © (2004-12-15 00:21) [2]

> Люди!!! Нужно доказать, что ООП по всем параметрам лучше, чем структурное программирование :-)

Я бы не ставил так однозначно вопрос..

> Отловили глюк достаточно быстро - оказалось, что в другом модуле была заведена дублирующая глобальная переменная.

Сей "глюк" не имеет никакого отношения к проблеме ООП vs структрурное..
Тем более в отражении на реалии Делфи.

← →
AlterEgo of WondeRu © (2004-12-15 00:22) [3]

думать не стоит... слудует на ООП переходить без вопросов! Я уже 2 года делаю научную работу по обработке изображений с использованием различных математических алгоритмов... на объекты перешел после месяца засовывания приличного математического аппарата в Делфу...
Определенных преимуществ сказать не могу, но избавление от глобальных переменных стоит того!

← →
Игорь Шевченко © (2004-12-15 00:26) [4]

> Только вот попросили обосновать почему именно нужно переходить
> на ООП и переписывать программу

Сравни цену исправления ошибки (потребное время*зарплата) и цену переписывания программы (потребное время*зарплата+потребное время на исправление ошибок(в кубе)*зарплата). Что выгоднее, тем и нужно заниматься.

← →
Pat © (2004-12-15 00:29) [5]

>Ihor Osov"yak © (15.12.04 0:21) [2]
Дык ясен пень, что все зависит от задачи, а то может получиться, что будем стрелять из пушки по воробьям. Просто нужно по-красивому обосновать переход на ООП (много красивых и умных слов :0). Избавление от геморроя с глобальными переменными не канает - руководитель не программист

← →
Чеширский_Кот © (2004-12-15 00:30) [6]

а что было до структурного программирования?

← →
Юрий Зотов © (2004-12-15 00:31) [7]

Что-то вспоминается известная байка про русского, китайских, канадского и индийского программистов...
:о)

← →
AlterEgo of WondeRu © (2004-12-15 00:33) [8]

Pat © (15.12.04 0:29) [5]
Просто нужно по-красивому обосновать переход на ООП
ясна! хотите бабки стрясти с шефа на развитие "программерской мысли и др. НИР"!

← →
Чеширский_Кот © (2004-12-15 00:35) [9]

ЮЗ, расскажи, плиз

← →
AlterEgo of WondeRu © (2004-12-15 00:38) [10]

Больница совершила недопустимую операцию и будет закрыта...

← →
vecna © (2004-12-15 00:38) [11]

не нада про индийский программистов, лучше уж сразу про чукотских!

← →
Ihor Osov'yak © (2004-12-15 00:38) [12]

2 [5] Pat © (15.12.04 00:29)

> Просто нужно по-красивому обосновать переход на ООП

Ну ты же сам написал - "все зависит от задачи"...

Конечно, при решении задачи с нуля в большинстве случаем следуя парадигме ООП результат будет быстрее, дешевле и стоимость сопровождения будет ниже.. Но. Из правила есть исключения. А в твоем случае сравниваются вообще не совсем соизмеримые вещи - с одной стороны простой багфиксинг, а с другой - редизайн решения (см. [4]).
Зы. Может просто немного ограничить область видимость глоальгых, убрав по мере возможности их с interface секции в implemrntations.. Можно даже убрать все, а для доступа извне модуля предусмотреть функции и процедуры виде Get_ и Set_ (по мере необходимости) - тогда каждый модуль будет функциональным аналогом статического класса с одним единственным экземпляром инстанции..

← →
Ihor Osov'yak © (2004-12-15 00:41) [13]

2 [7] Юрий Зотов © (15.12.04 00:31)

Про канадского я еще не слышал...

Зы. А вот недавно пришлось доделывать проект после румын.. Кошмар.. Я бы такого нарочно не придумал.. Хотя, вероятнее всего, дело не в том, что они румыны были...

← →
Юрий Зотов © (2004-12-15 00:44) [14]

> Чеширский_Кот © (15.12.04 00:35) [9]
http://www.xxp-design.ru/index.asp?mode=314&typ=lek

На всякий случай обращаю внимание модераторов, что это даже не оффтоп.
:о)

← →
AlterEgo of WondeRu © (2004-12-15 00:54) [15]

Юрий Зотов © (15.12.04 0:44) [14]
классная ссылка, понравилось:
"К счастью, все это не сильно влияет на дела фирмы, поскольку продукт продается и так. Поэтому менеджмент ходит в целом довольный и не устает напоминать всем, что они отобраны как лучшие среди лучших. И что мы давно доказали свою способность выпускать продукт тем, что выпускаем его иногда."

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

← →
Ihor Osov'yak © (2004-12-15 00:55) [16]

В продолжение офтопа..

Через одну местную софтовую команду иногда делаю работу для одного американа.. На того американа работает еще группа индусов. Так вот, американ говорит, что индусы за выполнение работы обычно ставят раза в два ниже цену по сравнению с нашими... Для меня это было немного неожиданым..
Правда, довольно часто случается. что соотв. заказ возращается нашим через месяц-другой после того, когда его якобы индусы взялись делать за в два раза меньшие деньги..
Так вот вопрос - действительно ли индусы работают за такие низкие деньги? Я то по наивности считал, что в плане денег exUSSR чуть не самые скромные запросы..

← →
AlterEgo of WondeRu © (2004-12-15 00:57) [17]

Hаши баги мы для совместимости сохраним в следующих версиях.

← →
Чеширский_Кот © (2004-12-15 01:01) [18]

> Юрий Зотов © (15.12.04 00:44) [14]
> http://www.xxp-design.ru/index.asp?mode=314&typ=lek

прикольная сцылка

← →
Sergey_Masloff (2004-12-15 08:39) [19]

Pat © (15.12.04 00:15)
>Люди!!! Нужно доказать, что ООП по всем параметрам лучше, чем >структурное программирование
Ну, если с доказательствами проблемы так может оно не так? Или не всегда так?

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

← →
TUser © (2004-12-15 10:04) [20]

У каждой технологии есть свои преимущества. Имея часто дело с расчетными задачами, могу сказать, что в подавляющем большинстве случаев ООП не требуется в объеме большем, чем TForm1 = class(TForm). Структурное - рулит. Иногда удобно бывает и наоопить чего-нибудь. Вот из недавних примеров - писал программу структурными методами, постоянно попадались динамические массивы, чтобы не перераспределять память по каждому поводу - писал везде конструкции типа
MyRec:
record
Count: integer;
Array: array of TMyType;
end;
После пятой или шестой - забил, сделал класс, типа TList"а и наследников. Так гораздо лучше.

← →
марсианин © (2004-12-15 22:56) [21]

> После пятой или шестой - забил, сделал класс, типа TList"а
> и наследников. Так гораздо лучше.

как жаль, что в делфи нет STL

← →
iZEN © (2004-12-16 04:54) [22]

Межязыковые барьеры пока преодолеваются только структурными подходами, а не ООП.

"Плоский" API рулит там, где нужно объединить два и более языка под одним флагом (DLL) - про MS COM умолчу, ибо это бинарный стандарт под одну платформу (Windows).

Мне приходилось решать обратную задачу: оборачивать "плоским" API объектно-ориентированную систему, чтобы её приспособить для работы с другой ООП-системой, а именно делал обёртку над Delphi-классами (объектами) для нативных вызовов в Java - там понимаются только C-подобные заглушки в виде DLL, эта DLL была написана на Delphi и удачно использована в проекте на Java.

← →
NetKnight (2004-12-16 12:05) [23]

JAVA юзающая dll? Это как? JAVA - кроссплатформенная, а dll - M$ only. Так как они стыкуются? JNI?

← →
Igorek © (2004-12-16 13:38) [24]

Pat © (15.12.04 0:15)

> Нужно доказать, что ООП по всем параметрам лучше, чем
> структурное программирование

Сомневаюсь, что кто-то докажет.

> марсианин © (15.12.04 22:56) [21]
> как жаль, что в делфи нет STL

А может, вместо STL SDL подойдёт?

http://www.delphikingdom.ru/asp/viewitem.asp?catalogID=891

> Межязыковые барьеры пока преодолеваются только структурными
> подходами, а не ООП.

Немножко не так.
Межъязыковые барьеры преодолеваются (без "пока") на уровне среды исполнения, а не на уровне языка.
Аксиома.

Всё остальное -- следствия.

Чеширский_Кот © (15.12.04 0:30) [6]
а что было до структурного программирования?
а до структурного было линейное ... если интересует эта тема то советую почитать Буча книгу называется чтото вроде "Основы ООП"
там очень исчерпывающе описано ... и доступно

по теме: как можно сравнивать инструменты или методы вернее, типа как лучше забивать гвозди, прямо или загибать шляпку, большинство делает как получится ... а профессионалы так как надо в конкретном случае ... если надо реализовать мат. функции, зачем городить классы ... усложнит отладку, ИМХО конечно ...

← →
Fantasist (2004-12-16 18:57) [29]

>
> А может, вместо STL SDL подойдёт?
>
> http://www.delphikingdom.ru/asp/viewitem.asp?catalogID=891

А кто-нибудь реально этим пользовался? Я качал, смотрел, но меня все-таки смутило то, что построенно все на variant. Довольно очевидно, что этот тип менее продуктивен. Правда вот VB весь на вариантах работает и ничего.

← →
aus (2004-12-16 19:12) [30]

>Избавление от геморроя с глобальными переменными не канает - руководитель не программист

Тогда как ты ему докажешь, что лучше?
Скажи, что ООП лучше звучит:
ООП...ООП..ООП...

/**NetKnight (16.12.04 12:05) [23]
JAVA юзающая dll? Это как? JAVA - кроссплатформенная, а dll - M$ only. Так как они стыкуются? JNI?
*/
Оно самое. Неважно, DLL (Windows) или .SO (UNIX) - JNI реализуется плоским API на C и компилируется в бинарные (загрузочные) модули операционной системы. Далее в Java подгружается эта библиотека и работает всё-в-одном флаконе. И не жужжит.

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

В моём случае несколько проще: Delphi для Windows может собирать код, бинарник которого будет совместим по сигнатурам/вызовам с аналогичным сишным.

я скачал, но не использовал.

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

с STL-классами примерно так же. хоть, там замедление и незначительно, в некоторых случаях предпочтительнее использовать, скажем, массивы в стиле С.

Григорьев Антон © (16.12.04 13:44) [25]
А может, вместо STL SDL подойдёт?
http://www.delphikingdom.ru/asp/viewitem.asp?catalogID=891

Млин раз 10 заходил на Королевство и всегда убегал оттуда. Дизайн непонятный, какие-то рыцари, подземелья, маги - нифига не поймешь. Еще и графики много. Не программерский сайт а фентези. :-)

> Igorek © (17.12.04 01:49) [33]
> Млин раз 10 заходил на Королевство и всегда убегал оттуда.
> Дизайн непонятный, какие-то рыцари, подземелья, маги - нифига
> не поймешь. Еще и графики много. Не программерский сайт
> а фентези. :-)

По-моему, достаточно просто один раз посмотреть карту сайта, и всё станет понятно :)
Адрес карты - http://www.delphikingdom.com/map.asp

А программерский сайт или нет - это определяется не оформлением, а количеством и качеством материала :)

ООП vs структурное программирование Найти похожие ветки