ООП против Процедур

Весь топик - жестькаконаесть.

ООП более мощный, но в то же время и чувствительный инструмент, и работать с ним надо уметь. 95% программистов пробуют что-то сделать на ООП и из-за того что у них ничего не получается начинают орать - "ООП ацтой!!", и насвегда возвращаются к лохматому процедурному программированию, так и не поняв сути и мощности ООП. Дайте пещерному человеку компьютер с запущеным на нем фотошопом. Он сможет изобразить рисунок лучше, чем куском камня на скале? Вряд ли. Он даже не поймет как этим компьютером пользоваться. Есть такое слово - "Не дано".
Пока человек задается вопросами по типу сабжа, это означает что его развитие еще находится в состоянии первобытного человека (opennetworks, без обид). Когда придет понимание, а точнее, если придет понимание, то такие вопросы отпадут сами собой, и вы будете просто мило улыбаться, глядя на людей, ведущих такие бессмысленные дискуссии.


ring4

Не надо путать несовершенство с банальным собственным незнанием предметной области.

 

я уже сказал что ошибся именем темы -- ООП знаю

 

TOR
Смотря какое ружье

 

Смотря какой слон...

 

_DEN_
Сказал, как отрезал! Молодца!

opennetworks
Ты не думай че круче, че лучше!
1. А просто возьмись реализовывать проект с 5тью программистами и используй при этом Процедурное программирование(т.е. "Разделяй и властвуй").
2. Потом реализуй этот же проект, но с другими 5тью с ООП-ориентированно мыслящими.

А потом сравни, зачем спрашивать? Сделай и то и то, да сравни!

 

EvilsInterrupt
No such time available

 

Да уж...

Многие конструкции в ООП мы принимаем за должное и пользуемся без оргазма))))
Нужно тебе монитор вырубить - вызвал SC_MONITORPOWER, 0 и все

А в процедурах --- Посмотрел какое у монитора прерыание, адрес; отправил процессору нужные команды - и о чудо! Монитор подчинился твоим кодам и вырубился! Такого наслаждения даже наркоманы не испытывают (я уже говорил что я извращенец)

 

Чтобы отловить все возможные ошибки в программе используйте низкий уровень. Еше Иисус говорил Андрею

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

 

fluderast

Молодец! +5

 

Таких обезъян пол страны

 

Для конкретной платформы - да. Сейчас остро стоит вопрос переносимости -- попробуй угадай какая у клиента платформа!

 

ну ну ну .... код на АСМ и Ада95 неплохо портируется на разные платформа ы вот Ява --- может отказать в любую минуту

 

Я же не сказал что у клиента нужно запускать уже откомпилированный файл --- пусть сам у себя компилирует!

 

Самый лучший выход для независимых прог - поставлять их с загрузчиком (волшебные 512 байт для биоса) на дискете и своей осью на CD.
Отдельной проге - отдельная ось!

 

fluderast

Ничего это не доказывает Основополагающий принцип ООП - "код и данные вместе" и уже к нему цепляются прочие прелести типа наследования, полиморфизма и т.п. Поэтому если мы имеем некий объект типа файл, куча и т.д и т.п., с которым можно производить ряд операций, то "сам бог велел" на уровне реализации приписать эти операции данному объекту, т.е. создать класс. Невиртуальные методы класса отличаются от обычных процедур только тем, что в них автоматически передается скрытый параметр - указатель на соответствующий объект. Теперь посмотрим на АПИ-функции какого-нить объекта, например кучи - во все RtlHeapXXX первым параметром передается hHeap - указатель на объект. Ну и чем это отличается от ООП ? Только тем, что этот параметр прописан в АПИ явным образом и из этого вовсе не следует, что все RtlHeapXXX на уровне исходников реализованы в виде отдельных процедур - это запросто могут быть stdcall-методы класса HHEAP. Вывод - на уровне машинного кода никакой разницы между процедурами и невиртуальными stdcall-методами классов нет, но на уровне исходников классы ес-но удобнее и оспаривать это могут только те, кто "не въехал" в прелести ООП из-за лени или упертости (= "не дано" )

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

А вот это как раз и есть непонимание ООП и сведение его лишь к "бездумногму киданию компонентов". Повторю еще раз, написание собственного класса ничем "плохим" не отличается от процедурного программирования - просто вместо HeapAlloc(hHeap,...) пишем hHeap -> HeapAlloc(...). А вот в "лучшую" сторону оличается, т.к. требует более взвешенного и продуманного подхода при проектировании с прицелом на дальнейшее развитие класса при наследовании. А обезьяны - они и в Африке обезьяны, хоть с ООП, хоть без него ))

opennetworks
Ты похоже решил в лидеры по числу постов на душу населения выйти )))
Может лучше подумать, чем каждую минуту жать жать на кнопку "Отправить". Чем-то мне это "обезьяну за компом" напоминает )))

 

leo
Мы тут говорим о плюсах и минусах ООП и !!! ВЫСОКОУРОВНЕГО ПРОГРАММИРОВАНИЯ в частности|||

Неужели так сложно? Я заметил что многие топики перерастают в критику конкретных людей.
Особенно в HEAP

Я так чувствую через 2-3 поста топик закроется

 

+1

 

fluderast

Вместо того чтобы насиловать свой мозг пихая туда все подряд, лучше бы им подумал. ООП тем и хорошо, что избавляет от необходимости все держать в голове. Это всеравно что подойти на стройке к мужику, который возит кирпичи на тележке и сказать: "Я круче! Я ношу кирпичи в руках!". Может быть тут ты и круче, только толку от тебя мало. Программирование это не конкурс на запоминание. Хочешь похвастаться безразмерностью своего мозга - запоминай число Пи, пока не обгонишь японца, который 40'000 знаков помнит. Только к программированию это никакого отношения иметь не будет.

 

fluderast

Оффтоп)) Ты наверно такой небритый дядя, которому за 30, и который начинал с чего-то типа ZX-Spectrum или первых отечественных IBM-совместимых компов (Практик, Поиск, и т.д.). Без обид))

 

fluderast
+++