Совершенно не знаю, где спросить, решил спросить здесь 

Имеют ли право на существование языки программирования без классов(я так понимаю, что то, что с классами, называется ООП) или нет? Потому что вот эта система с классами мне совсем не нравится. Любой язык программирования нравится ровно до того момента, как выясняю, что там есть ЭТА хрень Ну вот такое моё мнение об этом.

Если такие языки программирования есть(кроме Ассемблера), то можно ли рассчитывать получиьт работу с нормальной зарплатой, программируя на них, и если да, то где и как?

Спасибо.

И за что не нравится ООП, раз уж мы в филосфии программирования?

Это сообщение отредактировал(а) Mayk - 18.9.2008, 17:53

есть конечно. например можно программировать на С (простой си) для микроконтроллеров, там хочешь не хочешь а классов нет. так же можно писать например по юникс.. возможностей много 

За бесполезный код.

Class A: ClassB{

public A = new A();

Вот эти две строчки ровным счётом ничего не делают. Не выводят ничего на экран, не выполняют вычислений, не включают даже какую-то там функцию, которая бы не работала без этого, ВООБЩЕ НИЧЕГО НЕ ДЕЛАЮТ. А строчка "public A = new A();" да ещё и после объявления класса А, по моему мнению вообще верх маразма Ну зачем это? Я помнимаю, что это что-то там делает, выполняет какие-то условия в ОО языке программирования, мне это жутко не нравится. Я хочу, чтобы код был максимально простым и значимым.

Я даже переменные стараюсь не использовать, поскольку они тоже являются бесполезным кодом. Использую только тогда, когда без них никак. Функции - признаю их право на существование, возможно иногда используя их, код станет более компактным, но ненавижу оверюз их. А goto люблю гораздо больше функций Классы не перевариваю вообще. Считаю ненужным бредом.

Вот такое моё мнение

Это сообщение отредактировал(а) slavaentp - 18.9.2008, 18:52

А чего: без классов нельзя написать бессмысленный код?



Добавлено через 1 минуту и 45 секунд
классы - такие же инструменты языка, как переменные, функции и тот же goto. не нравится - не используешь. если выходит коряво - мучаешься.
вот только на java писать чисто в процедурном стиле не получится. значит, на работу по java ты в жизни не пройдешь.

Можно конечно


Дело тут вот в чём.

Я - человек, ориентированный на результат. Если программа работает, если цель ДОСТИГНУТА полностью - значит задача выполнена. Меня абсолютно не интересует, "оптимизирована" ли программа. Поставлена задача(в т.ч. и мной самим перед собой) - я написал код, который её решил - значит всё выполнено ИДЕАЛЬНО и ОПТИМАЛЬНО.

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

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

Но это так, отступление. Суть в том, что по-другому я не могу.

А если мою работу будут оценивать по принципу "Да, Ваша программа работает, всё полностью выполнено, но такой код нужно писать через классы, иначе программа через 10 лет будет работать чуточку медленнее" - я так не смогу.

[OFFTOP]
Одно из преимуществ классов: наследование
Понадобилось мне по учебе прогу сваять (преобразования плоского графич. объекта) и решил я ее по быстрому сделать на C#.
А там по заданию надо перемножение матриц. А самому то все писать лень =>


[/OFFTOP]

А насчет языкрв без классов, знаю только C, Pascal (!!! не Object Pascal)
Могу ошибаться, но по моему в Lisp и Prolog их тоже нет.

"Lisp" и "Prolog" - не более, чем общие названия. в одних версиях есть, в других - нет.

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

Добавлено через 33 секунды

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

Может быть если бы где-то расписаны вот такие подобные НАСТОЯЩИЕ преимущества - я бы и поменял отношение к классам или понял их лучше

А так, бред какой-то:

"Пишем программу HelloWorld. Создадим класс для нашей программы, дальше создадим экемпляр этого класса, а теперь поговорим подробно, какие аттрибуты мы можем поставить классу, и имейте в виду, что классы это такие-то такие-то ... <длиннейшее описание сути и философии классов и всех их разновидностей, из которого непонятно, зачем они вообще нужны>. Вот теперь, когда вы поняли всё о том, как создавать классы, экземпляры и конструкторы, правда не поняли, зачем это всё нужно, мы, наконец, напишем - Console.WriteLine("Hello, World!");"

Добавлено через 2 минуты и 39 секунд

Это непонимание, зачем классы нужны Я предположил, что для скорости - а иначе для чего?

Ибо все коды, которые я видел с классами, прекрасно могли быть написаны без них.

ИМХО пока сам не начнешь это все юзать - не поймешь.
Я например вначале тоже думал на# они надо, а щас как то и не знаю даже иногда как без ООП 

Добавлено через 4 минуты и 24 секунды


А как же те несчастные, которые будут потом поддерживать проект, если тебя уже не будет (место работы например сменишь)?
А им например надо будет какую то фичу добавить или баг устранить.
Вот и будут сидеть и проклинать автора, пытаясь разобраться в коде. 

А разве от программиста не готовый продукт требуется? По идее кроме программиста, никто в коде и не должен копаться.

Дело в том, что когда я программирую для себя, я программирую на Ассемблере

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

Другой вопрос, что за программирование на нём не платят, а что такое "прошивка микроконтроллеров", я вообще понятия не имею, как и то, почему это делается на Ассемблере.

Чет отправка глюканула, и не новый пост получился, а старый отредактировался.



Для себя и для кого-то разные вещи.

Это сообщение отредактировал(а) kosmonaFFFt - 18.9.2008, 19:30

Неужто так сложно разобраться в чужом коде, если автор его намеренно что-то там не скрывал?

Добавлено через 3 минуты и 24 секунды

Так чтобы получить "для кого-то", нужно квалификацией обладать.

Вот я и спрашиваю, где силы приложить, и вообще имеет ли мне смысл прилагать силы в программировании

Ибо если "надо сделать программу, чтобы работала" - это я могу сделать

А если нужно думать каждую секунду думать "Ой, как написать? Класс? Функцию? Или просто код?" - то тогда вряд ли, ибо для меня ответ(хотя бы по умолчанию) всегда - "просто код":)

