Здравствуйте, XopoSHiy, Вы писали:
XSH>А все эти public / protected — это корявенький, неполный, неестественный, но легковесный способ реализации желания упомянутых программистов. Какой-то шаг в направлении моих мыслей был сделан с появлением такой абстракции, как Interface в Delphi.
Я думаю, проблема легко решается заменой 'vs' в сабже на '+', особенно в контексте интерфейсов
Между природой и назначением этих вещей нельзя поставить знак равенства и потом их сравнивать. Это разные вещи, которые дополняют друг друга.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Если нам не помогут, то мы тоже никого не пощадим.
XSH>Все эти private, public, protected, и даже friend-ы — это полумеры. XSH>В действительности, всех пользователей класса (под пользователями я имею в виду другие классы) можно разделить на группы: одним надо то, другим сё, третьим и то и сё. Фактически это раздача пользователям ролей. XSH>Соответственно, хочется чтобы пользователям было доступно только то подмножество интерфейса нашего класса, которое необходимо для его роли. Вот. Это я попытался чётко сформулировать то, что хотят программисты в лице меня
Не совсем так. Модификаторы доступа — это классификация пользователей по их отношению к классу. Отличие от ролей в том, что их невозможно назначить произвольно. Всегда точно известно, является ли, к примеру, класс нашим наслежником (т.е. доступ через protected).
Очень редко удается придумать какие-нибудь еще классифицирующие признаки, кроме заложенных в модели. Потому, что про произвольно взятый класс мы не так уж много можем сказать.
Если этого не хватает, и требуется более гибкий способ раздавать коду привилегии, то реализуют Code Access Security. Там уже все по-настоящему. XSH>А все эти public / protected — это корявенький, неполный, неестественный, но легковесный способ реализации желания упомянутых программистов. Какой-то шаг в направлении моих мыслей был сделан с появлением такой абстракции, как Interface в Delphi.
Ты какой имеешь в виду? Тот, который interface/implementation, или type t = interface? Второй не имеет никакого отношения к твоим мыслям. Теоретически можно искусственно разделить интерфейс любого класса на два интерфейса — для public и protected, предполагая, что последним будут пользоваться только потомки. Ну или на еще более мелкие градации, предполагая раздачу интерфейсов на основе более сложных правил. На практике это лишено смысла, т.к. все интерфейсы доступны равноправно, и нет никакой проблемы выполнить приведение. XSH>Аналоги есть и в других языках. (в Java, например). Однако идея всё ещё не развита до той степени, до которой могла бы быть развита...
На мой взгляд, дальше чем CAS уехать сложно. XSH>К примеру, всё ещё нельзя при наследовании от класса указать внутренности каких интерфейсов мы будем менять, а каких, нет и тп.
Этого я не понял. Это ты вообще про что?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
СГ>>У класса нет пользователей, тем более другие классы не могут быть пользователями. Класс = классификация — есть описание. У описания нет пользователей, и описание само не может быть пользователем. Пользователи могут быть у ОБЪЕКТА, и сами ОБЪЕКТЫ могут быть пользователями.
XSH>Пользователи класса — это пользователи объектов данного класса. Неужели выдержки не хватает молча это осознать, вместо того, чтобы тут флудить?
И все же можно сказать инкапсуляция на уровне классов это полумеры по сравнению с инкапсуляцией на уровне компонент (или модулей), и компонента может вобще не предоставлять никаких классов (ни для наследования ни для чего другого), а предоставлять только интерфейсы (в каком либо формате) к реальным объектам, обьектным моделям, которыми управляет сама компонента. Это все же лежит за пределами компетнции классов.
Классы не принято как-то увязывать с диаграммами объектов. Можно внатяжку сказать: если для какой то сущности очень важна диаграмма объектов (а не классов), это скорее компонента (или назовем модуль, не важно) чем класс.
Отличия между компонентами и классами более существенные, чем то что класс в виде исходников, а компонента уже откомпилирована. Примерно такие же как между диаграммами классов и диаграммами объектов.
...Хотя к таким высказываниям и терминологии всегда можно придраться... отличия тонкие, но существенные.
Процесс написания очередного набора классов вызвала вот какую философскую мысль.
Все эти private, public, protected, и даже friend-ы — это полумеры. В действительности, всех пользователей класса (под пользователями я имею в виду другие классы) можно разделить на группы: одним надо то, другим сё, третьим и то и сё. Фактически это раздача пользователям ролей. Соответственно, хочется чтобы пользователям было доступно только то подмножество интерфейса нашего класса, которое необходимо для его роли. Вот. Это я попытался чётко сформулировать то, что хотят программисты в лице меня :)
А все эти public / protected — это корявенький, неполный, неестественный, но легковесный способ реализации желания упомянутых программистов. Какой-то шаг в направлении моих мыслей был сделан с появлением такой абстракции, как Interface в Delphi. Аналоги есть и в других языках. (в Java, например). Однако идея всё ещё не развита до той степени, до которой могла бы быть развита... К примеру, всё ещё нельзя при наследовании от класса указать внутренности каких интерфейсов мы будем менять, а каких, нет и тп.
Здравствуйте, XopoSHiy, Вы писали: XSH>К примеру, всё ещё нельзя при наследовании от класса указать внутренности каких интерфейсов мы будем менять, а каких, нет и тп.
Внутренности значит методы? Так у интерфейсов нет методов.
Я думаю, интерфейсы на данный момент самое гибкое средство. По сути это и есть роли. Каждый "клиент" класса работает через свой интерфейс.
Здравствуйте, Sinclair, Вы писали:
S>Не совсем так. Модификаторы доступа — это классификация пользователей по их отношению к классу. Отличие от ролей в том, что их невозможно назначить произвольно. Всегда точно известно, является ли, к примеру, класс нашим наслежником (т.е. доступ через protected). S>Очень редко удается придумать какие-нибудь еще классифицирующие признаки, кроме заложенных в модели. Потому, что про произвольно взятый класс мы не так уж много можем сказать.
Да уж, редко...
Есть владелец. Есть его соствляющие. Владелец использует маленький интерфейс для работы со своими составляющими. Составляющие содержат богатый интерфейс для остальных пользователей. Составляющие содержат небольшой интерфейс для взаимодействия друг с другом. Мне приходится перемешивать методы, для владельца и для взаимодействия с себе подобными. То есть получается свалка методов из разных ролей в одной большой секции protected. Приходится терпеть, потому что иначе никак. Ну и владелец, зачем-то видит все методы составляющих, хотя нужен ему только малая часть их всех.
S>Если этого не хватает, и требуется более гибкий способ раздавать коду привилегии, то реализуют Code Access Security. Там уже все по-настоящему.
А можно по-подробнее. Что за зверь и где про него почитать?
XSH>>А все эти public / protected — это корявенький, неполный, неестественный, но легковесный способ реализации желания упомянутых программистов. Какой-то шаг в направлении моих мыслей был сделан с появлением такой абстракции, как Interface в Delphi. S>Ты какой имеешь в виду? Тот, который interface/implementation, или type t = interface? Второй не имеет никакого отношения к твоим мыслям.
Второй, конечно! И очень даже имеет :)
Роли можно воплотить в интерфейсах. Тогда если владелец будет работать с интерфейсными переменными он будет видеть только методы из своей роли. Другое дело, что методы всё ещё будут находится в одной свалке под названием секция protected (или public — не суть...).
S> Ну или на еще более мелкие градации, предполагая раздачу интерфейсов на основе более сложных правил. На практике это лишено смысла, т.к. все интерфейсы доступны равноправно, и нет никакой проблемы выполнить приведение.
Хм... интерфейсную переменную привести к какому-нибудь левому типу вроде нельзя (по крайней мере в Delphi, по крайней мере ИМХО :))
XSH>>К примеру, всё ещё нельзя при наследовании от класса указать внутренности каких интерфейсов мы будем менять, а каких, нет и тп. S>Этого я не понял. Это ты вообще про что?
:)
Наследуюсь я от "составляющей". Я не собираюсь менять уже реализованный интерфейс работы с владельцем. Так вот хочу, чтоб
этот факт можно было как-то явно отразить в исходном коде, и чтоб компилятор на этапе компиляции этот факт проверил.
Здравствуйте, IT, Вы писали:
XSH>>А все эти public / protected — это корявенький, неполный, неестественный, но легковесный способ реализации желания упомянутых программистов. Какой-то шаг в направлении моих мыслей был сделан с появлением такой абстракции, как Interface в Delphi.
IT>Я думаю, проблема легко решается заменой 'vs' в сабже на '+', особенно в контексте интерфейсов :)
Не согласен. Сейчас у меня нет возможности полноценно реализовать разделение ролей. Но какое-то подобие предлагает механизм разделения областей видимости. Однако проблемы это безусловно не решает. После того, как я vs заменю на +, я все ещё буду не способен реализовать механизм ролей :)
IT>Между природой и назначением этих вещей нельзя поставить знак равенства и потом их сравнивать. Это разные вещи, которые дополняют друг друга.
А вот с этим согласен. "vs" в subj-е действительно получилось маленько не в тему...
Здравствуйте, beroal, Вы писали:
B>Здравствуйте, XopoSHiy, Вы писали: XSH>>К примеру, всё ещё нельзя при наследовании от класса указать внутренности каких интерфейсов мы будем менять, а каких, нет и тп. B>Внутренности значит методы? Так у интерфейсов нет методов.
Я имел в виду реализации каких интерфейсов будут изменены.
B>Я думаю, интерфейсы на данный момент самое гибкое средство. По сути это и есть роли. Каждый "клиент" класса работает через свой интерфейс.
Кто есть где на данный момент я более менее представляю и мне это не интересно
Мне хочется понять как всё будет в светлом будущем :)
Я не знаю, как реализованы подобные вещи в Java. Я даже не знаю, реализованы ли они. Но очевидно, что с одной стороны, в неуправляемой среде ты их не получишь (из-за отсутствия возможности исследовать стек в рантайме и убогости метаданных), а с другой стороны, в управляемой среде это вполне возможно. Так что интуитивно я ожидаю наличия Java-аналога.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, XopoSHiy, Вы писали:
XSH> Все эти private, public, protected, и даже friend-ы — это полумеры.
Да, совершенно верно, это полумеры. Настоящая инкапсуляция возможна только на уровне модуля.
XSH> В действительности, всех пользователей класса (под пользователями я имею в виду другие классы)
У класса нет пользователей, тем более другие классы не могут быть пользователями. Класс = классификация — есть описание. У описания нет пользователей, и описание само не может быть пользователем. Пользователи могут быть у ОБЪЕКТА, и сами ОБЪЕКТЫ могут быть пользователями.
XSH> можно разделить на группы: одним надо то, другим сё, третьим и то и сё. Фактически это раздача пользователям ролей. Соответственно, хочется чтобы пользователям было доступно только то подмножество интерфейса нашего класса, которое необходимо для его роли.
Для этого придуманы паттерны ООП:
1) Carrier/Rider/Mapper, где Rider = {Reader, Writer}, Mapper = {Scanner, Formatter}.
2) Model/View/Controller
3) "Посылка сообщения"
Для каждого конкретного случая можно использовать аналоги этих паттернов. Агрегация объектов другими объектами, а вовсе не наследование описаний (т.е. классов) является основной сутью этих паттернов.
Здравствуйте, Сергей Губанов, Вы писали:
XSH>> Все эти private, public, protected, и даже friend-ы — это полумеры. СГ>Да, совершенно верно, это полумеры. Настоящая инкапсуляция возможна только на уровне модуля.
Кто про что, а СГ про инкапсуляцию на уровне модуля :) И причём тут модуль?....
XSH>> В действительности, всех пользователей класса (под пользователями я имею в виду другие классы)
СГ>У класса нет пользователей, тем более другие классы не могут быть пользователями. Класс = классификация — есть описание. У описания нет пользователей, и описание само не может быть пользователем. Пользователи могут быть у ОБЪЕКТА, и сами ОБЪЕКТЫ могут быть пользователями.
Пользователи класса — это пользователи объектов данного класса. Неужели выдержки не хватает молча это осознать, вместо того, чтобы тут флудить?
СГ>Для этого придуманы паттерны ООП: СГ>1) Carrier/Rider/Mapper, где Rider = {Reader, Writer}, Mapper = {Scanner, Formatter}. СГ>2) Model/View/Controller СГ>3) "Посылка сообщения"
СГ>Для каждого конкретного случая можно использовать аналоги этих паттернов. Агрегация объектов другими объектами, а вовсе не наследование описаний (т.е. классов) является основной сутью этих паттернов.
Я понимаю, что описанная мной проблема частично решается ещё и деллегированием части обязанностей агрегатам. Так можно добиться разделения той свалки методов на аккуратные группки. В купе с деллегированием реализации интерфейса своим агрегатам (эта фича есть в моём рабочем языке — Delphi) вроде бы получается почти-почти то что надо. Но суть в том, что все эти естественные вещи приходится реализовывать не поймёшь как самомому. Мне банально лень из-за чувства красоты писать больше кода, чем реально надо, да ещё и корявого такого кода. Почему это не поддерживается самим языком? Это же достаточно естественное желание, разве нет? ;)
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, XopoSHiy, Вы писали:
XSH>> Все эти private, public, protected, и даже friend-ы — это полумеры.
СГ>Да, совершенно верно, это полумеры. Настоящая инкапсуляция возможна только на уровне модуля.
На уровне интерфейса или через Proxy тоже возможна настоящая инкапсуляция.
Здравствуйте, XopoSHiy, Вы писали:
XSH>Привет всем.
XSH>Процесс написания очередного набора классов вызвала вот какую философскую мысль.
XSH>Все эти private, public, protected, и даже friend-ы — это полумеры. В действительности, всех пользователей класса (под пользователями я имею в виду другие классы) можно разделить на группы: одним надо то, другим сё, третьим и то и сё. Фактически это раздача пользователям ролей. Соответственно, хочется чтобы пользователям было доступно только то подмножество интерфейса нашего класса, которое необходимо для его роли. Вот. Это я попытался чётко сформулировать то, что хотят программисты в лице меня
Скорее наоборот. Интерфейс класс — это некоторый контракт предлагаемый внешним пользователям. Выбирать что и как из этого использовать, решают сами пользователи.
Да и почему это полумеры? Нормальный интерфейс обусловленный возможностями и спецификацией языка. Это отнюдь не значит, что ты не сможешь использовать внутреннюю логику класса. Просто на это уйдет несколько больше времени. Дизассемблеры и рефлекторы никто не отменял. Если ты выполняешь контракт, то ты сам себе гарантируешь отсутсвие проблем.
XSH>А все эти public / protected — это корявенький, неполный, неестественный, но легковесный способ реализации желания упомянутых программистов. Какой-то шаг в направлении моих мыслей был сделан с появлением такой абстракции, как Interface в Delphi. Аналоги есть и в других языках. (в Java, например). Однако идея всё ещё не развита до той степени, до которой могла бы быть развита... К примеру, всё ещё нельзя при наследовании от класса указать внутренности каких интерфейсов мы будем менять, а каких, нет и тп.
Если у тебя правильно построен дизайн, то таких проблем не будет. Сама теория ООП дает понятие инкапсуляции и как ее делать правильно. Если говорить о компонентах, то там вмешиваться во внутреннюю логику тебе никто не даст.+
Интерфейс, это утверждение что данная функциональность в классе реализована и ею безопасно можно использовать. К вопросу о наследовании отношения не имеет. Не реализованные интерфейсы это нонсенс.
Здравствуйте, XopoSHiy, Вы писали:
XSH>Все эти private, public, protected, и даже friend-ы — это полумеры. В действительности, всех пользователей класса (под пользователями я имею в виду другие классы) можно разделить на группы: одним надо то, другим сё, третьим и то и сё. Фактически это раздача пользователям ролей. Соответственно, хочется чтобы пользователям было доступно только то подмножество интерфейса нашего класса, которое необходимо для его роли. Вот. Это я попытался чётко сформулировать то, что хотят программисты в лице меня
XSH>А все эти public / protected — это корявенький, неполный, неестественный, но легковесный способ реализации желания упомянутых программистов. Какой-то шаг в направлении моих мыслей был сделан с появлением такой абстракции, как Interface в Delphi. Аналоги есть и в других языках. (в Java, например). Однако идея всё ещё не развита до той степени, до которой могла бы быть развита... К примеру, всё ещё нельзя при наследовании от класса указать внутренности каких интерфейсов мы будем менять, а каких, нет и тп.
Вобщем ты путаешь нгазначение разных механизмов. Модификаторы доступа на самом деле не предназначены для решения проблем распределения прав. Существуют они исключительно для одного — изоляции деталей реализации для внешнего мира. Для всего внешнего мира, а не для кого то, не обладающего правами. А для разграничения прав кода, как справедливо заметил Sinclair, обычно создают другие механизмы, более сложные и навороченные, навроде CAS в дотнете.
Если нам не помогут, то мы тоже никого не пощадим.
