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

Сабж связан с проектом.
Когда-то мы все писали в процедурах. Но наступило то время, когда я постиг ООП. Как и многие другие программисты, я наотрез отказался от языков типа Паскаль и бейсик -- есть СИ с классами и ест Java.
ООП Рулит - говорят программисты, но так ли это? Очень хочу разобраться.
Как известно, порученный мне проект пишется на Java, а если точнее то Java+CPP+Delphi+Assembler.
Основная часть кода - Ява. И все вроде бы хорошо, но есть разные ИТ специалисты - я - программист а Андрей Семенович - тестер. Вот как раз он то и заставил меня задуматься над тем что лучше: ООП или Процедуры. А выглядело это банально просто - на моем компе стоит 1 гиг оперативы. Все тесты вроде проходят, но тестировщик сказал: "Я сейчас покажу тебе то о чем ты не знал". И показал - просто выдернул из системника один модуль DDR. При запуске на 512 МБ я получил UnknownException по какому-то адресу. Существуют ошибки, которые отловить методом переопределения исключений невозможно. Ты никогда не знаешь как поведет себя объект в том или ином случае. И я подумал: А что если отойти от ООП?
Просто ради интереса.

Код (Text):

1. class OOPFileExample{
2.  
3. public OOPFileExample(){
4.  
5. try{
6.  
7. File f = new File ("TEST");
8.  
9. FileOutputStream fio = new FileOutputStream (f);
10.  
11. byte b = 0x44; // ТОЛЬКО ДЛЯ КОМПИЛЯТОРА ANT!!!! -- ОБЫЧНАЯ ЯВА НЕ ВОЗЬМЕТ!!!
12.  
13. fio.write(b);
14.  
15. }catch (Exception e){
16.  
17. System.err.println("IO Exception");
18.  
19. }
20.  
21. }
22.  
23. }

Вроде здесь все ясно - пишем в тест байт 0x44. Но если этот байт писать например в порт или в сеть -- работает до поры-до времени)) - сам проверял и причины ошибки не известны

А если так, то:

Код (Text):

1. procedure CreateFile  is
2.  
3. fn: File_Type;
4.  
5. begin
6.  
7. Create (fn, Out_File,"d");
8.  
9. end CreateFile;

И коротко и ясно.

Так что ж лучше? ООП или Процедуры?

 

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

 

С другой стороны, если перевести большой проект на процедурный уровень то размер исходников будет ОГРОМНЫМ - запутаешься)

Другой пример - я очень долго разъяснял ООП компилятору что такое USB -- получился длиннючий код в то время как для процедурного языка нужно знать лишь адрес соответствующего девайса и писать туда или читать...

 

opennetworks Да если смотреть со стороны железа то лучше всего процедурный уровень. Мне тоже пришлось перейти со временим на ООП, чтож по делаешь, требует рынок, да и чем раньше начнёшь позновать новые технологии, тем меньше придётья потом наганять. Былабы моя воля, ябы с ДОСного ассемблера не вылезал.

 

ring4
Рынок требует качественных продуктов! И не важно на чем они написаны.
Почему некоторые потребители явно указывают на технологию разработки? "Хочу систему электронной коммерции на JSP!"
Да какая тебе разница на чем она сделана?! Я считаю - главное чтоб ВАЛИДНО работала, а не возбуждала исключения при выдергивании оперативки (кстати как программа с оперативной памятью связана - понять не могу))

 

opennetworks
рынок работадателей

 

Я не знаю как у вас в Москве, но у нас в России - принимают на работу хоть с какой технологией!
Нет ну есть специализированные конторы (линукс-центр) которые говорят что без си мы тя не возьмем или сановские офисы где не берут без явы а по факту им нужен КОНЕЧНЫЙ ПРОДУКТ!

 

ООП, это не способ написания процедур, а прежде всего способ мышления при разработке ПО.
Если ты где то допустил ошибку при общении с аппаратурой в ООП-ориентированной программе, то она также всплывет и программе при процедурном программировании.

