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

Это сообщение отредактировал(а) afiskon - 6.4.2011, 21:35

Если речь идет про видимость атрибутов и методов, то ничего страшного не вижу.

Если же речь идет об отношении обобщения (наследовании), то protected действительно непонятная штука, так как находится между двумя "крайностями": наследованием интерфейса (public наследование) и наследованием реализации (private наследование)

Все молчат, а я таки вброшу.  


ООП оно разное бывает. Но в общем то, да, это лазейка.


protected редко нужен, если проектировать более-менее грамотно. Сейчас вот уже многие пришли к выводу, что потребность в наследовании вообще возникает редко, а если и возникает, то 2-3 уровня в иерархии, и на первом уровне - абстрактный класс/интерфейс. При таком раскладе protected не нужен. Композиция рулит.

Видел у Страуструпа, кстати, в The Design and Evolution of C++ вот такое:

Вообще, Страуструп дельные вещи говорит. На практике как-то не очень выходит.  


  Жесть. Вообще, конечно, их вагон и маленькая тележка. Достаточно упомянуть, что первым труЪ ООП языком был Smalltalk. Там нет никаких аналогов protected.

Думаю, хватит для начала.

Спасибо, это как раз то, что я хотел узнать. Тем не менее, если кому есть что добавить - добавляйте, не стесняйтесь ;)

private и public в контексте _классического_ ООП те же лазейки   

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

вместо шаблонных методов - стратегия?

при чем тут ООП и шаблонные методы ?!
при чем тут шаблонные методы и стратегия ?!
и как все это связано с protected ?!
  

ну, это ж как раз ООПшный шаблон, не?

разве названное - не взаимозаменяемые способы отделить общую абстрактную логику от контекстно-зависимой?

никак. если присмотреться к цитате, к которой я писал свой комментарий, то можно заметить, что там противопоставляется наследование композиции.
и мое сообщение относится именно к этому.
ещё вопросы?

Не нужно путать ООП и возможности языка C++. Шаблоны не имеют НИКАКОГО отношения к ООП. В Ц++ многое относится к функиональному программированию, метапрограммированию и, возможно, еще каким-то парадигмам, про которые я забыл.

99% паттернов Гаммы со товарищи относятся к статически типизированным языкам. В таких языках для обеспечения позднего связывания необходимо использовать наследование (в т.ч. от абстрактных классов), виртуальные методы, ... А в языках с динамической типизацией позднее связывание обычно идёт "искаропки". Послал сообщение объекту, если он его обработал - хорошо, не обработал - побежали дальше по иерархии наследования. При этом, для того, чтобы объект обработал какое-то сообщение ему совершенно необязательно быть экземпляром какого подкласса какого-то абстрактного класса или реализовывать какой-то интерфейс. Если оно крякает, значит оно утка же! Ты же, вроде, ПоХаПешнег?  


Не, см. выше.

afiskon, не, не. Это ты перепутал С++ templates и "OOP" design patterns.   По-русски и то, и другое называют часто шаблонами. Последние также величают паттернами. Тут речь пошла о этих самых паттернах.

Добавлено через 11 минут и 24 секунды
Design Patterns in Python от Alex Martelli. Ссылка прямая! Так, хотя бы посмотреть о чём речь. Smalltalk всё равно круче!  

Ах, эти шаблоны. Я как-то пирвык, что их "паттернами" называют.

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

Добавлено через 15 секунд
сорри за внесенную в обсуждение смуту 

Немного не так. Не делает ненужными, а существенно упрощает реализацию. У Банды Четырёх в самом начале книги читаем (болд мой): 



Тут, скорее, не противопоставление, а обдуманное использование наследования. Причём, речь ведь идёт о наследовании реализации. В чистом виде оно встречается крайне редко, а при использовании где попало чревато.


В "труЪ-ООП", типа, да. Смолтокеры бы такое одобрили.  Ну и где их Смолток?  

Но я бы не сказал, что у Smalltalk есть какая-то монополия на определение ООП. Историческая, разве что. Да и то отчасти. Simula была раньше. И там было ООП со статической типизацией, виртуальными методами и прочим. Но там не было "тотального ООП". Объекты использовались ограниченно, для симуляций. А вот уже "тотальное ООП" ("всё есть объект") появилось в Smalltalk.

Страуструп С++ "рисовал" с Симулы. Я тебя слепели из того, что было.  

Тут уж как вы яхту назовёте...