Это сообщение отредактировал(а) slavaentp - 18.9.2008, 19:31

Сам несколько раз пытался разобраться в чужом кривоватом коде
(например все имена переменных в стиле a, aa, ttt, d, v, tt и т. д. и тут даже имеющиеся в обилии коменты не спасали)
, забивал и писал сам. 

Но сделал же в итоге Работодателю по идее должно быть всё равно - при любом варианте он имеет работающую програму.

Я например "просто код" всегда разбиваю на классы+методы/функции ибо мне так например легче.
Разбил задачу на более мелкие - написал и протестировал каждую, потом соединил и все работает. 
А потом, если что-то аналогичное потребуется (да хоть те же матрицы с их умножением,а они у меня в отдельном классе)
взял, скопировал/унаследовал+дописал и можно юзать.

Добавлено через 2 минуты и 54 секунды


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

Не спорю, у разных людей разные предпочтения.

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

ИМХО нет.
Думаю что если бы оплачивался, то ООП не возникло бы 

Абсолютно не верный вывод. После ввода программы в эксплуатацию требуется её активная поддержка для добавления фич и устранения багов. 

соответсвенно это тоже не верно, ну и всё последующее.

Это сообщение отредактировал(а) Mayk - 18.9.2008, 20:34

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


Умоляю тебя! В данный момент я - жертва такого программиста. Не бывает задачи "неоптимизированность кода". Бывает задача "эй вы, парни, нам надо вот такую фишку сделать и тут поменять", и в решении задачи ты сотни, тысячи раз обматеришь предшественника, поменяешь всё до чего дотянешься (или, что случается чаще, примешь как есть. Нет времени всё переписывать). Ура - задача (не скажу какой ценой) решена, можно перестать ругаться на заплатанный код. Думаешь, какая задача встанет следующей? Правильно! "Вот вылез баг, вот здесь плюшечку, и мы тут с бухгалтерией подумали, что надо вот этот момент по-другому вычислять...", но задачи оптимизации тебе в жизни никогда не поставят. И даже если выбьешь с начальника время на таковую, что теперь уже можно поменять? Только переписать всё целиком.

