q_q
Причем здесь повторное использование?
Весь мой предыдущий пост имел одну цель - доказать отсутствие тесной связи между ООП и "перегрузкой". Как верно заметил гн. Meyer, "перегрузку" часто ошибочно ассоциируют с повторным использованием кода и независимостью представления, а эти два понятия действительно являются китами ООП. Короче, IMO, "перегрузка" не имеет практической ценности с точки зрения ООП.

Не смешивай уровень реализации полиморфизма с уровнем абстракции.
Я подозреваю что кроется в этой фразе, но всё-таки попрошу выразиться более развёрнуто (на всякий случай).

Перегрузка - одно из воплощений полиморфизма.
Не согласен.

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

Quantum
"перегрузку" часто ошибочно ассоциируют с повторным использованием
Ни разу не сталкивался с такой ассоциацией.

q_q > Не смешивай уровень реализации полиморфизма с уровнем абстракции.
Quantum > ... попрошу выразиться более развёрнуто
...
q_q > Перегрузка - одно из воплощений полиморфизма.
Quantum > Не согласен.

Хорошо. Давай определимся с понятиями полиморфизм и повторное использование.

Мой вариант:
"Полиморфизм в ООП означает возможность применения одноименных методов с одинаковыми или различными наборами параметров в одном классе или в группе классов, связанных отношением наследования. Понятие полиморфизма, в свою очередь, опирается на два других понятия: совместное использование (overloading) и переопределение (overriding). Термин overloading можно перевести как перегрузку ..."
"Повторное использование - использование (в тривиальном случае методом при помощи copy-paste) написанного ранее кода."
Т.е. абсткакция - это когда на синтаксическом уровне программист обращается к одноименным методам/подпрограммам, а реализация (например на С++) - это когда компилятор генерирует вызов нужной подпрограммы в зависимости от числа и типов параметров.
Я думаю, что Meyer имел ввиду, что перегрузка не слабо, а отрицательно влияет на повторное использование.

2Quantum & q_q: люди, а можно вопрос? Вот смотрите, и абстракцию и полиморфизм и перегрузку - уже придумали, значит они комуто нужны! Вы местами утверждаете что вам они не нужны (может вы просто не умеете их готовить?:), но ведь ктото же ими пользуется, и временами успешно надо заметить! Итак вопрос: "Вы вообще о чем спорите? Чего добиваетесь?"

JaDS
Вы местами утверждаете что вам они не нужны
Неправда. Я утверждал, что всему свое место.

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

2q_q:
Я пытаюсь найти аргументы доказывающие, что воспользовавшись связкой ассемблер+ООП можно получить результаты, которые окупят затраты на создание этой связки, разработку и сопровождение программного обеспечения создаваемого при ее помощи.

Смотри, на текущий момент нет (здесь и далее я буду утверждать только то что знаю, а знаю я мало, так что извиняйте) ни одного крупного комерческого юзер-ориентированного продукта написанного на асме. И этому есть объективные причины, вот эти самые причины и доказывают результативность использования спарки ООП и ассемблера, а именно:

1) Зачастую заказчику нужна скорость разработки, а не быстрота, потребляемые ресурсы и ..., вот тут ООП проявит себя с наилучшей стороны. Само собой что ООП тебе в этом никак не поможет, но он поможет тебе (или комуто другому) написать библиотеку классов, с помощью которой ты сможешь сделать довольно сложный интерфейс практически не утруждаясь (как это сделано в VCL KOL MFC ...), и как следствие тратя на это меньше времени - заказчик будет рад.

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

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

И ещё раз, ВСЁ можно сделать и процедурно, да и без процедур подчас можно обойтись (hello.asm:), ООП - не панацея, это просто, в ОТДЕЛЬНЫХ случаях, очень удобно. Иногда этих отдельных случаев много (например при программировании GUI приложений под винду) иногда мало (написание драйвера под винду).

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

Суммируя всё вышесказанное, я за то чтоб быстро разработать программу (пусть она будет не столь оптимальна), а потом уделить больше времени на разработку/оптимизацию КРИТИЧНЫХ кусков кода. НО если программа критична по своей сути - то никаких (или почти никаких) исходных библиотек, всё ручками, НО опять же не исключенно что в объектах, например я за объектную структуру драйверов (ну или плагинов) - ты скажешь что в фаре она и процедурная работает на ура, а мне кажется что будь она объектной, она бы ещё лучше работала, но заметь никаких исходных кодов, только интерфейс ООП.

JaDS
Зачастую заказчику нужна скорость разработки
Я не знаю ни одного заказчика в здравом уме, который бы заказывал на _ассемблере_ и ему была бы не интересна скорость, я также не знаю ни одного программера, которому заказали бы сложную систему и он бы начал ее на асме писать. Будь реалистом, мы не в perfect world живем.

Продукт написанный на процедурном ассемблере - практически не пригоден для развития
Ты как-то устриц упоминал - намек понятен? У меня есть проекты на процедурном асме объемом >500 кб чистого кода (без макросов, инклудов и пр.) - никаких проблем я не испытываю. Меняю и мелочи, и более глобальные вещи.

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

только возможность писать библиотеки классов
а без этого никак?