Многие думают, что напишут Класс и все, у них супер-пупер ООП-программа! ))
Сила ООП не вклассах, а в мышлении, это четко и ясно поясняет Гради Буч. Даже Страуструп так не поясняет как Буч.

А мысль проста.
Радио-электронщику глубоко фиалетово сейчас как работает диод, его волнует чтобы он обладал соответствующим Вольт-Амперными характеристиками, если обладает то он его впаивает в свою плату!

В программировании также: Большинству глубоко фиолетово как работает CreateFileA, им важно чтобы на переданное имя открылся файл.

Это есть главный плюс, скрытие от программиста лишних деталей - Инкапсуляция.

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

Зы:
Все эти войны ООП или процедуры, имхо, также абсурдны что и среди операционок: "Windows vs UNIX", это абсурд.

зы2:
Если какой нить Дельфиец скажет ООП-отстой, я вообще по полу буду кататься! ))

 

если не ошибаюсь, она (программа) в ней (памяти) находится

 

EvilsInterrupt
Полностью согласен - ООП есть способ мышления, философия. Выходя за рамки программирования могу сказать что это даже способ понимания мира -- есть суперклассы -- классы -- объекты ::: у них - свойства и методы (я уже говорил что на UML можно устройство вселенной описать)
Я даже щас тока подумал -- ООП при желании можно и на асме реализовать
Войны операционок --- какая ось - это от поставленной задачи зависит.. Нам к примеру вообще MarteOs рекомендуют А крики - винда мастдай - это бред сивой кобыллы

Я говорю в этой теме лишь о актуальности принципов разработки!

rmn
Оперативку же не при включенном ПК выдернули!

 

opennetworks Вспомнил я свой случий. Когда писал что-то на С++ с ОПП конечно! так вот у меня на машине в то время стояло 512 оперативки. а вот когда я давал эту программу заказчику, у которого стояло 256, так програма вабе не фурычила ссылаясь на какието непонятные ошибки. А вот когда я откомпилил программу вабще на 128 метров ОЗУ так она стала запускать под любым количеством оперативки. Я сам не понял токда по чему. Тока щас вспомнил о этом случае.

 

У Ершова есть классные вещи по поводу программирования в целом

http://ershov.iis.nsk.su

 

Где купить билет в СССР?))

 

Щас рою инет на тему режима реального времени и параллельного исполнения в win32 и UNIX

У кого есть сцылки по теме?

 

А вот еще на тему неопределяемых ошибок -- на разных машинах разный выход

Код (Text):

1. procedure   Main is
2.  
3.  
4.  
5. procedure   push is
6.  
7. type    stack is array (1..255) of Integer;
8.  
9. a:  stack;
10.  
11. begin
12.  
13. a(25)   :=102;
14.  
15. Put ( a(25)*a(7) );
16.  
17. end push;
18.  
19.  
20.  
21.  
22. begin
23.    
24. Put ( "Выход:" );
25.  
26.  
27.  
28. push;
29.  
30.  
31. end Main;

 

Можно поинтересоваться, что тут

лежит? какими данными инициализируется в конкретном примере этот элемент массива?

 

TOR

Здесь ничего не лежит, то есть мы туда ничего не положили -- массив заполняется ссылаясь на содержимое памяти

Этот код я привел для абстракции --- мы редко в ООП заглядываем в память А это порой приводит к ошибкам

Попробуй у себя откомпилить - увидишь

 

opennetworks
В любом случае, даже если ты такой код используешь в процедурном программировании, то это тоже черевато ошибками. ООП ничем не хуже и не лучше процедурного программирования, это разные вещи.Используется разный подход,различные методики.
ring4

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

 

Тор безусловно прав --- это я скорее ошибся в названии темы

Попробую сказать по-другому

Высокий уровень VS Низкий

 

Ок, тогда сам выбирай:
Стрелять из пушки(ооп) по воробьям (аппаратура)? Или из ружья( процедурное программирование) по слону (бизнес проект)? Неразумно ни то,ни другое,хотя никто не запрещает...