Чем дальше, тем больше заплатанным становится код. Изменение одной его части влечёт совершенно непредсказуемые для всей программы последствия. Автоматизированные тесты навесить на это разваливающееся и подпёртое костылями чудо невозможно, и тестирование превращается в каторгу. Представь теперь, какое количество иголок будет втыкаться в твою восковую фигуру - нужна такая тяжесть на карме?


Эй, на чём-то придётся остановиться! Ни классов, ни функций, ни переменных - так не бывает, хотя бы что-то одно придётся использовать, причём это одно наверняка окажется функциями   

Диагноз - повышенное оптимизаторство, плавали - знаем, сам с ассемблера начинал. Жизнь заставит - всё полюбишь. И функции (за что на них-то взъелся?), и классы (с опытом поймёшь, как их юзать). И даже переменные. Всё хорошо, когда растёт на своём месте.

Зачем:

function superkod($a, $b){

echo $a+$b;

}

superkod(3+1);

если можно:

echo 3+1;

Это сообщение отредактировал(а) slavaentp - 19.9.2008, 15:18

А представь себе, что там не echo $a + $b, а около 40 строк кода, который делает что то с этими самыми переменными
а в программе это делать с ними надо часто. И тут появляется выбор - функция или копирование кода через
Ctrl+C, Ctrl+V (или как там у кого хоткеи настроены) 
Я лично предпочитаю в такой ситуации написать функцию.

Чем "goto" не устраивает?

Действительно отстой. Название superkod не говорит совершенно ни о чём. Функция обладает побочным эффектом, заключающимся в использовании echo. Ну её такую нафиг!

slavaentp, тролль нехороший  Но зато живая беседа.

Начнем, полжалуй, с функций.
Чтобы пример был нагляднее, возмем матрицу.
Нам нужно посчитать детерминант матрицы. Возьми матрицу 5x5 и попробуй написать код для рассчета ее детерминанта без функций. 
А теперь представь что матрица не 5х5, а вообще произвольного размера - как пользователь задаст.
Это тоже можно написать без функций. И даже будет работать, но код будет во много раз длиннее, а читать этот код будет нереально. Следовательно поддержка программы сводится к нулю.
Итого: больше потраченного времени программиста, программа занимает больше места, большее количество кода увеличивает шанс человеческой ошибки (скрытые баги), поддержку программы осуществлять трудно.

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

Это сообщение отредактировал(а) smartov - 19.9.2008, 17:28

Истории много лет, не одна сотня копий разбита в боях. Поисковики в помощь.

Хорошо, а теперь взять те же матрицы и их умножение (недавно сам делал):
как с помощью goto реализовать умножение двух произвольных матриц?
мне это представляется возможным только так:


А теперь с функциями (даже без классов):


И какой же вариант более простой и легчечитаемый? 

Это сообщение отредактировал(а) kosmonaFFFt - 22.9.2008, 18:42

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

 ООП позволяет тебе писать меньше кода на больших проектах. Вопросы есть?

Добавлено через 2 минуты и 51 секунду
Есть такие штуки, как полиморфизм. Они уменьшают количество кода.
Есть такие штуки, как инкапсуляция. Они повышают читабельность кода.
Есть такие штуки, как шаблоны проектирования. Они уменьшают количество головной боли при разработке.
Есть такие штуки, как фреймворки. Они в разы сокращают количество кода по сравнению с C-style библиотеками.

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

korian, надо же. Даже статья на Вики есть. Не знал.

100% тролль ...

именно...

Все верно, как и в предыдущем пояснении, но товариСЧ решил пЕсать для себя... Для себя можно как угодно )))



