ООП рулит!

сипп форева!

аффтопитезь

AklinООП рулит!

сипп форева!

аффтопитезь

ну да, еще:

автор...1. Согласны ли вы, что разбираться в большом проекте, написанным на ООП без наличия отрисовки его структуры гораздо сложнее чем в аналогичном процедурном?

2. Согласны ли вы, что менять структуру классов в работающей большой программе опаснее, чем менять функции в аналогичной процедурно написанной?

3. Правда ли то, что ОО-код работает медленнее процедурного?
...

1) категорически нет
2) если руки на месте, одно удовольствие, т.е. нет
3) не медленнее.

хотя опять же вопрос кривых рук (это аналогия на сисег) не раскрыт.

Frankie kolobok0Если Вы считаете, что это сложно или что то не понимаете - рекомендую обратиться к первоисточникам...К Гради Бучу например...
Я не считаю, что это сложно, я считаю - не естественно.
лично я не представляю программирование более 10 тыщ строк без ООП.
Frankie
Конечно, мне придётся смириться. Сейчас я просто пытаюсь понять, почему ООП в прикладном программировании становится стандартом,
почему становится? сипп, давно вышел, и стал стандартом давно, вы просто только что о нем узнали я так понимаю.
Frankie а те, кто его не применяют либо мечтают о нём, либо, по мнению остальных, ладеко не пойдут. Первоисточники сыпят красивыми фразами типа "работа с моделью реального мира", "более высокая абстракция". Я воспринимаю это как уход от реальности. Вместо того, чтобы сосредоточиться на взаимодействии человек<->компьютер и больше ни на чём, пытаются интерпретировать какую-то бизнес логику... UML это вообще чума для меня.
распознование программы, базирующейся на ООП в разы проще, одлеяются объекты при работе с конкретным кусочком кода. вы как бы проводите операцию на человеке на очень маленькой области зная при этом, что остальное не постарадает.
Frankie
И ышо...
Процедурный язык...Или использование си плас плас (подразумевая что это ОО подход) - есть БОЛЕЕ ГРОМОЗДКИЕ конструкции (по коду) и более связанные между собой (!) чем проработка задачи с позиций ОО. Это - факт.
Иероглифы тоже короче букв, но это не значит что они легче и понятнее.
про громозкость: выскажите ваше мнение, как через 20 символов обозначить более 20000 функций, так, чтобы они естесственно не пересекались, и были элементарно понятны программисту??? также оссобенность языка си в его компакности, а дополнение классов гораздо увеличивает восприятие программ и свободу. Frankie
Как один из примеров порой привожу следующие цифры...
Это к чему? Я разве отрицаю, что оптимизация программ приводит к впечатляющим результатам?

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

Frankie Станислав С2. Нет. Зачем резать "по живому" (менять что-то в РАБОТАЮЩЕЙ ПРОГРАММЕ)? Это плохой тон! Должна быть тестовая копия, где программу можно исковеркать по "самое нехочу" и должен быть релиз, с которым уже работают конечные пользователи...
Так и делается. Просто от меня требовалось дописать свойство и метод в калсс и при соответствующих событиях вызвать этот метод. Сделать можно за полчаса, но ведь задача не нарушить концепцию! 2 дня ушло на вникание в логику работы интерфейса (и это только часть!), в итоге сделал, и то не уверен, что это лучшее.

Я к тому, что фанаты ООП говорят, что такие проекты проще сопровождать. Я готов согласиться, но только если к коду прилагается схема классов.

у меня возник вопрос: вы копались во всем коде из, скажем, 20000 функций, или только в его части? если в части, даже меньшей тыщи строк то сразу видна ощутимое упрощение работы с проектом.

а иначе поднимается вопрос о качестве рограммиста, написавшего данную программу.