НО код их будет (надеюсь) лучше чем код ЯВУ
а ты попробуй написать лучше, чем на, скажем, VC++. И что значит - лучше - меньше и/или быстрее?

Не хочешь взяться и написать что-нибудь? Могу идеи подкинуть - под стать твоей концепции тотального перехода на ассеблер с ООП :) А то тут из 8 страниц толку никакого не видно - одни споры беспочвенные.

masquer
одни споры беспочвенные
согласен, но мыло то никто не отменял;)

Я открыл мыло в "О пользователе...", хотя спорить даже по но безрезультатно не очень хочется :)

q_q
Полиморфизм в ООП означает возможность применения одноименных методов с одинаковыми или различными наборами параметров в одном классе или в группе классов, связанных отношением наследования.
Это определение "перегрузки", а не полиморфизма. Полиморфизм - понятие гораздо более сложное и даже в книге Meyer'а оно не очень чётко выражено.

Повторное использование - использование (в тривиальном случае методом при помощи copy-paste) написанного ранее кода
Если через copy-paste, то это уже не ООП.

Т.е. абсткакция - это когда на синтаксическом уровне программист обращается к одноименным методам/подпрограммам
Это опять "перегрузка", а не абстракция. Абстракция даёт возможность программисту сосредоточиться на вопросе "Что должен делать код?", вместо "Как он это должен делать?".

а реализация (например на С++) - это когда компилятор генерирует вызов нужной подпрограммы в зависимости от числа и типов параметров.
Совершенно верно!

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

JaDS
Вы местами утверждаете что вам они не нужны (может вы просто не умеете их готовить?:), но ведь ктото же ими пользуется, и временами успешно надо заметить!
Да, все мы узали и юзаем STL, но на C++. Совсем другое дело - асм! Не так давно читал статью на сайте Sun, в которой советуют воздержаться от использования перегрузки методов в midlet'ах для платформы J2ME для экономии памяти. А против абстракции, полиморфизма и повтрного использования я ничего не имею, т.к. ООП опирается на эти понятия.

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

Продукт написанный на процедурном ассемблере - практически не пригоден для развития.
Мой самый большой коммерческий проект на асме - около 180Kb (беру в счёт только *.asm файлы). Его сейчас поддерживают другие программеры и не жалуются.

masquer
А то тут из 8 страниц толку никакого не видно - одни споры беспочвенные.
Кому нужно ООП и асм, тот давно их совмещает :-) Спорить тут особого смысла не вижу.

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

Как кто-то давеча сказал: "...побольше IDE - разных размеров и возможностей...".

Quantum
Любой ассемблер уже имеет всё необходимое для создания ООП-приложений

Разумеется. 100%. Иначе как же ассемблеру скомпилировать то, что ему С++ на вход дал? Конечно. На асме ты все можешь делать своими ручками и это его главная прелесть. И ООП можно ручками реализовать. Через макросы вытащить, vtbl самому написать, самому RTTI сделать и прочую херню, хе, и имена самому манглить. Только вот такое ООП мне уже не нада :)
Я не совсем уверен теперь, что хочу нормальное ООП на асме, но ООП, вытащенное через макросы, мне не нужно точно.

Quantum
Полиморфизм - понятие гораздо более сложное
Зачем затеваешь дискусию если у тебя нет определения?

даже в книге Meyer'а оно не очень чётко выражено
Meyer самый авторитетный?

Если через copy-paste, то это уже не ООП.
Я и не утверждал, что повторное использование - это признак ООП, в ООП оно получило дополнительную привлекательность.

JaDS
Твои доводы не перевешивают предполагаемые мною затраты. Как ни пессимистично это звучит, я согласен с masquer Будь реалистом.

q_q
Зачем затеваешь дискусию если у тебя нет определения?
Интересует моё определение полиморфизма? OK, попытаюсь сформулировать:

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

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

Авторитетов называть не буду, ибо моё сугубо личное мнение авторитетным тоже не назовёшь :-)

Я и не утверждал, что повторное использование - это признак ООП
Ну и зря, так как это утверждение совершенно правильное.

Quantum
С полиморфизмом понятно.
Я толкую этот термин как свойство одного объекта прикидываться разными (типа хамелеона, который настраивается на окружающую среду), а ты - как свойство разных объектов прикидываться одним, imho это больше похоже на наследование, откуда иначе появляются общие черты.

Я это не утверждал
Как тогда понять даже в книге Meyer'а?

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

q_q
С полиморфизмом понятно.
Да уж, с полиморфизмом разобрались.

Как тогда понять "даже в книге Meyer'а"?
Как я уже писал в предыдущем посте, Meyer любит теоретизировать. Поэтому за чёткими определениями в терминологии ООП можно смело обращаться к его творению(ям), но тема полиморфизма является одним из немногих исключений. Ещё у меня под рукой лежит книга by H. Shieldt, с более практическим уклоном, и в ней полиморфизм объясняется на примерах :-) На работе лежит толстенный талмуд (автора точно не помню) по объектам и в нём это определение тоже очень расплывчатое. Поэтому я и написал "даже в книге Meyer'а".

Потому что повторное использование возможно без ООП, а ООП без него нет.
Полностью согласен. Но это же не противоречит утверждению "повторное использование - это признак ООП", так?