Ну только вот таких вот обобщений не надо   ... Смотря кто где и над какими задачами работает.


ну Ваши представления об возможностях оператора безусловного перехода несколько искажены. Дейкстра ругал goto за полную дезориентацию синхронизма выполняемых действий - затруднения в очевидности, наглядности работы системы. А совсем, как раз, не за усложнение и утяжеление чтения исходника в пределах одного блока кода - кстати оба Ваших варианта читаются довольно легко. Поколдовав с препроцессором можно добиться ясности и простоты для намного более запутанных случаев... Мало того ПП(или ООП  ) на asm будет тоже тяжелочитаемым. Кстати никто goto собственно и не запрещает, в планировщике задач Linux, что 2.4 что 2.6(более ранних - невидал) он на каждом шагу... И Торвальдс такую работу принимает.
slavaentp
прав в своих кратких тезисах. Все это (+ процедурное программирование) парадигмы - мировоззренческие точки отсчета. Но никто никого не заставляет   ... 


Не совсем верен сам подход... Можно писать ООП на asm. Но это, конечно, экстрим. Но уже для С так очень часто поступают - для тех же микроконтроллеров может не оказаться C++, например, а команда хочет ООП. Кстати, ранние версии GCC преобразовывали C++ в C. И книги встречались на английском как писать на C в стиле C++. Вот неплохой материал по-теме. Ну а все, что можно на C можно и на asm   . 


есть такой язык brainfack... там ничего этого нет. И он работает... Правда именно так как и называется...

Мое скромное имхо по теме...
1) ООП - не панацея от кривого кода. Кто не верит, могу прислать пару модулей, написанных моим коллегой на VB  
2) Модульность и полиморфизм/инкапсуляция/наследование - не одно и тоже. А от переписывания большого количества кода спасать должна правильная структура программы (и модульность - пророк её)...
3) ООП - это все-таки здорово, но только если без фанатизма...

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

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

Хорошо, спрошу так: где граница между теми программами, где не нужно применять ООП, и теми, где ООП лучше применить?

по любому прийдется учить ООП  

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

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

a = GetString();

b = LetUserInput(3);

InitiateConversation();

и т.д.

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

---

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

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

---

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

