Только не надейтесь, что я буду сравнивать Pascal и C++
Война будет более глобальной

Я предлагаю высказаться тем, кто ЗА объектно-ориентированные языки и кто ПРОТИВ.

Для затравки - я ЗА. И вот почему:

1. Объекты позволяют строить гораздо более мощные системы
2. Повторное использование кода улучшается и возрастает
3. Рапараллеливание процессов гораздо более удобно, что позволяет масштабировать задачи.
4. Объект внутри себя позволяет использовать все что душе угодно - те же процедурные языки или функциональные.

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

И потом - с какими типами языков ты хотел бы сравнивать объектно-ориентированные?

По твоим тезисам есть масса возражений - однако они сформулированы слишком общо, пальцы жалко

Это сообщение отредактировал(а) Akina - 7.10.2004, 11:04

сначала хотел написать

Цитата

а кто за Windows или за Linux , нужно указать область применения

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

резюме: я за то, чтобы использовать ООП (в смысле подход, а не программирование), но и за то, чтобы очень осмотрительно применять ООП-языки при разработке в специфических областях

Соласен с maxim1000 , всё должно быть вмеру.
Вот зачем мне пименять классы в пхп, если я хочу просто обработать форму и напечатать результа на экран?

Цитата(Secandr @ 7.10.2004, 13:02)

Соласен с maxim1000 , всё должно быть вмеру.

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

Так почему же не рассматривать объекты как еще один уровень. Понятно, что управлять портом ввода-вывода на низком уровне через объекты - не получиться. Но если та же операционка на мобильнике будет иметь объект как порт ввода-вывода,то пользоваться им будет удобно.

Мой товарищ работал с Symbian (EPOC) - так там по его словам практически вся ОС построена на объектах. И программы получаются очень компактные и функциональные. Потому как работа внутренних систем инкапсулирована в объекты.

Я несколько переформулирую идею - понятно, что на уровне ассемблера не будет у вас выбора (какое там ООП - влезть бы в пару килобайт). Но если мы говорим о дальнейшем развитии - любая ОС может быть представлена как набор объектов, которые будут уже отвечать за работу с подключенными устройствами. Любое программное обеспечение ВЫГОДНО представлять на таком уровне - не предоставлять голые вызовы функции, а предоставлять набор объектов. Те же драйвера устройств или еще что.

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

Программы величиной больше 500 строк (субьективно) очень ТЯЖЕЛО создавать без ООП.
Пример: в том проекте который я сейчас отлаживаю, около 20 классов, глаза разбегаются..
Если бы это были функции, я с ума сошёл тут же...

Преобретаешь простоту и универсальность, теряешь в производительности.

Цитата

Преобретаешь простоту и универсальность, теряешь в производительности.

Проведем эксперимент?

Асемблер VS делфи. У кого будет меньше программа и быстрее работать?

Secandr
Спроси у Монти ;)
Он как то провёл исследование ASM vs Delphi
Добавлено @ 12:43
Я так понимаю, тут речь идёт о ООП vs процедурщина.
Поэтому и тестить надо на одном языке:
Си vs C++?


Это сообщение отредактировал(а) chipset - 7.10.2004, 12:39

chipset
Я утрирую. о смысл от этого не меняется.

Цитата(chipset @ 7.10.2004, 13:39)

Я так понимаю, тут речь идёт о ООП vs процедурщина.

Не совсем.
Я просто не видел более продвинутой концепции. Если смотреть "с времен очаковских и покоренья Крыма", то сначала были чистые коды, потом ассемблеры, потом языки высокго уровня с процедурами, потом даже несколько файлов и отдельные библиотеки. Теперь настал черед классов и объектов.

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

Моя концепция такова, что как сети и компьютеры создаются "слоями", так и софт может создаваться "слоями". И на сегодня объекты для меня самый высокий "слой". Ниже всего ассемблер, потом процедуры как методы объектов, ну и сами объекты/классы.

Но есть ли у кого-нибудь идея - может есть какой-то другой ?

Цитата

Я несколько переформулирую идею - понятно, что на уровне ассемблера не будет у вас выбора (какое там ООП - влезть бы в пару килобайт). Но если мы говорим о дальнейшем развитии - любая ОС может быть представлена как набор объектов, которые будут уже отвечать за работу с подключенными устройствами. Любое программное обеспечение ВЫГОДНО представлять на таком уровне - не предоставлять голые вызовы функции, а предоставлять набор объектов. Те же драйвера устройств или еще что.

я ни в коем случае не собирался спорить с тем, что слои ПО хорошо представлять в таком виде (я и сам стараюсь так делать)
я говорил о применении ООП при разработке внутри одного конкретного слоя (например, алгоритм сжатия или обработки видео)
и даже не говорил "не надо", а "осмотрительно"
Добавлено @ 13:10

Цитата

Преобретаешь простоту и универсальность, теряешь в производительности.

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

Это сообщение отредактировал(а) maxim1000 - 7.10.2004, 13:05

Цитата

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

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

Цитата

Объект внутри себя позволяет использовать все что душе угодно - те же процедурные языки или функциональные.

Добавлено @ 13:17

Цитата

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

ну, понятия процессов и потоков все-таки не тождественны объектам, так что можно назвать это "еще чем-нибудь"

Цитата

Преобретаешь простоту и универсальность, теряешь в производительности.

Обьясните мне ламеру, почему при ООП теряешь в производительности...