Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Системный анализ, проектирование и UML > Protected методы и члены нарушают инкапсуляцию?

Автор: afiskon 4.4.2011, 14:59

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

Автор: deniva 4.4.2011, 15:25

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

Автор: kemiisto 4.4.2011, 15:26

Все молчат, а я таки вброшу.   Цитата(afiskon @  4.4.2011,  13:59 ) Однако, интересует вопрос - как следует воспринимать protected не в контексте какого-либо языка, а в контексте парадигмы ООП? ООП оно разное бывает. Но в общем то, да, это лазейка. Цитата(afiskon @  4.4.2011,  13:59 ) Встречались ли вам где-нибудь в литературе соображения на этот счет или, возможно, сталкивались с вопросом на практике? protected редко нужен, если проектировать более-менее грамотно. Сейчас вот уже многие пришли к выводу, что потребность в наследовании вообще возникает редко, а если и возникает, то 2-3 уровня в иерархии, и на первом уровне - абстрактный класс/интерфейс. При таком раскладе protected не нужен. Композиция рулит. Видел у Страуструпа, кстати, в The Design and Evolution of C++ вот такое: Цитата One of my concerns about protected is exactly that it makes it too easy to use a common base the way one might sloppily have used global data....In retrospect, I think that protected is a case where "good arguments" and fashion overcame my better judgement and my rules of thumb for accepting new features. Вообще, Страуструп дельные вещи говорит. На практике как-то не очень выходит.   Цитата(afiskon @  4.4.2011,  13:59 ) Может быть, кому-нибудь известны ООП языки, вообще не поддерживающие protected?   Жесть. Вообще, конечно, их вагон и маленькая тележка. Достаточно упомянуть, что первым труЪ ООП языком был Smalltalk. Там нет никаких аналогов protected. Думаю, хватит для начала.

Автор: afiskon 4.4.2011, 15:32

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

Автор: mes 5.4.2011, 16:10

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

Автор: baldina 5.4.2011, 18:03

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

Автор: skyboy 5.4.2011, 21:34

Цитата(kemiisto @  4.4.2011,  14:26 ) При таком раскладе protected не нужен. Композиция рулит. вместо шаблонных методов - стратегия?

Автор: mes 5.4.2011, 21:41

Цитата(skyboy @  5.4.2011,  20:34 ) вместо шаблонных методов - стратегия?  при чем тут ООП и шаблонные методы ?! при чем тут шаблонные методы и стратегия ?! и как все это связано с protected ?!

Автор: skyboy 6.4.2011, 08:28

Цитата(mes @  5.4.2011,  20:41 ) при чем тут ООП и шаблонные методы ?! ну, это ж как раз ООПшный шаблон, не? Цитата(mes @  5.4.2011,  20:41 ) при чем тут шаблонные методы и стратегия ?! разве названное - не взаимозаменяемые способы отделить общую абстрактную логику от контекстно-зависимой? Цитата(mes @  5.4.2011,  20:41 ) и как все это связано с protected ?! никак. если присмотреться к цитате, к которой я писал свой комментарий, то можно заметить, что там противопоставляется наследование композиции. и мое сообщение относится именно к этому. ещё вопросы?

Автор: afiskon 6.4.2011, 10:14

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

Автор: kemiisto 6.4.2011, 13:08

Цитата(skyboy @  5.4.2011,  20:34 ) вместо шаблонных методов - стратегия?  99% паттернов Гаммы со товарищи относятся к статически типизированным языкам. В таких языках для обеспечения позднего связывания необходимо использовать наследование (в т.ч. от абстрактных классов), виртуальные методы, ... А в языках с динамической типизацией позднее связывание обычно идёт "искаропки". Послал сообщение объекту, если он его обработал - хорошо, не обработал - побежали дальше по иерархии наследования. При этом, для того, чтобы объект обработал какое-то сообщение ему совершенно необязательно быть экземпляром какого подкласса какого-то абстрактного класса или реализовывать какой-то интерфейс. Если оно крякает, значит оно утка же! Ты же, вроде, ПоХаПешнег?   Цитата(skyboy @  6.4.2011,  07:28 ) ну, это ж как раз ООПшный шаблон, не? Не, см. выше. afiskon, не, не. Это ты перепутал С++ templates и "OOP" design patterns.   По-русски и то, и другое называют часто шаблонами. Последние также величают паттернами. Тут речь пошла о этих самых паттернах. Добавлено через 11 минут и 24 секунды http://www.aleax.it/gdd_pydp.pdf от Alex Martelli. Ссылка прямая! Так, хотя бы посмотреть о чём речь. Smalltalk всё равно круче!

Автор: afiskon 6.4.2011, 13:28

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

Автор: skyboy 6.4.2011, 14:29

Цитата(kemiisto @  6.4.2011,  12:08 )  Ты же, вроде, ПоХаПешнег? ну, я про статически типизируемые, для которых куча шаблонов писалась и спросил. действительно, возможность создавать экземпляр по имени класса и вызывать метод по имени большую часть шаблонов делает ненужными. я именно про противопоставление "наследование - композиция". впрочем, основную мысль я понял - это к ОО ЯП никакого отношения не имеет. "там" - есть только объекты-модули и сигналы-сообщения. Добавлено через 15 секунд сорри за внесенную в обсуждение смуту

Автор: kemiisto 6.4.2011, 21:26

Цитата(skyboy @  6.4.2011,  13:29 ) ну, я про статически типизируемые, для которых куча шаблонов писалась и спросил. действительно, возможность создавать экземпляр по имени класса и вызывать метод по имени большую часть шаблонов делает ненужными. Немного не так. Не делает ненужными, а существенно упрощает реализацию. У Банды Четырёх в самом начале книги читаем (болд мой):  Цитата The choice of  programming  language  is   important  because  it   influences  one's  point  of  view.  Our  patterns assume Smalltalk/C++-level language features, and that choice determines what can and cannot be implemented easily.   If  we assumed procedural   languages,  we might  have   included design patterns  called  "Inheritance," "Encapsulation,"   and   "Polymorphism."  Similarly,   some   of  our   patterns   are   supported  directly  by  the   less common object-oriented languages. CLOS has multi-methods, for example, which lessen the need for a pattern such as Visitor (page 331). In fact, there are enough differences between Smalltalk and C++ to mean that some patterns can be expressed more easily in one language than the other. (See Iterator (201) for an example.) Цитата(skyboy @  6.4.2011,  13:29 ) я именно про противопоставление "наследование - композиция". Тут, скорее, не противопоставление, а обдуманное использование наследования. Причём, речь ведь идёт о наследовании реализации. В чистом виде оно встречается крайне редко, а при использовании где попало чревато. Цитата(skyboy @  6.4.2011,  13:29 ) "там" - есть только объекты-модули и сигналы-сообщения. В "труЪ-ООП", типа, да. Смолтокеры бы такое одобрили.  Ну и где их Смолток?   Но я бы не сказал, что у Smalltalk есть какая-то монополия на определение ООП. Историческая, разве что. Да и то отчасти. Simula была раньше. И там было ООП со статической типизацией, виртуальными методами и прочим. Но там не было "тотального ООП". Объекты использовались ограниченно, для симуляций. А вот уже "тотальное ООП" ("всё есть объект") появилось в Smalltalk. Страуструп С++ "рисовал" с Симулы. Я тебя слепели из того, что было.   Тут уж как вы яхту назовёте...

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)