А вот аргумент сторонника goto убийственный(с форума http://www.sql.ru:

"3) Целевой машинный код в конечном счете будет содержать goto, какие-бы вы не использовали структурно-обьектно-функциональные компилляторы.".

Ещё раз, я не спорю, я хочу для себя понять.

Конечно же можно без классов. Но нельзя без ООП, а классы в этом сильно помогают.

Пример огромной программы без классов: linux. Но ООП там есть.

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

И опять же комментарии при объявлении функций еще не отменял.

Кстати мну тут друг недавно рассказывал - пытался одной знакомой по
программированию помочь, у нее простенькая прога максимум строк на 400 на с++ была написана
сплошным текстом (без функций/классов) и с использованием того же goto, причем было много коментов нормальных, так он часа 3
пытался разобраться в этом всем - не смог, и минут за 30 написал то же самое, но с разбивкой
на функции, и заняло это по объему кода намного меньше.

Точно тролль.

Такое ощущение, что здесь почти все кроме slavaentp - тролли.

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

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

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

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

ksili, при чем тут документация?
Разве не логичней, когда у тебя есть класс "строка", ты создаешь объект этого класса, а затем посылаешь сообщение "ToUpper" этому объекту, по твоему лучше когда вместо класса, объекта и сообщения у нас есть область памяти выделенная под строку, указатель на строку, куча переменных хранящих длину строки, кодировку символов и тд и функция, принимающая в качестве параметра указатель на область в памяти и кодировку символов?
Вообще, ###код можно писать как угодно, но код написанный в ООП стиле, если он написан правильно, намного проще использовать и сопровождать. Например мы пишем программу - редактор текста, и у нас есть класс CDocumentElement, от которого порожден класс CText, и от которого в свою очередь порожден CFormattedText, единственное отличие которого от простого текста - наличие форматирования. Теперь представим что нам потребовался класс CImage(наследник CDocumentElement) - встроенное в документ изображение, затем нам потребуется CAlignedImage итд. Это плохой дизайн, в этом случае получится очень сильно упростить программу, если ввести класс CFormat который был-бы декоратором для CDocumentElement и мог-бы изменять поведение вложенного в него объекта. 
Дело даже не в языке программирования, а в подходе, можно и на асме писать ОПП программы.
зы
кстати, хорошо спроектированная программа или библиотека не нуждается в большом количестве комментариев.

Добавлено через 1 минуту и 4 секунды

Такое ощущение, что здесь почти все кроме slavaentp - занимались сопровождением собственного кода  

Lazin, и как часто мы пишем текстовые редакторы, которые будем сопровождать полжизни? 
Я не говорил, что ООП вообще не нужно. Если проект большой - пожалуйста. Но большая часть программ - не такие крупные проекты как Word. 
И еще. Меня всегда поражал такой фанатизм в дроблении: сделаем Image, из него AlignedImage, из него ещё какой-нибудь имэйдж... Любит человек размножаться ничего не скажешь... Нельзя было сразу сделать объект со всеми нужными свойствами? AlignedImage же тоже можно сделать невыровненным.

Есть базовые классы, они хорошо отработаны. их хватает для большинства часто решаемых задач. Если их не хватает, значит проект наверняка большой  и используй ООП на здоровье. Но все это 

у тебя опять же  будет, только кроме этого ещё куча воды.

Только я ее видеть не буду, это уже кое-что
А насчет больших и маленьких проектов, ты слышал когда-нибудь про принцип DRY, разве ты не захочешь использовать повторно код, который ты писал для маленького проекта? В случае если это ООП код, то это легко сделать, если код, к примеру чтения из реестра размазан по коду программы, то даже в маленьком проекте его будет трудно изменить а использовать в другом проекте, то что ты уже делал крайне затруднительно. Мне однажды пришлось переписать такую "небольшую" программу. Там было всего около 4к строк, но это был абсолютно не сопровождаемый и не читаемый код, все состояло из пары десятков функций и такого-же количества глобальных переменных, все отправилось в унитаз =)

а комментарии там были читаемые? Готов поспорить, что их там не было или почти не было

неа

обычно я для этого использую CTRL-C  CTRL-V, но вообще обычно делать то, что уже делал раньше, не берусь. Как-то так получается

Это сообщение отредактировал(а) ksili - 29.12.2008, 13:35

какая разница были там комментарии или нет, мне что-бы что-то изменить в программе нужно весь код разбирать что-ли?
Don't Repeat Yourself  

вот представь, есть у тебя код для работы с реестром, скажем добавление ключа в реестр, ты его скопипастил в N проектов, потом выходит windows vista, в которой немного изменилась работа с атрибутами безопасности и этот код перестал работать, ты будешь руками править все эти N проектов?

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

функция это уже какая-то абстракция, один шаг до ООП, к примеру функции такие:

это уже ООП, только ты не знаешь об этом  
лично я тут вижу класс registry, и два его метода, то что это его методы нам говорит название ф-й и то, что они принимают в качестве первого аргумента один и тот-же параметр, который определяет экземпляр объекта
Это все эквивалентно такому коду:

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

 О да, void * — офигенческий ООП.
Тогда можно сказать, что асм - самый оопный язык, т.к. там вообще типов нет.

Добавлено через 13 минут и 42 секунды
Lazin, а представь, что ты наследуешь "класс", т.е. дополняешь структуру(на которую тьвой void* смотрит) новыми данными.
Что получишь? Рантайм-ошибку конечно же.

На самом деле тебе придется при наследовании ПЕРЕписывать все ф-ии, т.е. писать над ними обертку для наследника.

+ отсутствует контроль во время компиляции, не говоря уже о подчеркивании красным в IDE.

Это сообщение отредактировал(а) nerezus - 30.12.2008, 10:06

для этого надо будет ещё постараться.


