Зачем подражать ЯВУ?

Модель ООП не является привелегией ЯВУ (по крайней мере об этом нигде никогда не писалось). Никто не упоминал о том, что ООП является подражание ЯВУ в языке Ассемблер. Более того он может быть внедрен (без последствий, т.е. без замены базового компилятора) в любой язык поддерживающий процедурный стиль программирования и ссылочного типа.

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

Существует множество парадигм программирования один из примеров, а также более подробно можно посмотреть здесь

Fixer
Спасибо за объяснение, но "Object-Oriented Software Construction" by Bertrand Meyer, 2d Ed. лежит у меня на тумбочке (тумбочка прогибается :) Кстати, про китов там тоже написано.

И всё-таки, зачем private и protected на асме? Кому может понадобиться ограничивать доступ к атрибутам и методам своего объекта именно на асме? Логики не вижу... Ведь модификаторы прав доступа не являются неотъемлемой частью OOP.

Quantum
зачем private и protected на асме? Кому может понадобиться ограничивать доступ к атрибутам и методам своего объекта именно на асме?

IMHO, чтоб самому невзначай не использовать какой-нить приватный член-данные. Ведь ООП имеет в качестве одной из целей скрыть от пользователя всю реализацию обработки и данные, предоставив интерфейс для взаимодействия с объектом.

Ведь если ты будешь использовать члены-данные напрямую, ты не сможешь изменить логику обработки данных в классе (в крайнем случае нужно будет найти все обращения к члену и модифицировать все это). А если использовать принципы инкапсуляции и вместо прямого обращения к данным использовать функции, то вместо простого return some_data можно вернуть и log(some_data)/e^3+455 и т.п. без изменений в основном коде пргограммы. (иногда это бывает необходимо)

Хотя для некоторых типов классов это абсолютно несущественно.

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

Не могу согласится!!!!
Но спорить буду только после статьи :)))

Ведь модификаторы прав доступа не являются неотъемлемой частью OOP.

ООО!!!
Ну если у тебя такая книга и там нет 100 раз повторяющегося ООП -- это абстракция.. тогда я молчу :)

Fixer
DaemoniacaL
Edmond

Попытаюсь сформулировать вопрос иначе. Представьте себе следующую ситуацию:

Программер создаёт пакет (библиотеку) полезных
классов на Java (слово "Java" можете заменить на "asm",
если хотите), запускает javadoc (oop2html) и получает
автодокументацию того, что было обозначено как "public".
Всё, что не public, может быть friendly по умолчанию.
Другой программер берёт библиотеку и смотрит
документацию. То, чего нет в документации, он всё равно
не сможет использовать если, конечно, не раскомпилирует
классы. Использование private в данном случае ничего не
изменит.

Ещё пример:

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

Итак, кто-нибудь может привести пример в котором private и/или protected просто необходимы для эффективного проектирования на асме или даже на ЯВУ?

Edmond
ООП -- это абстракция
Да, я знаю, что OOP -- это абстракция. Но при чём здесь вышеописанные модификаторы доступа?

Quantum

На самом деле к модификаторам private и protected надо относиться как к комментариям для вас, для других и для процессора (или ты тоже не пишешь комментариев). Если вы что нибудь сделаете не так то компилятор вам укажет на это.

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

"Object-Oriented Software Construction" by Bertrand Meyer, 2d Ed. лежит у меня на тумбочке (тумбочка прогибается :)

Везет, у меня такой литературой забит весь стеной шкаф (по стене уже идет трещина :)).

Fixer
На самом деле к модификаторам private и protected надо относиться как к комментариям для вас, для других и для процессора
Таа-аак, интересная мысль. Кое-что для меня проясняется. Спасибо. Буду медитировать дальше.

Другое дело полиморфизм который, даже используя стандартные макросы, невозможно реализовать на современных компиляторах языка Ассемблера
Полиморфизм обычно реализуется в рантайме, что сильно усложняет эмуляцию макросами. У NaN есть пример наследования на masm32 (CSmiley или что-то в этом роде). Там реализован полиморфный массив из двух классов.

В принципе можно создавать таблицу виртуальных ссылок на методы класса (как это и делается), а с помощью макросов делать подмену ссылок (подставлять ссылку на таблицу).

P.S. Где-то у меня валялась книжка от Borland'a (очень древняя) по реализации ООП для Ассемлера, если найду выложу.

Quantum
Да, я знаю, что OOP -- это абстракция. Но при чём здесь вышеописанные модификаторы доступа?

А разве они не есть часть абстракции? :)

Edmond
А разве они не есть часть абстракции? :)
Ммдааа... долго чесал я репу над этой фразой... Итак, OOP без абстракции -- не OOP, т.е. если есть OOP, значит есть и абстракция. Но ведь можно реализовать абстракцию без private, так? Другое дело -- модификаторы abstract, virtual и т.д. Буду думать дальше.

Quantum
Мдааа, чем дальше читаю, понимаю насколько нужна тут моя статья.. :)))

Итак, OOP без абстракции -- не OOP, т.е. если есть OOP

И да, и нет.

ООП складывается из (как и любая технология):

1. Идея реализации к коде
2. Абстракция представления
3. Абстракция отображения

private -- это абстракция представления
abstract, virtual - представления/отображения

Идея реализация в коде была доступна ещё в DOS...

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

А вот например на ПХП я недавно получил методику пространственных Объектов.
То есть то же ООП, но связи не по иерархии, а в пространстве.

Так что, в любой технологии есть и Абстракция и Реализация.

Edmond
Потихоньку приближаемся к "философии ООП и её трех китов" :)

Что-то я не пойму - о какой абстракции идёт речь?
кто-нибудь может привести пример абстракции в ООП?

Edmond
Мдааа, чем дальше читаю, понимаю насколько нужна тут моя статья.. :)))
Нужна, нужна...

AsmGuru62
Абстракцию не определить в двух-трёх словах. IMO, абстракция -- это предварительное определение (декларация) функциональности, а имплементация -- дело десятое. Декларация a priori, имплементация a posteriori.

То есть речь идёт о виртуальных функциях, как я понял. Например: у меня есть базовый класс для диалогового окна (назовём его xxiDlg). У него есть виртуальный метод xxiDlg_ProvideCmdMap. Каждый специфический диалог бокс будет иметь собственную имплементацию этого метода. Только причём здесь private, public и protected? Здесь нужен virtual. Задача базового класса xxiDlg: правильно получить параметры WM_COMMAND и вызвать xxiDlg_ProvideCmdMap, который, в свою очередь будет overriden и выполнит нужные действия.