Здравствуйте, _vovin, Вы писали: _>Бедный частный случай, а не изоморфизм.
Не понимаю умной мысли. _>Про поведение там просто *ничего не сказано*. Поэтому мимо. Т.е. с _>поведением ты можешь делать все что тебе заблагорассудится, в том числе _>и private/protected. Если очень нужны фиче-грабли. Там — это где? _>О, значит тебе осталася совсем маленький переход для понимания связи _>между слоями и контролем видимости. _>Туда же — layers, views, perspectives, subjects... _>Видимо для мэйнстрима это terra incognita.
Снова не понимаю умной мысли. _>Все мимо, все не в кассу. Производительность достигается не _>ограничениями, а возможностями.
Какая именно производительность? Ок, ни одна из современных платформ не требует пользоваться чем-либо, кроме public. Объясни мне, какая именно производительность подымется, если пользоваться только им? Уж не производительность ли при поддержке написанного софта? _>Не испробовав возможности, превышающие _>твои текущие ограничения (а значит и мышление), не сможешь оценить все _>плюсы и минусы. _>Вот и со слоями — ну не видишь ты их здесь, а они есть...
Где? _>Насчет — ты предлагаешь дать потребителям самим решать, чем им _>пользоваться — абсолютно правильно подмечено. И поверь, на основе такой _>предпосылки строится абсолютно иной более гибкий и продуктивный способ _>мышления и построения программных систем.
Хм. То есть ты считаешь, что авторы С++, Delphi, Java, C# и VB.NET дружно заблуждаются? Можно в студию хоть какие-то аргументы, кроме усмешек и голословных заявлений? >> _>Нижеприведенные примеры ничего не говорят в пользу конкретно >> _>protected/private. >> Это почему еще? Давай-ка прокомментируй.
_>Достаточно в качестве контр-примера привести более гибкую схему, _>например как указано выше.
Ну так приведи. То, что ты указал выше — всего лишь идея. Из нее не видно, как можно решать задачи структурирования решения, в том числе и контролировать зависимости. _>Продуктивность неприемлет параноидальности.
Бла-бла-бла. А давай я напишу "Продуктивность требует параноидальности". И дальше что? Аргументы, дружище, аргументы. _>Бывали случаи, когда _>приходилось копировать целые классы из базового сертифицированного ядра _>для обхождения private. _>Поэтому подход — чтобы вынудить их пользоваться только нашей _>политикой — заведомо ущербен.
Ага. То есть из того, что существуют конкретные библиотеки, которые некорректно используют private, ты делаешь вывод об ущербности private вообще? Т.е. об инкапсуляции в целом, я тебя правильно понял?
З.Ы. А я вот встречал случаи, когда люди занимались обходом private методом Copy/Paste только от того, что не смогли разобраться в штатном способе расширения функциональности. Ну, типа вместо того, чтобы штатно зарегистрировать свою фабрику, копировали класс и публиковали конструктор. Иожет, вместо private стоит запретить Copy/Paste?
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали: VD>Но ты все ремя хочешь доказаь что инкапсулция — это грех. Не по тому ли что любимый язык-игрушка попросту не позволяет ее достичь?
Вроде бы нет. Я таки выбил из него ссылки на то, что он столь высокомерно цитирует. Это не Smalltalk. Это Us — настолько академический проект, что smalltalk на его фоне просто заезженный мейнстрим.
Прикол в том, что тот подход, который проповедует _vovin, преследует ровно те же цели, что и protected/private. В статье приведено отдельное решение, которое эмулирует поведение private — достаточно привязать нужные методы к перспективе, единственная ссылка на которую хранится в неопубликованном статик-поле. Поскольку обращение из-под определенной перспективы (этакая имперсонация) требует наличия ссылки на эту перспективу, постольку внешний код не сможет выполнить эти методы. Т.е. результат будет ровно тем же самым: опять разработчик библиотеки ставит _vovin в нелепую позу. Манипуляции с отладкой и relection для подглядывания внутрь объекта и копирования этой ссылки, имхо, ничуть не лучше, чем hack classes в Delphi и С++ и прочие хаки для обхода private — тот самый "минус к продуктивности".
Резюме: авторы этого послойного подхода решили предоставить весьма неудобный и ненадежный способ добиться функциональности public/private/protected. Для того, чтобы не по годам развитый прикладник мог исправить редкую ошибку разработчика библиотеки, все остальные разработчики библиотек должны тратить свое время на создание своих protected/private, причем для каждого класса в отдельности. Самое приятное, что никаких паттернов раздачи привилегий, не укладывающихся в возможности Java/.Net в той статье не приведено. И вообще непохоже, что авторы ставили перед собой цель переплюнуть С++. Они всего лишь пытались довести любимый Self — язык без инкапсуляции — до нужного уровня. Ясен перец, что простой подход не мог их устроить. Количество граблей, возникающих вследствие layered approach, и описанных в статье, весьма впечатляет. Опять же понятно, что unit testing спасает вообще от всех граблей — граблей языка, библиотек, и разработчиков.
Я понимаю, почему _vovin сам не рискнул объяснять, что такое Layered approach to subjective objects — оказалось бы, что это те же ягодицы, что и в мейнстриме, только вид спереди.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Хм. Тогда перефразирую вопрос. Зачем нужны эти уровни? Польза какая?
Я рекомендую тебе воспользоваться поиском. Вопрос о модификаторах доступа здесь уже досконально обсасывался. Специально для тебя повторю главную тему: инкапсуляция = возможность предоставлять контролируемый контракт потребителям. Для потребителей в различных, скажем так, зонах, можно предоставлять различные контракты.
То, что это необходимо — очевидно. ANS>Что даёт их наличие такого, чего нельзя достич при помощи обычной безуровневой инкапсуляции?
Простейшая штука: мы не хотим предоставлять внешним пользователям объекта возможностей по его конструированию, чтобы вынудить их пользоваться только нашей политикой создания.
Если мы сделаем конструктор приватным, то
а) невозможно будет сделать фабрику отдельным классом. Потому, что ему тоже будет нельзя вызывать конструктор
б) невозможно будет отнаследоваться от такого класса, т.к. потомок не сконструируется.
Если мы сделаем конструктор публичным, то никакого контроля над созданием объекта не получится.
Если мы распространим приватную область видимости на пределы модуля, то в него автоматически приедут все классы, связанные с одним из них.
Простейшая штука номер два: параноидальный подход при конструировании класса требует проверять все приходяшие в методы значения на валидность. И кидать исключение, если что.
При этом каждый вызов получает дополнительные накладные расходы.
Уровень доступа "сборка" позволяет нам предоставить менее безопасный, но более производительный интерфейс ограниченному кругу потребителей. Причем, по удачному совпадению, это ровно тот круг потребителей, которые находятся под нашим контролем. Поэтому мы можем гарантировать валидность передаваемых параметров административными методами и статическим анализом кода.
З.Ы.
Тебя не удивляет, что в жизни все далеко не делится только на личное и общее? Ты даешь свой телефон друзьям, а ключ от квартиры любимой девушке. При этом посторонние не получат ни того, ни другого, хотя могут спокойно спросить у тебя "сколько времени". В программировании — то же самое.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, Losar, Вы писали:
L>>Привет, forum! L>>Я недавно стал изучать язык D и у меня возникло несколько вопросов?
L>>1. Как можно скрыть реализацию класса? Т.е. допустим есть класс, который что то делает. я создаю из него библиотеку (lib), как сделать так что бы я мог отдать эту либ и её можно было юзать но, была скрыта реализация класса? L>>(В си к примеру мы даём заголовки где лежат описание класса и либу, а сами реализация скрыта)
CS>Напиши так:
Здравствуйте, Sinclair, Вы писали:
S> Подсчет количества модификаторов доступа в них оставляю в качестве домашнего задания.
Много.
И напомнило мне это славный анекдот:
Стоият два милиционера в Киеве на Крещатике.
Подходит к ним иностранец и на хорошем
украинском языке спрашивает "Громадянэ, как пройти на Хрещатик?".
Молчат милиционеры. По немецки спросил. По русски. По испански — все равно
тишина.
Пять минут проходит, один служ. пор. говорит другому:
Здравствуйте, Andrei N.Sobchuck, Вы писали: ANS>Разных "зон" это от 3х до 5ти? Такого примитивизма я не принимаю. Если хочется так предоставить контролируемы контракт, то возьми и предоставь его в смысле, объект, который пересылает разрешённые сообщения объекту. Вариантов тут поболее 5ти .
Этого я не понял. Наверное, туплю. Ты имеешь в виду динамическую проверку? Это уже Code Access Security и к областям видимости отношения не имеет. ANS>Очевидность необходимости модификаторов мне не очевидна. Повторю вопрос: что они дают? ANS>Вот есть инкапсуляция. Она, уменьшая связность, даёт гибкость. Есть пространства имён (классов). Они уменьшают количество коллизий этих имён. Вот есть модификаторы. Они дают... ???
Блин, я уже уставать начинаю. Может, будем читать сообщения? Эти модификаторы — и есть инкапсуляция. Они уменьшают связность и дают гибкость. ANS>>>Что даёт их наличие такого, чего нельзя достич при помощи обычной безуровневой инкапсуляции? S>>Простейшая штука: мы не хотим предоставлять внешним пользователям объекта возможностей по его конструированию, чтобы вынудить их пользоваться только нашей политикой создания.
ANS>(в следующем предложении, говоря "ты" я не имею ввиду именно тебя ) ANS>А я, как разработчик-пользователь твоей библиотеки, не хочу, что ты к чему-то меня принуждал, только потому, что ты считаеш себя умнее меня и предусмотрел все мои потребности.
Да нет проблем. Считаешь себя умнее меня — напиши свою библиотеку и объяви все public. Правла, при этом тебе придется контролировать корректность пользовательского кода самостоятельно, потому что гарантий ты предоставить уже не можешь. Ну, вот к примеру, если у нас созданием объектов рулит фабрика, то можно легко ее заменить на другую. А если конструктор объектов при этом публичный, то нет никакой гарантии, что после замены фабрики код будет корректным. В данном случае на большинстве применяемых ОО-языков ты сможешь обойтись банальным контекстным поиском, но в более интересных ситуациях тебе поможет только дорогостоящее тестирование.
ANS>[...]
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, _vovin, Вы писали:
_>Человек говорил про неудачность protected/private, ты начал говорить про _>необходимость ограничений в общем — но второе вовсе не требует первое.
Гм. Я все воспринимаю буквально. Человек (ты, надо полагать, в виду имеешь Andrei N.Sobchuck) ничего про неудачность не говорил. Он спросил "зачем нужны модификаторы". Я ему ответил. >> Там — это где? _>В ООП. В общем случае спрятана только внутренняя структура.
А можно ссылку на это ООП? Меня вообще восхищает такой подход — если "в ООП" не было сказано о protected, значит protected есмь зло. Ага, а если в библии не было сказано про СТО — то Эйнштейн есмь зло. Ну да ладно. >> Какая именно производительность? Ок, ни одна из современных платформ не требует пользоваться чем-либо, кроме public. Объясни мне, какая именно производительность подымется, если пользоваться только им? Уж не производительность ли при поддержке написанного софта? _>Речь о продуктивности разработки. _>В частности private снижает продуктивность. Но отсутствие некоторого _>количества ограничений увеличивает риски, что тоже нехорошо.
Ага. Совершенно верно. И с ростом размера проектов управление рисками выходит на передний плвн. >> Где? _>Указанный подход как раз был сформулирован как layered approach
Не вижу ни формулировки, ни указания. Вижу только туманные общие фразы, объяснения которым я вынужден придумывать самостоятельно. Фи. _>естественным образом получается, что он может осуществлять контроль доступа.
Каким образом? Что мне мешает обратиться из Layer1 прямо в Layer2? _>Т.е. отвечая на твой вопрос "Где?" — по определению.
Определения тоже никакого нет. Есть набор отрывочных фраз. >> Хм. То есть ты считаешь, что авторы С++, Delphi, Java, C# и VB.NET дружно заблуждаются? Можно в студию хоть какие-то аргументы, кроме усмешек и голословных заявлений? _>Причем тут заблуждения? Не все упорядочивается по принципу Заблуждение > Истина. Кое-что _>выстраиваются в цепочки от частного к общему или от менее гибкого к _>более гибкому.
Т.е. аргументов нет? _>Всему свое время.
Ок, я подожду, пока protected вымрет в результате естественного отбора. Ха-ха-ха. >> Ну так приведи. То, что ты указал выше — всего лишь идея. Из нее не видно, как можно решать задачи структурирования решения, в том числе и контролировать зависимости. _>"A Layered Approach to Software Design"
Это что, тест на пользование Google?
Ок. Вот что я нашел: http://www.cse.ucsc.edu/classes/cmps290g/Fall03/summary/pie_summary.pdf.
Читаем:
Goldstein and Bobrow present a layered network approach to represent changes in software
design and development. The fundamental difference to a file based version control system
is that software is represented as network in which the nodes represent software modules (e.g.,
products, components, classes, class methods, etc.) and the edges denote a containment hirarchy.
Changes in this system are represented by layers. A layer is similar to traditional delta files
such that it only contains the changes to the network layer it was derived from. The layered
network approach was implemented in PIE (Personal Information Environment), which can be
viewed as an extension to the standard Smalltalk class browser.
Т.е. никакого отношения к видимости или управлению доступом здесь нет. Это всего лишь change tracking system, замена file-based VCS. Что еще из оффтопа предложишь? _>"A Simple and Unifying Approach to Subjective Objects"
Ок, нашел вот это. Оно?
Честно говоря, я не до конца понял идею. Я понял намеренения авторов — использовать единый подход как для видимости с т.з. объектов, так и с т.з. пользователей. Начинают они, фактически, с того, что декларируют недостаточность инкапсуляции данных, которую ты так защищаешь. Вот только вместо фиксированного набора областей видимости, предоставляемого мейнстримом, они предлагают задавать их вручную. Т.е. они не только не отказываются от protected, они предлагают расширить набор областей до неограниченного!
Маахонькая тонкость: автор сам приписывает к коду обозначение той "области видимости", в которой он находится. Я, правда, так и не увидел в статье того места, где описывается perspective, из которой должен вызываться метод.
При этом одним выстрелом убиваются трое .Net-зайцев:
1. Области видимости
2. Интерфейсы
3. CAS
Таким образом, потребность в областях видимости все же есть. Есть также и подходы различной степени экзотичности к обеспечению этой потребности. Никаких причин к подходу Us рулить супротив Java или Net я пока не вижу. >> Бла-бла-бла. А давай я напишу "Продуктивность требует параноидальности". И дальше что? Аргументы, дружище, аргументы.
Т.е. аргументов опять нет. >> Ага. То есть из того, что существуют конкретные библиотеки, которые некорректно используют private, ты делаешь вывод об ущербности private вообще? Т.е. об инкапсуляции в целом, я тебя правильно понял? _>Неверное обобщение.
Отлично. Вот только не я его сделал. Его делвешь ты. _>Наверняка можно собрать статистику какой процент _>private является неоправданным и приводит к кривым заплаткам.
Ну так собери. Я нигде не говорю, что модификаторы доступа суть единственный способ реализации fine-grained encapsulation. Но твоя критика в их адрес выглядит, мягко говоря, неубедительной. На фоне этого твоя поза великого гуру, обрывки мыслей которого мы должны ловить с открытым ртом, смотрится смешно. _>Не это ли минус к продуктивности?
Лично мне — неизвестно. Минусов к продуктивности может быть столько, что ой-ой-ой. Совершенно не уверен, что именно private виноват. _>А мой случай — является. Там была фабрика, но нужно было сделать _>реализацию на основе класса, в котором куча методов кроме одного _>главного была private.
Твой случай ничуть не лучше. Ну сделали тебе неудачный класс — и что теперь, private виноват? Я тебя уверяю — некорректных применений layer/perspective можно наплодить с той же легкостью. Да, залатать кривой дизайн будет проще. Но маинтайнить систему, состоящую из заплаток, я врагу не пожелаю.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, _vovin, Вы писали:
_>А бороться нужно с такими писаками как ты, которые норовят провести _>анализ собственной проекции других личностей с учетом штампов, _>сложившихся на основе неадекватно восприятой информации. =)
Ура, ура. Я понял что имеется тут ввиду. Несмотря на путанные объяснения господина _vovin и самой статьи. Считай что множественная диспечеризация только с помощью интерфейсов(в терминах мейнстрима). Эта штука мне нравится.
Только одно:
Какого x... э.. с... у......... с я...... назвали это layer approach и взяли эти дурацкие термины.
To Sinclair and VladD2: Вообще у меня создалось впечатление (и не сейчас) что если бы допустим Net 3.0 CAS шифровала private часть класса, то вы бы это называли как раз той самой оптимальной инкапсуляцией которую ждал весь мир. Ничего личного, но впечатление такое есть. По моему нельзя относиться к ней как к ДОГМЕ. Все хорошо в меру.
Хочу заметить также, что статья 96 года, и на него и ориентирована.
С уважением, Gleb.
ЗЫ: Кто безгрешен? Кто не нарушал инкапсуляцию, пусть первым бросит в меня килобайтом.
Привет, forum!
Я недавно стал изучать язык D и у меня возникло несколько вопросов?
1. Как можно скрыть реализацию класса? Т.е. допустим есть класс, который что то делает. я создаю из него библиотеку (lib), как сделать так что бы я мог отдать эту либ и её можно было юзать но, была скрыта реализация класса?
(В си к примеру мы даём заголовки где лежат описание класса и либу, а сами реализация скрыта)
2. Кто может обьяснить (чайнику), что такое mixin и для чего они нужны?
Здравствуйте, Losar, Вы писали:
L>Привет, forum! L>Я недавно стал изучать язык D и у меня возникло несколько вопросов?
L>1. Как можно скрыть реализацию класса? Т.е. допустим есть класс, который что то делает. я создаю из него библиотеку (lib), как сделать так что бы я мог отдать эту либ и её можно было юзать но, была скрыта реализация класса? L>(В си к примеру мы даём заголовки где лежат описание класса и либу, а сами реализация скрыта)
Напиши так:
//myheader.d class A {
void foo();
}
//myimpl.d class A {
void foo() { .... }
}
И отдавай myheader.d
L>2. Кто может обьяснить (чайнику), что такое mixin и для чего они нужны?
Здравствуйте, Losar, Вы писали:
L>И ещё. L>Есть ли у класса права доступа к методам и членом класса???? Если да то как использовать?
Как обычно.
Читай доку (она конечно не супер но все есть — её просто нужно прочитать всю):
Protection Attribute
Protection is an attribute that is one of private, package, protected, public or export.
Private means that only members of the enclosing class can access the member, or members and functions in the same module as the enclosing class. Private members cannot be overridden. Private module members are equivalent to static declarations in C programs.
Package extends private so that package members can be accessed from code in other modules that are in the same package. This applies to the innermost package only, if a module is in nested packages.
Protected means that only members of the enclosing class or any classes derived from that class, or members and functions in the same module as the enclosing class, can access the member. Protected module members are illegal.
Public means that any code within the executable can access the member.
Export means that any code outside the executable can access the member. Export is analogous to exporting definitions from a DLL.
Здравствуйте, c-smile, Вы писали: CS>Как обычно. CS>Читай доку (она конечно не супер но все есть — её просто нужно прочитать всю): CS>
CS>Protection Attribute
CS>Protection is an attribute that is one of private, package, protected, public or export.
CS>Private means that only members of the enclosing class can access the member, or members and functions in the same module as the enclosing class. Private members cannot be overridden. Private module members are equivalent to static declarations in C programs.
CS>Package extends private so that package members can be accessed from code in other modules that are in the same package. This applies to the innermost package only, if a module is in nested packages.
CS>Protected means that only members of the enclosing class or any classes derived from that class, or members and functions in the same module as the enclosing class, can access the member. Protected module members are illegal.
CS>Public means that any code within the executable can access the member.
CS>Export means that any code outside the executable can access the member. Export is analogous to exporting definitions from a DLL.
Здравствуйте, Losar, Вы писали:
L>Здравствуйте, c-smile, Вы писали: CS>>Как обычно. CS>>Читай доку (она конечно не супер но все есть — её просто нужно прочитать всю): L>Хммм, почему не работает? L>Писал код L>class A L>{ L>private int i = 0; L>}
L>int main() L>{ L>A a = new A; L>printf("%d\n", a.i); L>return 0; L>}
L>всё компилится и рабоатет, не ругается на то что i = private. L>почему? что неправильно?
Читайте внимательней:
Private means that only members of the enclosing class can access the member, or members and functions in the same module as the enclosing class.
Вынеси main в другой модуль — и работать перестанет...
Здравствуйте, Dusty, Вы писали:
D>Здравствуйте, Losar, Вы писали:
L>>Здравствуйте, c-smile, Вы писали: CS>>>Как обычно. CS>>>Читай доку (она конечно не супер но все есть — её просто нужно прочитать всю): L>>Хммм, почему не работает? L>>Писал код L>>class A L>>{ L>>private int i = 0; L>>}
L>>int main() L>>{ L>>A a = new A; L>>printf("%d\n", a.i); L>>return 0; L>>}
L>>всё компилится и рабоатет, не ругается на то что i = private. L>>почему? что неправильно? D>Читайте внимательней: D>
Private means that only members of the enclosing class can access the member, or members and functions in the same module as the enclosing class.
D>Вынеси main в другой модуль — и работать перестанет...
Хммм, как то глупо =).
Может кто знает есть ли студия или какой плагин для разработки программ на D?
Здравствуйте, Losar, Вы писали:
L>Здравствуйте, Dusty, Вы писали:
D>>Здравствуйте, Losar, Вы писали:
L>>>Здравствуйте, c-smile, Вы писали: CS>>>>Как обычно. CS>>>>Читай доку (она конечно не супер но все есть — её просто нужно прочитать всю): L>>>Хммм, почему не работает? L>>>Писал код L>>>class A L>>>{ L>>>private int i = 0; L>>>}
L>>>int main() L>>>{ L>>>A a = new A; L>>>printf("%d\n", a.i); L>>>return 0; L>>>}
L>>>всё компилится и рабоатет, не ругается на то что i = private. L>>>почему? что неправильно? D>>Читайте внимательней: D>>
Private means that only members of the enclosing class can access the member, or members and functions in the same module as the enclosing class.
D>>Вынеси main в другой модуль — и работать перестанет...
L>Хммм, как то глупо =).
Почему?
private for module. имхо это удобнее чем
лепить friends в C++ по поводу и без повода.
L>Может кто знает есть ли студия или какой плагин для разработки программ на D?
Здравствуйте, c-smile, Вы писали:
D>>>Вынеси main в другой модуль — и работать перестанет... L>>Хммм, как то глупо =). CS>Почему?
По тому что глупо. private должен быть private. CS>private for module. имхо это удобнее чем лепить friends в C++ по поводу и без повода.
В C# поступили гораздо умнее. Там ввели модификатор internal доткрытый доступ внутри сборки.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, c-smile, Вы писали:
D>>>>Вынеси main в другой модуль — и работать перестанет... L>>>Хммм, как то глупо =). CS>>Почему? WH>По тому что глупо. private должен быть private.
Для кого он должен быть private? Для меня — того человека что
пишет этот модуль? А смысл?
CS>>private for module. имхо это удобнее чем лепить friends в C++ по поводу и без повода. WH>В C# поступили гораздо умнее. Там ввели модификатор internal доткрытый доступ внутри сборки.
Здравствуйте, c-smile, Вы писали:
CS>Для кого он должен быть private?
Для всех кроме того класса в котором он объявлен. На то он и private чтобы никто своими руками в реализацию не лез. CS>Для меня — того человека что пишет этот модуль?
Модуль может быть большим. Напиример в одной из сборок того проекта который я сейчас пишу пол метра исходников в 104х файлах.
И пишут его два человека. CS>А смысл?
Может тогда вобще убрать модификаторы доступа? В чем смысл то?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Andrei N.Sobchuck, Вы писали:
CS>>>А смысл? WH>>Может тогда вобще убрать модификаторы доступа? В чем смысл то? ANS>Присоединяюсь к вопросу: в чем их смысл то?
Смысл чего? Модификаторов доступа?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
CS>>>>А смысл? WH>>>Может тогда вобще убрать модификаторы доступа? В чем смысл то? ANS>>Присоединяюсь к вопросу: в чем их смысл то? WH>Смысл чего? Модификаторов доступа?
Здравствуйте, Dusty, Вы писали:
D>Здравствуйте, c-smile, Вы писали:
CS>>Здравствуйте, Losar, Вы писали:
L>>>Привет, forum! L>>>Я недавно стал изучать язык D и у меня возникло несколько вопросов?
L>>>1. Как можно скрыть реализацию класса? Т.е. допустим есть класс, который что то делает. я создаю из него библиотеку (lib), как сделать так что бы я мог отдать эту либ и её можно было юзать но, была скрыта реализация класса? L>>>(В си к примеру мы даём заголовки где лежат описание класса и либу, а сами реализация скрыта)
CS>>Напиши так:
далее есть main.d
/*********************************** main.d **************************************/
import std.stdio;
import lib;
int main()
{
A a = new A();
return 0;
}
/********************************************************************************/
собираю
dmd -O -release -L mylib.lib main.d
он начинает ругатся что типа незнает A;
но если я заменю import lib на import lib_r
все собирается и работает?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
WH>>В контроле инкапсуляции компилятором. ANS>Так инкапсуляция либо есть либо нет. А атрибутов много. ANS>Значит в чем то другом дело.
Дело в уровнях инкапсуляции.
public — Публичный интерфейс класса.
protected — Интерфейс класса доступный потомкам.
internal — Интерфейс класса доступный внутри сборки.
private — Детали реализации класса.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Так инкапсуляция либо есть либо нет. А атрибутов много. ANS>Значит в чем то другом дело.
Наива. Инкапсуляция — это возможность публиковать различные контракты для различных потребителей. Количество модификаторов доступа напрямую определяется количеством типов отношений кода с потребителями. Для процедурных языков такой классификации не существует. Для модульных языков процедура-потребитель может находиться либо в том же модуле, либо в другом. Для объектно-ориентированных языков объект-потребитель принадлежит либо тому же классу, либо его потомку, либо любому другому. И т.д. Наиболее развитые сейчас (афаик) в плане структурирования кода платформы — .Net и Java. Подсчет количества модификаторов доступа в них оставляю в качестве домашнего задания.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Будем дольше развивать темы про D.
Теперь у меня такой вопрос?
Кто ни будь, тестировал D на производительность??
Что можете сказать?
Как он себя показывает на фоне компиляторов от Microsoft и от g++?
Если быстрее то в чем?? Если медленнее, то тоже, в каких ситуациях??
Как можно оптимизировать?
Здравствуйте, Cyberax, Вы писали: C>Немного. А если точнее, то в Java их всего 4: public, default, protected C>и private.
Верно. На 1 больше, чем в с++. И ровно потому, что появилась новая единица структурирования — пакет. C>Если считать static модификатором доступа, то будет 8.
Ну, статик на visiblity не влияет. Так что вместе с final выкидываем его из рассмотрения.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
L>Кто ни будь, тестировал D на производительность?? L>Что можете сказать? L>Как он себя показывает на фоне компиляторов от Microsoft и от g++? L>Если быстрее то в чем?? Если медленнее, то тоже, в каких ситуациях?? L>Как можно оптимизировать?
Далеко ходить не надо: http://www.rsdn.ru/article/devtools/devtools.xml
Здравствуйте, Dusty, Вы писали:
L>>Кто ни будь, тестировал D на производительность?? L>>Что можете сказать? L>>Как он себя показывает на фоне компиляторов от Microsoft и от g++? L>>Если быстрее то в чем?? Если медленнее, то тоже, в каких ситуациях?? L>>Как можно оптимизировать? D>Далеко ходить не надо: http://www.rsdn.ru/article/devtools/devtools.xml
Здравствуйте, Losar, Вы писали:
L>Здравствуйте, Dusty, Вы писали:
L>>>Кто ни будь, тестировал D на производительность?? L>>>Что можете сказать? L>>>Как он себя показывает на фоне компиляторов от Microsoft и от g++? L>>>Если быстрее то в чем?? Если медленнее, то тоже, в каких ситуациях?? L>>>Как можно оптимизировать? D>>Далеко ходить не надо: http://www.rsdn.ru/article/devtools/devtools.xml
Здравствуйте, Losar, Вы писали:
L>Здравствуйте, Dusty, Вы писали:
L>>>Кто ни будь, тестировал D на производительность?? L>>>Что можете сказать? L>>>Как он себя показывает на фоне компиляторов от Microsoft и от g++? L>>>Если быстрее то в чем?? Если медленнее, то тоже, в каких ситуациях?? L>>>Как можно оптимизировать? D>>Далеко ходить не надо: http://www.rsdn.ru/article/devtools/devtools.xml
L>В этой статье только слова, а мне бы цифры? И сравнения!
"...и опыт сын ошибок..."
Самое надежное: написать для себя пример
имплементирующий простую mission critical функцию
на двух трех языках. По результатам — осознанно выбрать.
Рекламным материалам верить можно до определенного
предела. Если вообще можно.
WH>Здравствуйте, Andrei N.Sobchuck, Вы писали:
WH>>>В контроле инкапсуляции компилятором. ANS>>Так инкапсуляция либо есть либо нет. А атрибутов много. ANS>>Значит в чем то другом дело. WH>Дело в уровнях инкапсуляции.
Хм. Тогда перефразирую вопрос. Зачем нужны эти уровни? Польза какая? Что даёт их наличие такого, чего нельзя достич при помощи обычной безуровневой инкапсуляции?
Как по мне, то если в классе куча кода который кажется приватным, то есть, не относится к интерфейсу класса, то это явный повод вырефакторить этот код в отдельный класс. А если есть желания использовать не ОО подход, а используя модуляризацию, то и берите тот же Оберон
Желания запретить пользоваться своим кодом кому бы то ни было я решительно не понимаю. Вопросов бы не было, если бы эти модификаторы помогали поддерживать стабильными публичные интерфейсы. Так глядя на кучу "depreciated" в Java и .Net видно, что к этой задаче модификаторы не пригодны.
WH>public — Публичный интерфейс класса. WH>protected — Интерфейс класса доступный потомкам. WH>internal — Интерфейс класса доступный внутри сборки. WH>private — Детали реализации класса.
Кстати, хорошим аргументом "против" является экстенсивное наращивание модификаторов. От С++ через Java к .Net. А завтра кому-то захочется "защитится" от классов в одном пространстве имён. Бац, новый модификатор. А потом для разных комбинаций пространств имён и пакетов... (А в каждой шутке, как известно, только доля шутки.)
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Хм. Тогда перефразирую вопрос. Зачем нужны эти уровни? Польза какая? Что даёт их наличие такого, чего нельзя достич при помощи обычной безуровневой инкапсуляции?
Например есть класс дерево и класс ветка дерева. Для взаимодействия между ними нужен болие широкай интерфейс чем для взаимодействия с внешним миром.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
ANS>>Хм. Тогда перефразирую вопрос. Зачем нужны эти уровни? Польза какая? Что даёт их наличие такого, чего нельзя достич при помощи обычной безуровневой инкапсуляции? WH>Например есть класс дерево и класс ветка дерева. Для взаимодействия между ними нужен болие широкай интерфейс чем для взаимодействия с внешним миром.
И что? Ты же не утверждаеш, что не используя модификаторов доступа не возможно создать классы дерева и ветки?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>И что? Ты же не утверждаеш, что не используя модификаторов доступа не возможно создать классы дерева и ветки?
А то что иначе эти классы будут иметь слишком большой интерфейс который не нужен их пользователям.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
ANS>>И что? Ты же не утверждаеш, что не используя модификаторов доступа не возможно создать классы дерева и ветки? WH>А то что иначе эти классы будут иметь слишком большой интерфейс который не нужен их пользователям.
Ты уверен на все 100, что этот интерфейс мне не нужен?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
WH>>А то что иначе эти классы будут иметь слишком большой интерфейс который не нужен их пользователям. ANS>Ты уверен на все 100, что этот интерфейс мне не нужен?
Ну может тогда вобще отменим модификаторы доступа и пусть все будет публичным?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Ну может тогда вобще отменим модификаторы доступа и пусть все будет публичным?
Автор, не богохульствуй!
Пишу на досуге на PHP довольно тяжёлую программу. Очень интересный язык оказался. Но вот отсутствие явной спецификации типов и отсутствие приватных элементов (они появились в пятой версии) задалбывает.
Здравствуйте, tarkil, Вы писали:
WH>>Ну может тогда вобще отменим модификаторы доступа и пусть все будет публичным? T>Автор, не богохульствуй!
А я то тут причем? Этот ты Andrei N.Sobchuck скажи. Я прекрасно понимаю зачем нужны модификаторы доступа.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
T>>Автор, не богохульствуй! WH>А я то тут причем? Этот ты Andrei N.Sobchuck скажи. Я прекрасно понимаю зачем нужны модификаторы доступа.
Нет, ну как тебе даже мысль могла придти в голову, сделать всё публичным?! Я в шоке... надо выпить чаю.
Sinclair wrote:
> Здравствуйте, Andrei N.Sobchuck, Вы писали: > > ANS>Хм. Тогда перефразирую вопрос. Зачем нужны эти уровни? Польза какая? > Я рекомендую тебе воспользоваться поиском. Вопрос о модификаторах доступа здесь уже досконально обсасывался. Специально для тебя повторю главную тему: инкапсуляция = возможность предоставлять контролируемый контракт потребителям. Для потребителей в различных, скажем так, зонах, можно предоставлять различные контракты. > То, что это необходимо — очевидно.
Обрати внимание — эти правильные слегка общие фразы не кореллируют
непосредственно с указанным способом котроля — public/protected/private.
Более того, такой подход достаточно ущербен.
Если обратиться к азам ООП, то видно, что про контроль поведения ничего
не говорится, а говорится только про инкапсуляцию данных. Поэтому все
данные должны быть приватными, а методы как хочется — это уже будет
высокоуровневой надстройкой конкретной реализации ООП.
В плане развития надстроек можно условно выделить две тенденции —
ограничивающую и непринуждающую.
Первый случай, это наличие ограничений, которые не могут быть
проигнорированы — final, throws, private, жестко прописанные типы и т.д.
Второй случай, это наличие нежестких или более свободных ограничений.
Например, шаблоны C++ vs generics C#, латентная типизация, отсутствие
final, throws, private.
Теперь рассмотрим какие непреодолимые ограничения возникают при
необходимости доступа к поведению с различными модификаторами:
1) private — совсем ничего не сделаешь
2) protected — нужно наследоваться
3) package local — нужно быть объявленным в том же пакете
Первый случай является абсолютно параноидальным, ни разу не возникло
желания им воспользоваться, а когда натыкался, были одни проблемы.
Второй и третий задают ограничение по структуре. Нужно либо быть
потомком данного класса, т.е. выступать в той же роли и поддерживать все
его интерфейсы (что может быть очень даже лишним). Либо находиться в том
же пакете, а значит являться частью некоторой подсистемы и иметь
назначение, заданное данным пакетом (что так же может быть камнем на шее
хорошего дизайна).
Так вот намного более перспективным, общим, полным и неограничивающим
подходом в контроле доступа является так называемый layered approach или
по-другому — субъекты, или еще по-другому — method/selector namespaces.
Идея простая — потребитель *сам* включает видимость/доступность тех или
иных частей системы. Получаются явно прописанные зависимости, которые
определяются исходя из роли каждого конкретного класса. Класс,
наделенный ролью УправлениеРюшками, будет явно включать namespace
СозданиеРюшек, получая доступ к якобы приватным методам других классов,
отвечающим за управление временем жизни Рюшек.
> ANS>Что даёт их наличие такого, чего нельзя достич при помощи обычной безуровневой инкапсуляции?
Нижеприведенные примеры ничего не говорят в пользу конкретно
protected/private.
> Простейшая штука: мы не хотим предоставлять внешним пользователям объекта возможностей по его конструированию, чтобы вынудить их пользоваться только нашей политикой создания. > > Если мы сделаем конструктор приватным, то > а) невозможно будет сделать фабрику отдельным классом. Потому, что ему тоже будет нельзя вызывать конструктор > б) невозможно будет отнаследоваться от такого класса, т.к. потомок не сконструируется. > Если мы сделаем конструктор публичным, то никакого контроля над созданием объекта не получится. > Если мы распространим приватную область видимости на пределы модуля, то в него автоматически приедут все классы, связанные с одним из них. > > Простейшая штука номер два: параноидальный подход при конструировании класса требует проверять все приходяшие в методы значения на валидность. И кидать исключение, если что. > При этом каждый вызов получает дополнительные накладные расходы. > Уровень доступа "сборка" позволяет нам предоставить менее безопасный, но более производительный интерфейс ограниченному кругу потребителей. Причем, по удачному совпадению, это ровно тот круг потребителей, которые находятся под нашим контролем. Поэтому мы можем гарантировать валидность передаваемых параметров административными методами и статическим анализом кода. > > З.Ы. > Тебя не удивляет, что в жизни все далеко не делится только на личное и общее? Ты даешь свой телефон друзьям, а ключ от квартиры любимой девушке. При этом посторонние не получат ни того, ни другого, хотя могут спокойно спросить у тебя "сколько времени". В программировании — то же самое.
Меня удивляет, когда программирование один-в-один сравнивают например с
гражданским строительством. Поэтому лучше не удивлять других и не
приводить прямых "жизненных" аналогий.
T>Здравствуйте, WolfHound, Вы писали:
WH>>Ну может тогда вобще отменим модификаторы доступа и пусть все будет публичным?
T>Автор, не богохульствуй!
А, религия. Тогда без вариантов, конечно.
T>Пишу на досуге на PHP довольно тяжёлую программу. Очень интересный язык оказался. Но вот отсутствие явной спецификации типов и отсутствие приватных элементов (они появились в пятой версии) задалбывает.
Так не нужно путать не-ОО язык, с языком в котором таки есть инкапсуляция (заметь нет ни слова о модификаторах доступа).
Здравствуйте, Sinclair, Вы писали:
ANS>>Хм. Тогда перефразирую вопрос. Зачем нужны эти уровни? Польза какая? S>Я рекомендую тебе воспользоваться поиском. Вопрос о модификаторах доступа здесь уже досконально обсасывался. Специально для тебя повторю главную тему: инкапсуляция = возможность предоставлять контролируемый контракт потребителям. Для потребителей в различных, скажем так, зонах, можно предоставлять различные контракты.
Разных "зон" это от 3х до 5ти? Такого примитивизма я не принимаю. Если хочется так предоставить контролируемы контракт, то возьми и предоставь его в смысле, объект, который пересылает разрешённые сообщения объекту. Вариантов тут поболее 5ти .
S>То, что это необходимо — очевидно.
Очевидность необходимости модификаторов мне не очевидна. Повторю вопрос: что они дают?
Вот есть инкапсуляция. Она, уменьшая связность, даёт гибкость. Есть пространства имён (классов). Они уменьшают количество коллизий этих имён. Вот есть модификаторы. Они дают... ???
ANS>>Что даёт их наличие такого, чего нельзя достич при помощи обычной безуровневой инкапсуляции? S>Простейшая штука: мы не хотим предоставлять внешним пользователям объекта возможностей по его конструированию, чтобы вынудить их пользоваться только нашей политикой создания.
(в следующем предложении, говоря "ты" я не имею ввиду именно тебя )
А я, как разработчик-пользователь твоей библиотеки, не хочу, что ты к чему-то меня принуждал, только потому, что ты считаеш себя умнее меня и предусмотрел все мои потребности.
Здравствуйте, _vovin, Вы писали:
_>Обрати внимание — эти правильные слегка общие фразы не кореллируют _>непосредственно с указанным способом котроля — public/protected/private.
Да ну? Я, наверное, как-то сильно умно выражаюсь. Ок, разжуем помельче:
public: контракт, предоставляемый всем объектам
protected: контракт, предоставляемый объектам классов, унаследованных от данного
private: контракт, предоставляемый объектам данного класса.
Что, не прослеживается корреляции? _>Более того, такой подход достаточно ущербен.
Очень интересно. _>Если обратиться к азам ООП, то видно, что про контроль поведения ничего _>не говорится, а говорится только про инкапсуляцию данных.
А можно мне эти азы точно указать? И где там сказано "ни в коем случае не скрывайте при помощи инкапсуляции поведение. Она только для состояния!" _> Поэтому все данные должны быть приватными, а методы как хочется — это уже будет _>высокоуровневой надстройкой конкретной реализации ООП.
_>В плане развития надстроек можно условно выделить две тенденции — _>ограничивающую и непринуждающую. _>Первый случай, это наличие ограничений, которые не могут быть _>проигнорированы — final, throws, private, жестко прописанные типы и т.д. _>Второй случай, это наличие нежестких или более свободных ограничений. _>Например, шаблоны C++ vs generics C#, латентная типизация, отсутствие _>final, throws, private.
_>Теперь рассмотрим какие непреодолимые ограничения возникают при _>необходимости доступа к поведению с различными модификаторами: _>1) private — совсем ничего не сделаешь _>2) protected — нужно наследоваться _>3) package local — нужно быть объявленным в том же пакете _>Первый случай является абсолютно параноидальным, ни разу не возникло _>желания им воспользоваться, а когда натыкался, были одни проблемы. _>Второй и третий задают ограничение по структуре. Нужно либо быть _>потомком данного класса, т.е. выступать в той же роли и поддерживать все _>его интерфейсы (что может быть очень даже лишним). Либо находиться в том _>же пакете, а значит являться частью некоторой подсистемы и иметь _>назначение, заданное данным пакетом (что так же может быть камнем на шее _>хорошего дизайна).
_>Так вот намного более перспективным, общим, полным и неограничивающим _>подходом в контроле доступа является так называемый layered approach или
Никогда не встречал подобного применения термина layered approach. Обычно под ним понимают общее структурирование системы на слои, каждый из которых зависит только от нижележащего. Это позволяет минимизировать затраты на замену самого нижнего слоя, т.к. изменения гарантированно затронут только непосредственно зависящий от него слой. _>по-другому — субъекты, или еще по-другому — method/selector namespaces. _>Идея простая — потребитель *сам* включает видимость/доступность тех или _>иных частей системы. Получаются явно прописанные зависимости, которые _>определяются исходя из роли каждого конкретного класса. _>Класс, _>наделенный ролью УправлениеРюшками, будет явно включать namespace _>СозданиеРюшек, получая доступ к якобы приватным методам других классов, _>отвечающим за управление временем жизни Рюшек.
Отлично. Слоев тут нет ( (с) Шрек), зато есть ориентированность на потребителя. Как quickfix это должно действительно спасать. Но пока что я не вижу никакой причины для руления этого подхода в долгосрочной перспективе. Подход, где ограничения на потребителей задает производитель (назовем его классическим. Потому как в четырех из четырех мне известных ООП-платформ применяется именно он), выглядит менее демократичным. Но он, имхо, больше похож на реальность, где плодами трудов одного производителя пользуется множество потребителей. Поэтому производитель может себе позволить более высокую квалификацию, при которой принимаются правильные архитектурные решения. И требования к потребителям выдвигаются так, что они вынуждены следовать правильным решениям. От них заботливо убирают грабли, на которые можно наступить. Ты предлагаешь дать потребителям самим решать, чем им пользоваться, и пусть они отвечают за избыточные зависимости (которые не дадут им потом сделать upgrade на новую версию библиотеки), и за поддержание инвариантов. _>Нижеприведенные примеры ничего не говорят в пользу конкретно _>protected/private.
Это почему еще? Давай-ка прокомментируй. >> Простейшая штука: мы не хотим предоставлять внешним пользователям объекта возможностей по его конструированию, чтобы вынудить их пользоваться только нашей политикой создания. >> >> Если мы сделаем конструктор приватным, то >> а) невозможно будет сделать фабрику отдельным классом. Потому, что ему тоже будет нельзя вызывать конструктор >> б) невозможно будет отнаследоваться от такого класса, т.к. потомок не сконструируется. >> Если мы сделаем конструктор публичным, то никакого контроля над созданием объекта не получится. >> Если мы распространим приватную область видимости на пределы модуля, то в него автоматически приедут все классы, связанные с одним из них. >> >> Простейшая штука номер два: параноидальный подход при конструировании класса требует проверять все приходяшие в методы значения на валидность. И кидать исключение, если что. >> При этом каждый вызов получает дополнительные накладные расходы. >> Уровень доступа "сборка" позволяет нам предоставить менее безопасный, но более производительный интерфейс ограниченному кругу потребителей. Причем, по удачному совпадению, это ровно тот круг потребителей, которые находятся под нашим контролем. Поэтому мы можем гарантировать валидность передаваемых параметров административными методами и статическим анализом кода.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Так не нужно путать не-ОО язык, с языком в котором таки есть инкапсуляция (заметь нет ни слова о модификаторах доступа).
Если в PHP отсутствует инкапсуляция, то я не имею права сожалеть об этом, ссылаясь на некий из воздуха вытянутый постулат, дескать, "PHP не ООП-язык"? Это что ли подразумевалось?
Sinclair wrote: > Здравствуйте, _vovin, Вы писали: > > _>Обрати внимание — эти правильные слегка общие фразы не кореллируют > _>непосредственно с указанным способом котроля — public/protected/private. > Да ну? Я, наверное, как-то сильно умно выражаюсь. Ок, разжуем помельче: > public: контракт, предоставляемый всем объектам > protected: контракт, предоставляемый объектам классов, унаследованных от данного > private: контракт, предоставляемый объектам данного класса. > Что, не прослеживается корреляции?
Бедный частный случай, а не изоморфизм.
> _>Более того, такой подход достаточно ущербен. > Очень интересно. > _>Если обратиться к азам ООП, то видно, что про контроль поведения ничего > _>не говорится, а говорится только про инкапсуляцию данных. > А можно мне эти азы точно указать? И где там сказано "ни в коем случае не скрывайте при помощи инкапсуляции поведение. Она только для состояния!"
Про поведение там просто *ничего не сказано*. Поэтому мимо. Т.е. с
поведением ты можешь делать все что тебе заблагорассудится, в том числе
и private/protected. Если очень нужны фиче-грабли.
> _>Так вот намного более перспективным, общим, полным и неограничивающим > _>подходом в контроле доступа является так называемый layered approach или > Никогда не встречал подобного применения термина layered approach. Обычно под ним понимают общее структурирование системы на слои, каждый из которых зависит только от нижележащего. Это позволяет минимизировать затраты на замену самого нижнего слоя, т.к. изменения гарантированно затронут только непосредственно зависящий от него слой.
О, значит тебе осталася совсем маленький переход для понимания связи
между слоями и контролем видимости.
Туда же — layers, views, perspectives, subjects...
Видимо для мэйнстрима это terra incognita.
> _>по-другому — субъекты, или еще по-другому — method/selector namespaces. > _>Идея простая — потребитель *сам* включает видимость/доступность тех или > _>иных частей системы. Получаются явно прописанные зависимости, которые > _>определяются исходя из роли каждого конкретного класса. > _>Класс, > _>наделенный ролью УправлениеРюшками, будет явно включать namespace > _>СозданиеРюшек, получая доступ к якобы приватным методам других классов, > _>отвечающим за управление временем жизни Рюшек. > Отлично. Слоев тут нет ( (с) Шрек), зато есть ориентированность на потребителя. Как quickfix это должно действительно спасать. Но пока что я не вижу никакой причины для руления этого подхода в долгосрочной перспективе. Подход, где ограничения на потребителей задает производитель (назовем его классическим. Потому как в четырех из четырех мне известных ООП-платформ применяется именно он), выглядит менее демократичным. Но он, имхо, больше похож на реальность, где плодами трудов одного производителя пользуется множество потребителей. Поэтому производитель может себе позволить более высокую квалификацию, при которой принимаются правильные архитектурные решения. И требования к потребителям выдвигаются так, что они вынуждены следовать правильным решениям. От них заботливо убирают грабли, на которые можно наступить. Ты предлагаешь дать потребителям самим решать, чем им пользоваться, и пусть они отвечают за избыточные зависимости (которые не дадут им потом сделать upgrade на
новую версию библиотеки), и за поддержание инвариантов.
Все мимо, все не в кассу. Производительность достигается не
ограничениями, а возможностями. Не испробовав возможности, превышающие
твои текущие ограничения (а значит и мышление), не сможешь оценить все
плюсы и минусы.
Вот и со слоями — ну не видишь ты их здесь, а они есть...
Насчет — ты предлагаешь дать потребителям самим решать, чем им
пользоваться — абсолютно правильно подмечено. И поверь, на основе такой
предпосылки строится абсолютно иной более гибкий и продуктивный способ
мышления и построения программных систем.
[Кстати, тема из всеми любимого строительства — только главный
инженер полностью и безповоротно ответственен за решения принимаемые при
проектировании конструкции. На ком ответственность тот и решает как
разруливать зависимости и прочее].
> _>Нижеприведенные примеры ничего не говорят в пользу конкретно > _>protected/private. > Это почему еще? Давай-ка прокомментируй.
Достаточно в качестве контр-примера привести более гибкую схему,
например как указано выше.
Продуктивность неприемлет параноидальности. Бывали случаи, когда
приходилось копировать целые классы из базового сертифицированного ядра
для обхождения private.
Поэтому подход — чтобы вынудить их пользоваться только нашей
политикой — заведомо ущербен.
> >>>Простейшая штука: мы не хотим предоставлять внешним пользователям объекта возможностей по его конструированию, чтобы вынудить их пользоваться только нашей политикой создания.
Sinclair wrote:
> Здравствуйте, _vovin, Вы писали: > _>Бедный частный случай, а не изоморфизм. > Не понимаю умной мысли.
Человек говорил про неудачность protected/private, ты начал говорить про
необходимость ограничений в общем — но второе вовсе не требует первое.
> _>Про поведение там просто *ничего не сказано*. Поэтому мимо. Т.е. с > _>поведением ты можешь делать все что тебе заблагорассудится, в том числе > _>и private/protected. Если очень нужны фиче-грабли. > Там — это где?
В ООП. В общем случае спрятана только внутренняя структура.
> _>О, значит тебе осталася совсем маленький переход для понимания связи > _>между слоями и контролем видимости. > _>Туда же — layers, views, perspectives, subjects... > _>Видимо для мэйнстрима это terra incognita. > Снова не понимаю умной мысли. > _>Все мимо, все не в кассу. Производительность достигается не > _>ограничениями, а возможностями. > Какая именно производительность? Ок, ни одна из современных платформ не требует пользоваться чем-либо, кроме public. Объясни мне, какая именно производительность подымется, если пользоваться только им? Уж не производительность ли при поддержке написанного софта?
Речь о продуктивности разработки.
В частности private снижает продуктивность. Но отсутствие некоторого
количества ограничений увеличивает риски, что тоже нехорошо.
> _>Не испробовав возможности, превышающие > _>твои текущие ограничения (а значит и мышление), не сможешь оценить все > _>плюсы и минусы. > _>Вот и со слоями — ну не видишь ты их здесь, а они есть... > Где?
Указанный подход как раз был сформулирован как layered approach, но
естественным образом получается, что он может осуществлять контроль доступа.
Т.е. отвечая на твой вопрос "Где?" — по определению.
> _>Насчет — ты предлагаешь дать потребителям самим решать, чем им > _>пользоваться — абсолютно правильно подмечено. И поверь, на основе такой > _>предпосылки строится абсолютно иной более гибкий и продуктивный способ > _>мышления и построения программных систем. > Хм. То есть ты считаешь, что авторы С++, Delphi, Java, C# и VB.NET дружно заблуждаются? Можно в студию хоть какие-то аргументы, кроме усмешек и голословных заявлений?
Причем тут заблуждения?
Не все упорядочивается по принципу Заблуждение > Истина. Кое-что
выстраиваются в цепочки от частного к общему или от менее гибкого к
более гибкому. Всему свое время.
> >>>_>Нижеприведенные примеры ничего не говорят в пользу конкретно >>>_>protected/private. >>>Это почему еще? Давай-ка прокомментируй. > > > _>Достаточно в качестве контр-примера привести более гибкую схему, > _>например как указано выше. > Ну так приведи. То, что ты указал выше — всего лишь идея. Из нее не видно, как можно решать задачи структурирования решения, в том числе и контролировать зависимости.
"A Layered Approach to Software Design"
"A Simple and Unifying Approach to Subjective Objects"
> _>Продуктивность неприемлет параноидальности. > Бла-бла-бла. А давай я напишу "Продуктивность требует параноидальности". И дальше что? Аргументы, дружище, аргументы. > _>Бывали случаи, когда > _>приходилось копировать целые классы из базового сертифицированного ядра > _>для обхождения private. > _>Поэтому подход — чтобы вынудить их пользоваться только нашей > _>политикой — заведомо ущербен. > Ага. То есть из того, что существуют конкретные библиотеки, которые некорректно используют private, ты делаешь вывод об ущербности private вообще? Т.е. об инкапсуляции в целом, я тебя правильно понял?
Неверное обобщение. Наверняка можно собрать статистику какой процент
private является неоправданным и приводит к кривым заплаткам. Не это ли
минус к продуктивности?
> З.Ы. А я вот встречал случаи, когда люди занимались обходом private методом Copy/Paste только от того, что не смогли разобраться в штатном способе расширения функциональности. Ну, типа вместо того, чтобы штатно зарегистрировать свою фабрику, копировали класс и публиковали конструктор. Иожет, вместо private стоит запретить Copy/Paste?
И я такие встречал. Но этот случай не является пограничным для разных
подходов к ограничению доступа, поэтому рассматривать его в данном
контексте не интересно.
А мой случай — является. Там была фабрика, но нужно было сделать
реализацию на основе класса, в котором куча методов кроме одного
главного была private. Вот здесь и видна разница между непреодолимыми и
преодолимыми ограничениями.
Мне кажется, что ты боришся за очень странные идиалы. Ты все время пыташся объяснить всем окружающим, что вокруг куча идиотов пишущих невменяемые библиотеки поставляемые исключительно в виде неизменяемых компонентов. И что тебе лично постоянно приходится пользоваться этими компонентами постоянно нарываясь на невменяемость авторов. При это ты делашь вывод, что все ораничения (точнее инкапсуляци) по сути есть козни дьявола и только системы плюющие на инкапсуляцию есть истина в последней инстанции.
А может быть ты живешь в не нормальном мире? Может все же создатели библиотек несколько мудрее чем нерадивые пользователи? Может они не зря ставят private на методах и переменных?
Я вот согласен с синклером. Большинство жалающих заполучить доступ к private-членам — это просто не очень дальновидные люди (мягко выражаясь) не способные адекватно оценить ситуацию.
В конце концов если есть исходники проблему с небоснованным private можно решить за пару секунд. А если исходников нет, то можно договориться с авторами или просто написать аналогичный код (если уж авторы не вменяемые).
Но ты все ремя хочешь доказаь что инкапсулция — это грех. Не по тому ли что любимый язык-игрушка попросту не позволяет ее достичь?
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>но в более интересных ситуациях тебе поможет только дорогостоящее тестирование.
Забавный аргумент. Ты споришь с любителем Смолтока. А они как один костьми лягут, что все фигня и мир спосет юнит-естирование. И вообще проверка ошибок до рантайма — это мовитон.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
ANS>>Разных "зон" это от 3х до 5ти? Такого примитивизма я не принимаю. Если хочется так предоставить контролируемы контракт, то возьми и предоставь его в смысле, объект, который пересылает разрешённые сообщения объекту. Вариантов тут поболее 5ти . S>Этого я не понял. Наверное, туплю. Ты имеешь в виду динамическую проверку? Это уже Code Access Security и к областям видимости отношения не имеет.
Я говорил, скорее, об интерфейсах. Хотя, вариантов больше, чем стандартных модификаторов, в майнстримовых языках и не сделаеш.
ANS>>Очевидность необходимости модификаторов мне не очевидна. Повторю вопрос: что они дают? ANS>>Вот есть инкапсуляция. Она, уменьшая связность, даёт гибкость. Есть пространства имён (классов). Они уменьшают количество коллизий этих имён. Вот есть модификаторы. Они дают... ??? S>Блин, я уже уставать начинаю. Может, будем читать сообщения? Эти модификаторы — и есть инкапсуляция. Они уменьшают связность и дают гибкость.
Я так и не понял, почему "инкапсуляция = наличие модификаторов"?
Моё виденье такое: поведение объекта зависит от его состояния. Закрыв доступ к его состоянию мы получаем невозможность установки объекта в невалидное состояние со стороны. Нет возможности поломать состояние — есть инкапсуляция. А куда тут притулить модификаторы?
ANS>>>>Что даёт их наличие такого, чего нельзя достич при помощи обычной безуровневой инкапсуляции? S>>>Простейшая штука: мы не хотим предоставлять внешним пользователям объекта возможностей по его конструированию, чтобы вынудить их пользоваться только нашей политикой создания.
S>Ну, вот к примеру, если у нас созданием объектов рулит фабрика, то можно легко ее заменить на другую. А если конструктор объектов при этом публичный, то нет никакой гарантии, что после замены фабрики код будет корректным. В данном случае на большинстве применяемых ОО-языков ты сможешь обойтись банальным контекстным поиском, но в более интересных ситуациях тебе поможет только дорогостоящее тестирование.
Ну, так бы сразу и сказал, что модификатором можно прикрыть дырку в языке. Было бы создание объектов через посылку сообщения изначально (читай, через фабрику), не было б надобности закрывать конструктор.
Sinclair wrote:
> Здравствуйте, _vovin, Вы писали: > > _>Человек говорил про неудачность protected/private, ты начал говорить про > _>необходимость ограничений в общем — но второе вовсе не требует первое. > Гм. Я все воспринимаю буквально. Человек (ты, надо полагать, в виду имеешь Andrei N.Sobchuck) ничего про неудачность не говорил. Он спросил "зачем нужны модификаторы". Я ему ответил. > >>>Там — это где? > > _>В ООП. В общем случае спрятана только внутренняя структура. > А можно ссылку на это ООП? Меня вообще восхищает такой подход — если "в ООП" не было сказано о protected, значит protected есмь зло. Ага, а если в библии не было сказано про СТО — то Эйнштейн есмь зло. Ну да ладно.
Быстренько кончаем прикидываться умалишенным. Читаем то что написано — в
ООП ничего не сказано про protected, значит protected ничем особым не
должен выделяться относительно других возможных подходов и это понятие
не выведено на скрижалях истории. Значит мы вправе отказаться от такого
подхода при обнаружении проблем с ним и нахождении лучшего варианта.
Где я говорил, "если в ООП... — значит зло"? Про перспективы/субъекты
тоже ничего в ООП не сказано, и?...
> >>>Какая именно производительность? Ок, ни одна из современных платформ не требует пользоваться чем-либо, кроме public. Объясни мне, какая именно производительность подымется, если пользоваться только им? Уж не производительность ли при поддержке написанного софта? > > _>Речь о продуктивности разработки. > _>В частности private снижает продуктивность. Но отсутствие некоторого > _>количества ограничений увеличивает риски, что тоже нехорошо. > Ага. Совершенно верно. И с ростом размера проектов управление рисками выходит на передний плвн.
Угу риски неоправданных private вылазят одними из первых. Про
сбалансированность ограничений не задумывался?
> >>>Где? > > _>Указанный подход как раз был сформулирован как layered approach > Не вижу ни формулировки, ни указания. Вижу только туманные общие фразы, объяснения которым я вынужден придумывать самостоятельно. Фи.
В таких случаях rsdn-овцы говорят так — что я тебе целую статью должен
пересказывать? Тебе надо — найди и прочти.
> _>естественным образом получается, что он может осуществлять контроль доступа. > Каким образом? Что мне мешает обратиться из Layer1 прямо в Layer2?
Ты это можешь сделать только непосредственно включив один layer в
другой. А такие явные зависимости уже контролируемы.
> _>Т.е. отвечая на твой вопрос "Где?" — по определению. > Определения тоже никакого нет. Есть набор отрывочных фраз. > >>>Хм. То есть ты считаешь, что авторы С++, Delphi, Java, C# и VB.NET дружно заблуждаются? Можно в студию хоть какие-то аргументы, кроме усмешек и голословных заявлений? > > _>Причем тут заблуждения? Не все упорядочивается по принципу Заблуждение > Истина. Кое-что > _>выстраиваются в цепочки от частного к общему или от менее гибкого к > _>более гибкому. > Т.е. аргументов нет?
Гибкость — преодолимые ограничения, заданные хорошо контролируемыми
явными зависимостями. Негибкость — жесткие непреодолимые ни при каких
условиях ограничения, наподобие private.
Сойдет?
> _>Всему свое время. > Ок, я подожду, пока protected вымрет в результате естественного отбора. Ха-ха-ха. > >>>Ну так приведи. То, что ты указал выше — всего лишь идея. Из нее не видно, как можно решать задачи структурирования решения, в том числе и контролировать зависимости. > > _>"A Layered Approach to Software Design" > Это что, тест на пользование Google? > Ок. Вот что я нашел: http://www.cse.ucsc.edu/classes/cmps290g/Fall03/summary/pie_summary.pdf.
Ты нашел отзыв, по котором можно очень с трудом догадаться, что же
говорится в этой работе.
Признаю, что с поиском оригинала сейчас напряженка, раньше его очень
легко можно было найти.
Но тогда, по-крайней мере, не нужно было делать поспешных неверных
выводов на основе "одна бабка сказала"...
> Т.е. никакого отношения к видимости или управлению доступом здесь нет. Это всего лишь change tracking system, замена file-based VCS. Что еще из оффтопа предложишь?
Отзыв не указал главного, поэтому твой коммент съехал в оффтоп.
Главное назначение такого подхода — реализация design alternatives. При
наличии указанной схемы структурирования исходных текстов и layered
approach легко переключать различные варианты реализации — контексты. А
change tracking это один из побочных эффектов.
Механизм же layerd approach может быть различный. Как чисто механический
— мы состовляем граф беря из разных слоев разные альтернативы. Либо
можно придумать чисто декларативный, где слоям назначаются
идентификаторы, и мы можем указывать в своих слоях какие слои в каком
порядке включать. Вот это и будет примерно то, что я описал с областями
видимости.
В следующей статье уже более конкретно разбирается этот случай с
субъектами и перспективами.
> _>"A Simple and Unifying Approach to Subjective Objects" > Ок, нашел вот это. Оно? > Честно говоря, я не до конца понял идею. Я понял намеренения авторов — использовать единый подход как для видимости с т.з. объектов, так и с т.з. пользователей. Начинают они, фактически, с того, что декларируют недостаточность инкапсуляции данных, которую ты так защищаешь. Вот только вместо фиксированного набора областей видимости, предоставляемого мейнстримом, они предлагают задавать их вручную. Т.е. они не только не отказываются от protected, они предлагают расширить набор областей до неограниченного!
Все верно. Набор областей видимости неограничен. Это первое
преимущество. Второе — я могу видимость получить из любого места, в
случае же с protected мой код структурно ограничен откуда он может
доступиться. И мне как дизайнеру более высокоуровневого кода виднее
какие перспективы и куда включать.
То есть, в очередной раз повторяю, этот подход является
непринуждающим/неблокирующим, в отличие от private/protected, где тебя
вообще лишают шанса применить оптимальный в данной ситуации дизайн, либо
заставляют структурировать код, навязанный неудачным private/protected.
> Маахонькая тонкость: автор сам приписывает к коду обозначение той "области видимости", в которой он находится. Я, правда, так и не увидел в статье того места, где описывается perspective, из которой должен вызываться метод.
Надо знать Self/Us — там и код и слоты и объекты представляются
единообразно. Метод это просто объект с наличием activation record.
Поэтому конструкция — (...) (+) perspective — действует везде.
Дальше практически верно:
> > При этом одним выстрелом убиваются трое .Net-зайцев: > 1. Области видимости > 2. Интерфейсы
Это лишнее. Варианты использования перспектив и интерфейсов могут
пересекаться, но у интерфейсов изначально совсем другое назначение. В
динамическом языке не нужны интерфейсы как средство обеспечения
полиморфизма.
> 3. CAS > Таким образом, потребность в областях видимости все же есть. Есть также и подходы различной степени экзотичности к обеспечению этой потребности. Никаких причин к подходу Us рулить супротив Java или Net я пока не вижу.
Ну как же, как же. Одну статью не прочитал, вторую не до конца понял, а
берешься утверждать.
Классический пример — поддержка версионности. Одни и те же объекты в
разных перспективах (задающих версию) могут работать по-разному.
По-разному могут работать и конструкторы.
Возможны и другие интересные эффекты: перспектива Version_1_1 может
включать в себя Version_1_0 и переопределять только различающееся
поведение. При этом бывает необходимо иметь раздельное состояние для
различных версий. Тогда в перспективе Version_1_1 заводятся копии
необходимых полей объекта из Version_1_0. При этом в перспективе
Version_1_0 код из Version_1_0 будет естественно работать с полями из
Version_1_0. А в перспективе Version_1_1 — с полями из Version_1_1.
Или другой пример — запуск отладчика в отладчике (одно и то же адресное
пространство, одни и те же объекты) и его модифицирование.
Модифицирование ведется в другой перспективе, включающей перспективу
оригинального отладчика, в которой изменений не происходит, поэтому
отладка отладчика идет абсолютно без сбоев какие бы изменения мы не
проделывали.
> >>>Бла-бла-бла. А давай я напишу "Продуктивность требует параноидальности". И дальше что? Аргументы, дружище, аргументы. > > Т.е. аргументов опять нет.
Личный опыт и наблюдения. Про постоянное натыкание на private и
связанные с этим проблемы я говорил. В отсутствие private никаких
проблем не было, как это обосновать? Тем, что никаких проблем не было...
Это не выглядит супер-аргументом, поэтому и приводить-то его не стоит.
Многим и так интуитивно/эмпирически понятно.
> >>>Ага. То есть из того, что существуют конкретные библиотеки, которые некорректно используют private, ты делаешь вывод об ущербности private вообще? Т.е. об инкапсуляции в целом, я тебя правильно понял? > > _>Неверное обобщение. > Отлично. Вот только не я его сделал. Его делвешь ты.
Обобщение — это если утверждать, что везде работает хорошо. А я говорю —
уберите от меня эти private, т.к. это как ложка дегтя. Пусть все
библиотеки будут супер-пупер спроектированы, но стоит в одном месте
попасться кривому private, из-за чего мне придется скопировать двадцать
методов — и приплыли.
Т.е. это случай, когда неполезность доказывается *одним примером*. А
отсутствие проблем без private подтверждается личной практикой.
Если бы был инструмент, позволяющий самому контролировать доступ, тогда
*лично у меня* проблем бы было меньше.
Меня не интересует мнение разработчиков библиотек, которые "заботятся" о
пользователях библиотеки и лишают их любых возможностей доступа к
определенным частям (часто просто не недомыслию) — как бы чего не случилось.
Если механизм контроля доступа будет требовать *явного* включения
перспективы с именем *MyLibrary_very_restricted_area__dangerous для
доступа к каким-то внутренностям, то я сначала хорошо подумаю перед тем
как это сделать. И у меня будет *явная* зависимость на закрытую область.
> _>Наверняка можно собрать статистику какой процент > _>private является неоправданным и приводит к кривым заплаткам. > Ну так собери. Я нигде не говорю, что модификаторы доступа суть единственный способ реализации fine-grained encapsulation. Но твоя критика в их адрес выглядит, мягко говоря, неубедительной. На фоне этого твоя поза великого гуру, обрывки мыслей которого мы должны ловить с открытым ртом, смотрится смешно.
Личный наезд.
"Ну так собери" — абсурдное предложение. Свою статистику я примерно
представляю, а собирается она только при личном натыкании на проблему и
ее обход.
> _>Не это ли минус к продуктивности? > Лично мне — неизвестно. Минусов к продуктивности может быть столько, что ой-ой-ой. Совершенно не уверен, что именно private виноват.
"Именно" тут неуместно. Просто практическое наблюдение — от private
никакой пользы, одни проблемы при конкурирующей разработке.
А "именно" — это очень большой список — "именно" вот из-за таких-то
десяти/ста/тысячи причин дизайн кривой...
> _>А мой случай — является. Там была фабрика, но нужно было сделать > _>реализацию на основе класса, в котором куча методов кроме одного > _>главного была private. > Твой случай ничуть не лучше. Ну сделали тебе неудачный класс — и что теперь, private виноват? Я тебя уверяю — некорректных применений layer/perspective можно наплодить с той же легкостью. Да, залатать кривой дизайн будет проще. Но маинтайнить систему, состоящую из заплаток, я врагу не пожелаю.
Ну прям назвал заплаткой и понятие приобрело негативный смысл.
А private как представитель подхода *непреодолимых* ни при каких
условиях ограничений действительно сам по себе виноват своим существованием.
Здравствуйте, Sinclair, Вы писали:
S>Вроде бы нет. Я таки выбил из него ссылки на то, что он столь высокомерно цитирует. Это не Smalltalk. Это Us — настолько академический проект, что smalltalk на его фоне просто заезженный мейнстрим.
Поделись ссылочкой... А то "us" заезженное слово, по нему нифига в Гугле не находится
Обсуждение личностей является злостным оффтопом...
> Здравствуйте, _vovin, Вы писали: > > Мне кажется, что ты боришся за очень странные идиалы. Ты все время пыташся объяснить всем окружающим, что вокруг куча идиотов пишущих невменяемые библиотеки поставляемые исключительно в виде неизменяемых компонентов. И что тебе лично постоянно приходится пользоваться этими компонентами постоянно нарываясь на невменяемость авторов. При это ты делашь вывод, что все ораничения (точнее инкапсуляци) по сути есть козни дьявола и только системы плюющие на инкапсуляцию есть истина в последней инстанции.
Ты ошибся, авторов я считаю вполне умными и адекватными, но не им решать
какой вариант использования их библиотеки является наилучшим для моего
приложения для конкретной ситуации. Поэтому пусть они не будут создавать
жестких *непреодолимых* ограничений, и многие им скажут спасибо.
А бороться нужно с такими писаками как ты, которые норовят провести
анализ собственной проекции других личностей с учетом штампов,
сложившихся на основе неадекватно восприятой информации. =)
> > А может быть ты живешь в не нормальном мире? Может все же создатели библиотек несколько мудрее чем нерадивые пользователи? Может они не зря ставят private на методах и переменных?
Ненормальный = отличный от твоего?
В обычном мире мудрость/глупость не сильно коррелирует с создателями и
пользователями библиотек. Но пользователь в любом случае в целом умнее
именно для своего приложения, поэтому ему и решать. А создатели тоже
очень умные, т.к. используют свои библиотеки уже для *своих* приложений,
но у них есть очевидно преимущество — они могут быстренько подправить
непреодолимые ограничения своей библиотеки. У пользователей *частенько*
такой возможности нет.
> > Я вот согласен с синклером. Большинство жалающих заполучить доступ к private-членам — это просто не очень дальновидные люди (мягко выражаясь) не способные адекватно оценить ситуацию.
Учимся не говорить за всех.
А ты не думал, что private может быть поставлен потому что в этом
конкретном месте про реюзабилити никто специально не думал? Или в ходе
автоматического рефакторинга (Extract Method) или просто нежелания дать
некоторые возможности? Даже если автор очень умен и вроде бы все
продумал, где гарантия, что он учел все теоретические варианты?
> > В конце концов если есть исходники проблему с небоснованным private можно решить за пару секунд. А если исходников нет, то можно договориться с авторами или просто написать аналогичный код (если уж авторы не вменяемые).
Угу, вот тебе мой недавний пример — последняя версия ядра системы сдана
и сертифицирована, работать нужно именно с ней, переход на новую версию
не намечается да и смерти был бы подобен такой переход если бы захотели.
В итоге заводится собственный бранч, из нужного класса копируются
буквально все методы и делается небольшая правочка в одном из них.
> > Но ты все ремя хочешь доказаь что инкапсулция — это грех. Не по тому ли что любимый язык-игрушка попросту не позволяет ее достичь?
Читаем все, что написано. Предложенный мной вариант инкапсуляции
содержит бесконечное количество областей видимости (это отметил и Sinclair).
Тема тобой не изучена, разговаривать дальше пока не о чем.
Здравствуйте, Sinclair, Вы писали:
VD>>Но ты все ремя хочешь доказаь что инкапсулция — это грех. Не по тому ли что любимый язык-игрушка попросту не позволяет ее достичь? S>Вроде бы нет. Я таки выбил из него ссылки на то, что он столь высокомерно цитирует. Это не Smalltalk. Это Us — настолько академический проект, что smalltalk на его фоне просто заезженный мейнстрим. S>Прикол в том, что тот подход, который проповедует _vovin, преследует ровно те же цели, что и protected/private.
Мне показалось, что _vovin вообещ исповедут мысль о том, что все эти "protected/private" мешают ему делать то что он хочит с чужими библиотеками. И мне показалось, что он несколько раз говорил, что подобных проблем в Смолтоке у него нет. Можно переспросить его?
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _vovin, Вы писали:
_>Ты ошибся, авторов я считаю вполне умными и адекватными, но не им решать _>какой вариант использования их библиотеки является наилучшим для моего _>приложения для конкретной ситуации.
Забавно. Значит они не в праве определить публичный интерфейс своего класса и скрыть реализацию? Или они попросту не способны это сделать?
А ты когда нибудь слышаль такой термин "связанность"? Как ты думашь, как можно развивать библиотеку если куча уверенных в себе орлов влезли в ее кишки и пользуются ими как хотят? А если я в следующей вресии своего класса захочу изменить эти кишки? Ну, или я захочу использовать какую-то иную реализацию некого алгоритма? Что выслушивать гневные крити таких уверенных в себе "вертай все назад..."?
_> Поэтому пусть они не будут создавать _>жестких *непреодолимых* ограничений, и многие им скажут спасибо.
Грамотный разработчик определяет публичный интерфейс предоставляющий запланированную функциональность. Все остальное скрывается от потребителя. Потребитель видит класс как черный ящик с некоторым интерфейсом. Если автор не предоставил нужной функциональности через публичный интерфейс, то это просто не очень хорошая реализация. И стоит найти другую, убедить автора исправить свою ошибку, или написать собственную. А лезь в чюжое нижнее белье, да еще в большинстве не понимая всей сути происходящего — это самый плохой вариант.
_>А бороться нужно с такими писаками как ты,
Нда. Уровень ниже плинтуса.
_> которые норовят провести _>анализ собственной проекции других личностей с учетом штампов, _>сложившихся на основе неадекватно восприятой информации. =)
Боюсь я тебя растрою. Анализировать твою лично нет никакой нужды. Твои аргументы явно слабоваты и достаточно проанализировать их. Данный порыв хамства, который видимо тебя и обрадовал, только подтверждает это.
_>Ненормальный = отличный от твоего?
Нормальны == квалифицированный, грамотный.
_>В обычном мире мудрость/глупость не сильно коррелирует с создателями и _>пользователями библиотек.
Мудрость и глупость вообще не коррелируют. Это просто свойства людей. Но эдак мы уж совсем уйдем в абстрактную философию.
_> Но пользователь в любом случае в целом умнее _>именно для своего приложения, поэтому ему и решать.
Ясно. Именно этот вопрос меня и интересовал. Пользователь умнее. Это ему ведь нужен публичный интерфейс. И что там планировал разработчик класса пользователя колыхать не должно.
Боюсь, с тобой многие не согласятся. И уж точно ты противоречишь идеям ООП (на которые периодически ты так любишь ссылаться).
_> А создатели тоже _>очень умные, т.к. используют свои библиотеки уже для *своих* приложений, _>но у них есть очевидно преимущество — они могут быстренько подправить _>непреодолимые ограничения своей библиотеки. У пользователей *частенько* _>такой возможности нет.
А может быть это нормально? Почему ты не удивляешся тому, что ты не можешь быстренько подпрвить внутренее устройство кофемолки или принтера? Ну, или исправить микросхему чтобы твой монофонический приемник стал ДВД-плеером?
Мир не идеален. Бывают просто кривые библиотеки. Ищи библиотеки с исходниками. Или коришись с авторами. На худой конец создай свой аналог класса/библиотеки. Но не нужно ратовать за хаки создающие кучу пролем на ровном месте.
>> Я вот согласен с синклером. Большинство жалающих заполучить доступ к private-членам — это просто не очень дальновидные люди (мягко выражаясь) не способные адекватно оценить ситуацию.
_>Учимся не говорить за всех.
Это хорошо, что ты учишся это делать. Еще нужно учиться не приклеивать ярлыков и видеть только то что есть.
Я, как ты мог заметить, говорю за себя и соглашаюсь с одним человеком.
_>А ты не думал, что private может быть поставлен потому что в этом _>конкретном месте про реюзабилити никто специально не думал?
Тут и думать нечего. Может. Более того частенько так и происходит. В прочем, так же как частенько программисты ставят знак "-" вместо "+" и т.п. Это называется ошибкой.
_> Или в ходе автоматического рефакторинга (Extract Method) или просто нежелания дать некоторые возможности? Даже если автор очень умен и вроде бы все продумал, где гарантия, что он учел все теоретические варианты?
Гарантия в его имени. Хороший автор будет исправлять ошибки и стараться не допустить их. Как подстраховка может быть что библиотеку можно поставлять с исходниками. К сожалению подправление библиотек для личных нужд приводит к тем же проблемам что и зализание в чужие потраха через методы среды или языка. Но тут хотя бы можно попытаться убедить разработчика класса в неправоте и добиться того, чтобы в следующей вресии проблема была устранена.
_>Угу, вот тебе мой недавний пример — последняя версия ядра системы сдана _>и сертифицирована, работать нужно именно с ней, переход на новую версию _>не намечается да и смерти был бы подобен такой переход если бы захотели. _>В итоге заводится собственный бранч, из нужного класса копируются _>буквально все методы и делается небольшая правочка в одном из них.
Очень похоже на безграмотную организацию проекта и на столь же безграмотное проектирование. Хотя для рельного вывода нужно иметь намного больше информации.
>> Но ты все ремя хочешь доказаь что инкапсулция — это грех. Не по тому ли что любимый язык-игрушка попросту не позволяет ее достичь?
_>Читаем все, что написано. Предложенный мной вариант инкапсуляции _>содержит бесконечное количество областей видимости (это отметил и Sinclair).
Синклер отметил, что предложенный тобой вариант вообще не жизненоспособен. Или я его не так понял?
Потом ты как-то не очень хорошо объяснил как при твоем подходе защититься от любителей покапаться с чужой реализацией?
_>Тема тобой не изучена, разговаривать дальше пока не о чем.
Доктор сказал в морг, значит в мор. Не занимайтесь самоличением. Так что ли?
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote:
> Здравствуйте, _vovin, Вы писали: > > _>Ты ошибся, авторов я считаю вполне умными и адекватными, но не им решать > _>какой вариант использования их библиотеки является наилучшим для моего > _>приложения для конкретной ситуации. > > Забавно. Значит они не в праве определить публичный интерфейс своего класса и скрыть реализацию? Или они попросту не способны это сделать?
Скрыть в каком смысле? Если совсем-совсем скрыть, то им нужно все в
зашифрованный бинарный код вбить.
А если мне доступны исходники и я вижу что вот этот участок я вполне
использовать и адекватно оцениваю последствия, то почему бы и нет?
> > А ты когда нибудь слышаль такой термин "связанность"? Как ты думашь, как можно развивать библиотеку если куча уверенных в себе орлов влезли в ее кишки и пользуются ими как хотят? А если я в следующей вресии своего класса захочу изменить эти кишки? Ну, или я захочу использовать какую-то иную реализацию некого алгоритма? Что выслушивать гневные крити таких уверенных в себе "вертай все назад..."?
Я очень и очень в курсе что такое связность и как раз предлагаю очень
хорошо специфицированный контроль доступа.
И поверь, что никто запросто так не лезет в кишки библиотеки, если на
это нет очень веских оснований. Очень часто туда имеет смысл лезть чтобы
поправить баг разработчика. И если механизм контроля доступа требует
прописывания явных зависимостей, то очень легко контролировать кто
откуда пытается доступиться в чужие кишки.
> > _> Поэтому пусть они не будут создавать > _>жестких *непреодолимых* ограничений, и многие им скажут спасибо. > > Грамотный разработчик определяет публичный интерфейс предоставляющий запланированную функциональность. Все остальное скрывается от потребителя. Потребитель видит класс как черный ящик с некоторым интерфейсом. Если автор не предоставил нужной функциональности через публичный интерфейс, то это просто не очень хорошая реализация. И стоит найти другую, убедить автора исправить свою ошибку, или написать собственную. А лезь в чюжое нижнее белье, да еще в большинстве не понимая всей сути происходящего — это самый плохой вариант.
> > _>А бороться нужно с такими писаками как ты, > > Нда. Уровень ниже плинтуса. > > _> которые норовят провести > _>анализ собственной проекции других личностей с учетом штампов, > _>сложившихся на основе неадекватно восприятой информации. =) > > Боюсь я тебя растрою. Анализировать твою лично нет никакой нужды. Твои аргументы явно слабоваты и достаточно проанализировать их. Данный порыв хамства, который видимо тебя и обрадовал, только подтверждает это.
Ответ на сарказм — вровень с плинтусом. =)
> > _>Ненормальный = отличный от твоего? > > Нормальны == квалифицированный, грамотный. > > _>В обычном мире мудрость/глупость не сильно коррелирует с создателями и > _>пользователями библиотек. > > Мудрость и глупость вообще не коррелируют. Это просто свойства людей. Но эдак мы уж совсем уйдем в абстрактную философию.
Значит сойдемся, что все умные.
> > _> Но пользователь в любом случае в целом умнее > _>именно для своего приложения, поэтому ему и решать. > > Ясно. Именно этот вопрос меня и интересовал. Пользователь умнее. Это ему ведь нужен публичный интерфейс. И что там планировал разработчик класса пользователя колыхать не должно.
А если пользователь умный настолько, что заметил баг в библиотеке? Или
что увидел неоправданный private на метод, который можно переопределить
и этим избавиться от вагона кода?
> > Боюсь, с тобой многие не согласятся. И уж точно ты противоречишь идеям ООП (на которые периодически ты так любишь ссылаться).
Брось, каждый под ООП понимает столько разного, прям ужас.
> > _> А создатели тоже > _>очень умные, т.к. используют свои библиотеки уже для *своих* приложений, > _>но у них есть очевидно преимущество — они могут быстренько подправить > _>непреодолимые ограничения своей библиотеки. У пользователей *частенько* > _>такой возможности нет. > > А может быть это нормально? Почему ты не удивляешся тому, что ты не можешь быстренько подпрвить внутренее устройство кофемолки или принтера? Ну, или исправить микросхему чтобы твой монофонический приемник стал ДВД-плеером?
Т.е. все-таки ты предполагаешь, что пользователь всегда глупее? А если
он на досуге эти кофемолки мастерит и прошивки для двд правит?
> > Мир не идеален. Бывают просто кривые библиотеки. Ищи библиотеки с исходниками. Или коришись с авторами. На худой конец создай свой аналог класса/библиотеки. Но не нужно ратовать за хаки создающие кучу пролем на ровном месте.
Библиотеки с исходниками — круто. Но как только тебе нужно
сертифицировать определенные версии всех библиотек и написать якобы
чуточку кода, чтобы это все склеить, а потом оказывается, что во всех
библиотеках нужно подправить кучу багов и добиться от них реюзабилити,
которая в них не заложена из-за private, то рисуется совсем другая картина.
А про хаки ты зря. Если тебе такой подход не нравится, это еще не значит
хак. В скриптовых языках вообще отсутствует контроль доступа — это одна
противоположность. Делать private все, что не в публичных интерфейсах —
это вторая противоположность. Но, как обычно, противоположности сходятся
в одной точке.
> > >>>Я вот согласен с синклером. Большинство жалающих заполучить доступ к private-членам — это просто не очень дальновидные люди (мягко выражаясь) не способные адекватно оценить ситуацию. > > > _>Учимся не говорить за всех. > > Это хорошо, что ты учишся это делать. Еще нужно учиться не приклеивать ярлыков и видеть только то что есть.
Не придирайся. Я говорю по факту — я увидел абсолютно тупо навешанный
private, который напрашивается быть protected, чтобы этот метод был
перегружен.
Но все равно в твоей реальности я отношусь к "просто не очень
дальновидные люди (мягко выражаясь) не способные адекватно оценить
ситуацию"?
> > Я, как ты мог заметить, говорю за себя и соглашаюсь с одним человеком. > > _>А ты не думал, что private может быть поставлен потому что в этом > _>конкретном месте про реюзабилити никто специально не думал? > > Тут и думать нечего. Может. Более того частенько так и происходит. В прочем, так же как частенько программисты ставят знак "-" вместо "+" и т.п. Это называется ошибкой.
— на + меняется в ходе тестирования, а private на protected только если
кто-то в дальнейшем уткнется в него носом, но у него уже может не быть
такой возможности — если версии библиотек жестко фиксируются.
На хороший дизайн юнит-тестов не придумаешь.
> > _> Или в ходе автоматического рефакторинга (Extract Method) или просто нежелания дать некоторые возможности? Даже если автор очень умен и вроде бы все продумал, где гарантия, что он учел все теоретические варианты? > > Гарантия в его имени. Хороший автор будет исправлять ошибки и стараться не допустить их. Как подстраховка может быть что библиотеку можно поставлять с исходниками. К сожалению подправление библиотек для личных нужд приводит к тем же проблемам что и зализание в чужие потраха через методы среды или языка. Но тут хотя бы можно попытаться убедить разработчика класса в неправоте и добиться того, чтобы в следующей вресии проблема была устранена.
Нет, это ошибка должна быть как-то устранена к такой-то релиз-дате и
точка. А библиотеки менять нельзя.
Может быть хороший автор все делает хорошо, но и супер-мастер местами
бывает откровенно тупит.
> > _>Угу, вот тебе мой недавний пример — последняя версия ядра системы сдана > _>и сертифицирована, работать нужно именно с ней, переход на новую версию > _>не намечается да и смерти был бы подобен такой переход если бы захотели. > _>В итоге заводится собственный бранч, из нужного класса копируются > _>буквально все методы и делается небольшая правочка в одном из них. > > Очень похоже на безграмотную организацию проекта и на столь же безграмотное проектирование. Хотя для рельного вывода нужно иметь намного больше информации.
Молодец. Я бы с тобой пожалуй согласился, если бы в задачах проекта ядра
было определение всех самых невероятных возможностей реюзабилити.
А так — не катит. Проект был сдан в срок, функциональность закрыта —
значит он вполне хороший.
> > >>>Но ты все ремя хочешь доказаь что инкапсулция — это грех. Не по тому ли что любимый язык-игрушка попросту не позволяет ее достичь? > > > _>Читаем все, что написано. Предложенный мной вариант инкапсуляции > _>содержит бесконечное количество областей видимости (это отметил и Sinclair). > > Синклер отметил, что предложенный тобой вариант вообще не жизненоспособен. Или я его не так понял?
По-моему он сказал, что вариант покрывает кучу возможностей. Но ему
все-таки не нравится.
> > Потом ты как-то не очень хорошо объяснил как при твоем подходе защититься от любителей покапаться с чужой реализацией?
У меня такой задачи не стоит, но она реализуема. Нет времени все описывать.
> > _>Тема тобой не изучена, разговаривать дальше пока не о чем. > > Доктор сказал в морг, значит в мор. Не занимайтесь самоличением. Так что ли?
Все в норме. Вон уже два других человека примерно поняли что к чему.
Может удастся поговорить о деталях...
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Я так и не понял, почему "инкапсуляция = наличие модификаторов"?
потому, что инкапсуляция == возможность скрывать детали реализации от разных потребителей. модификаторы доступа дают возможность классифицировать этих потребителей. Ты точно читаешь то, что я пишу?
ANS>Моё виденье такое: поведение объекта зависит от его состояния. Закрыв доступ к его состоянию мы получаем невозможность установки объекта в невалидное состояние со стороны. Нет возможности поломать состояние — есть инкапсуляция. А куда тут притулить модификаторы?
Ну естественно. В таком понимании инкапсуляции модификаторы не нужны.
ANS>Ну, так бы сразу и сказал, что модификатором можно прикрыть дырку в языке. Было бы создание объектов через посылку сообщения изначально (читай, через фабрику), не было б надобности закрывать конструктор.
Помимо конструктора, приходится еще много чего закрывать.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
ANS>>Я так и не понял, почему "инкапсуляция = наличие модификаторов"? S>потому, что инкапсуляция == возможность скрывать детали реализации от разных потребителей. модификаторы доступа дают возможность классифицировать этих потребителей. Ты точно читаешь то, что я пишу?
сто пудов сверху по ветке можно найти изначальный вопрос: какая польза то такого понимания инкапсуляции.
Ты сказал, что польза — маленький публичный интерфейс. Я думаю, если у класса интерфейс большой, то
просто приложив "private/protected" к "не нужным потребителю" методам проблему не решить. Тут рефакторить нужно.
Еще?
ANS>>Моё виденье такое: поведение объекта зависит от его состояния. Закрыв доступ к его состоянию мы получаем невозможность установки объекта в невалидное состояние со стороны. Нет возможности поломать состояние — есть инкапсуляция. А куда тут притулить модификаторы? S>Ну естественно. В таком понимании инкапсуляции модификаторы не нужны.
Хе-хе. Тогда, на вопрос сверху можно не отвечать, ибо мы сошлись в точке когда понимаем "понимание" друг друга, но не принимаем его.
ANS>>Ну, так бы сразу и сказал, что модификатором можно прикрыть дырку в языке. Было бы создание объектов через посылку сообщения изначально (читай, через фабрику), не было б надобности закрывать конструктор. S>Помимо конструктора, приходится еще много чего закрывать.
Если так много примеров, то можно и еще хоть один привести?