не передергивай. Также можно сказать, что создание своего типа типа - еще один шаг до ООП.


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

Не используя классы, я избавляюсь от 
1) неявных действий в виде конструкторов/деструкторов
2) глупых ограничений, типа "эту функцию над этими данными выполнить нельзя, т.к. они вообще друг друга не знают" (как же они меня бесят)

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

 Это не глупые ограничения, а глупые действия.

Ну я просто не знал, что их можно соблюсти и без классов

Добавлено через 7 минут и 56 секунд
А это реально бывает? или так, существует вероятность...

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

1) используй explicit для конструкторов, что плохого в том что вызывается деструктор я не понял...
2) ради этого все и задумывалось, что-бы обходить ограничения есть шаблоны, например:

это плохо

а это хорошо, так-как будет работать как с std::vector<int>::intertor так и с int*

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

Это сообщение отредактировал(а) Lazin - 30.12.2008, 10:58

У меня в legacy проекте есть комментарии и документация, два пункта из трёх. Но этого, оказывается, маловато. И даже переименовывание переменных не помогает. Чую отчётливый запах серы.


Сложно? Создаётся объект - вызывается конструктор, уничтожается объект - вызывается деструктор. Другое дело, что в них можно любой лишний код засунуть, ну так это не от ООП зависит. Опять же - действия конструкторов/деструкторов разрешено документировать так же свободно, как любой другой код.

Неявный вызов деструкторов? Это не std::auto_ptr ли в коллекциях замешан? Тут несколько другая ситуация, неоднократно упомянутая в различных источниках. Другой случай? Давай разберёмся - я искренне заинтересован.

Чем дальше, тем больше в программировании неявных действий. Ты же не ругаешься, что компилятор без твоего участия сам PE заголовок виндовому экзешнику выстраивает, секции кода/данных/стека размечает. Никогда не было трудностей с пониманием работы коллбеков (мне крышу сорвали в своё время начисто)? Сейчас даже в программировании на ассемблере неявностей выше крыши, и сделано это не ради запутывания несчастных мятущихся программерских душ, но для упрощения процесса программирования. И это ты ещё АОП не видел!

А по факту, современные скриптовые языки (самые известные - перл, пайтон, руби), все как один обладают вагоном неочевидных на первых взгляд тонкостей. Перловые "$<symbols>", пайтоновые "__<functions>__", и так далее. Я лично от таких плюшек в полном восторге.

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

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


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

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

я думаю это заблуждение, программирование развивается в сторону большей абстракции, так-как:

• железо стоит дешево
• программисты стоят дорого

то-есть, нанимая 10 программистов на Си, работодатель получает через какое-то время готовый проект который относительно быстро работает, но он его разработка обошлась дорого и его сложно поддерживать, так-как для этого опять-же нужны программисты на Си. 
В то-же время можно нанять одного ООП-шника программиста на python, java, C# etc (в зависимости от задачи), который сделает то-же самое, но быстро, этот проект сможет поддерживать кто угодно, а разницу в скорости работы программы можно очень недорого компенсировать лучшим железом. В общем это намного дешевле, соответственно конечный продукт при том-же функционале будет стоить намного меньше.
Кстати, контроллеры нынче часто программируют на java, и в этом нет ничего плохого 



Это сообщение отредактировал(а) Lazin - 30.12.2008, 12:54

Можешь привести парочку наименований? Я хоть для общего развития почитаю про них, а то не слышал про такое... Кстати, хорошего на мой взгляд в этом ничего нет, но возможно, у меня взгляд замылен, и технологии уже утопали настолько далеко, что я безнадежно отстал от них. Тогда надо наверстывать 
Я думаю, ksili не зря упомянул про реальный сектор. А там - всякие питоновцы, пхп-вцы, C#-цы и прочие (около)web-кодеры места себе не найдут или найдут, но где-то на очень высоком уровне абстракции от собственно реального уровня промышленного оборудования... 
Для темы общесофтварной разработки - ты, конечно, прав...  
Опять же, сертифицированное железо, применяемое в реальном (т.е. околотехнологическом) производстве, стоит ОЧЕНЬ дорого (по сравнению с себестоимостью, конечно). Несертифицированное - просто мало кто применяет, а кто применяет - на свой страх и риск и как правило на некритичных\вспомогательных участках и\или в условиях недофинансирования...
правильно сказал, я бы даже немного добавил - очень нехватает людей, которые могут с легкостью обучиться чему-то нестандартному и подхватить на лету "идею", и именно люди с незашоренным философией ООП взглядом могут проявить себя в таком качестве максимально эффективно. Собственно, берусь это утверждать именно потому, что за несколько лет работы в этой отрасли из всех студентов, что у меня были - только два смогли реально быстро включиться в работу и оба, как ни странно, очень хорошо знали только ассемблер\базовый С, ну и аппаратно\электронную сторону железа. Всякие ООП им нафиг не сдались на то время...

вот например

Добавлено через 3 минуты и 23 секунды

реальный сектор это не только встраиваемые системы  


так ведь это не проблема ООП подхода а проблема обучения, кто мешает знать и то и другое?

Можно и без классов - напирмер oberon, javascript ... Классы это всего лиш способ реализации ООП в некоторых языках. В oberon (zonnon, blackbox) нету никаких классов, есть расширяемые структуры, есть модули.

+1
На практике комментарии не так уж полезны, как об этом теоретизируют, зачастую даже вредны. Надо чётко осознавать, что хорошие комментарии не дублируют код и не объясняют его, они лишь поясняют его цель, т.е. описывают намерения программиста, а не то, что он написал, т.к. сам язык программирования в этом плане гораздо яснее и лаконичнее. Если же программист не способен написать код, который понятен без комментариев(т.е. комментарии чуть ли не в каждой третьей строке), то с чего вы взяли, что он будет способен написать понятный комментарий    Такие комментарии вредны, и со временем вовсе рассинхронизируются с кодом, что приводит к тому, что неправильными становятся и код, и комментарии к нему.
Хороший код читается как простой текст на английском(пусть и немного корявый со стилистической точки зрения), и классы в данном плане отлично помогают. Но надо понимать, что классы - это синтаксический сахар, как тут уже говорили, т.е. они делают процесс кодирования более приятным, но отнюдь не обеспечивают ООП... 
ООП может быть без классов, а классы могут быть без ООП. Большинство противников ООП просто не осознают сей простой факт.
 

source777, *doc - это тоже комментарии, если что ;)

Поди напиши VCL на одних функциях и goto.

Хороший пример применения ООП это обертка GUI для WinAPI.

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

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

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

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

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

Вот такое вот у меня на сегодняшний день мнение)

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

Добавлено через 3 минуты и 47 секунд

+1, на учебе мне постоянно вдалбилвали - вы должны все комментировать (чуть ли не каждую строку), только потом почитав умных людей и проанализировал я понял что нужно комментировать, а что не нужно. И это очевидно.
Все эти системы наподобие doxygen, вместо того чтобы помочь комментировать код - его портят. Отсюда и появилось выражение, "такой хороший код, комментариями испортили".

Это сообщение отредактировал(а) Torsten - 11.2.2009, 20:12

Очень интересная тема.....

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

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

Архитектор продает продукт, Хакер свою работу.

Как правильно программировать, вопрос не принципа, а психологии.

Холерик и сангвиник - Хакеры.
Флегматик и меланхолик - Архитекторы.

 [offtopic] Я флегматик. => Я архитектор... Верно подмечено, мне ООП нравится гораздо больше процедурного стиля... И когда пришлось работать как-то с чистым WinAPI у меня промелькнула мысль: а почему бы не сделать обертку для всего этого с использованием ООП

Это сообщение отредактировал(а) Krawler - 15.3.2009, 17:34

 Кстати да, я тож например флегматик и ближе к архитектору, чем к хакеру...
Сейчас например LISP осваиваю, так первое за что взялся - объектная система...