Здравствуйте, igna, Вы писали:
I>А именно? Наследование от iterator_traits? Так там весьма своеобразная "реализация", состоящая исключительно из определений типов. Даже если наследование от iterator_traits можно назвать "повторным использованием кода", в таком виде оно не имеет недостатков присущих наследованию реализации в общем виде. Этот антипаттерн в STL вообще не используется.
В одной из корпоративных библиотек видел фантазию на тему бустового shared_ptr, где в качестве trait`а передавался класс, реализующий блокировку. Я такой сценарий имел в виду.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, LaPerouse, Вы писали:
AVK>>>До наследования только контракта мейнстрим, слава богу, дошел, дело за наследованием реализации без наследования контракта. LP>>Такое можно делать и без поддержки в языке "наследования реализации без интерфейсов". AVK>Можно. Делегированием. Но уж очень неудобно.
Или множественным наследованием. При этом наследник будет невидим вне своего пакета, будут торчать лишь его интерфейс. Это удобнее делегирования, так как не нужно создавать делегирующие методы, при этом цели достигаются те же (гибкость интерфейса, отсутствие привязанности к иерархии наследования). Понятно, это не замена делегирования вообще, это замена конкретного применения делегирования (для наследования реализации).
AVK>>>Дело не в формализации, а в откровенно неверных предпосылках. LP>>А они берутся из-за отсутствия формализации. AVK>Крайне сомнительно. ЯП это не явление природы, естественнонаучные методы к нему в полном объеме неприменимы. ЯП, в виду своего назначения (обеспечение взаимодействия машинной логики с моском человека) в немалой степени определяется нематериальными аспектами культуры, например образом мышления программиста. И эти самые аспекты с формализацией дружат очень плохо. Можно загнать программизм в рамки формализма, но результатом будет жуткая неудобоваримость, как, к примеру, в квантовой физике, когда сильно упрощенные модели описываются невероятно трудным в понимании каскадом высшей математики. Современного размера и сложности программу так не напишешь.
Так ведь я не предлагаю формализовать ЯП, я предлагаю формализовать знания о методиках программирования. На нашем примере: мы имеем конкретную проблему — отсутствует понимание того, в каких случаях надо использовать наследование реализации, в каких — контракта. Происхождение проблемы: большинство авторов учебников не уделяют должного внимания этому аспекту. Почему? Причина банальна: мало кто из авторов обладает по-настоящему экспертными знаниями в той области, о которой пишет. Действительно ценные книги и статьи, написанные профессионалами, теряются среди кучи всяких "Освой Java за 21 день". Проблема может иметь решение — стандартизация экспертных знаний различных предметных областей путем создания семантической базы знаний (стандартизация знаний в текстовом виде невозможна). Все средства на сегодня уже существуют — детально разработаны форматы хранения данных (RDF+OWL), созданы эффективные хранилища (Oracle 11g, jena store), существуют проработанные языки запросов (RDFQL, SPARQL). Предстоит многолетняя работа по созданию и стандартизации словарей и онтологий, эта работа уже идет. К сожалению, идет очень медленно, поскольку производительные процессы кап. общества завязаны на прибыль, а прибыль разработчикам онтологий если и светит, то не в ближайшем будущем. Онтологии создаются в основном для своих текущих нужд. Но даже капитализм рано или поздно таки доползет до создания публичных стандартизованных онтологий и баз знаний.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, 0x7be, Вы писали:
0>В одной из корпоративных библиотек видел фантазию на тему бустового shared_ptr, где в качестве trait`а передавался класс, реализующий блокировку. Я такой сценарий имел в виду.
Здравствуйте, igna, Вы писали:
0>>В одной из корпоративных библиотек видел фантазию на тему бустового shared_ptr, где в качестве trait`а передавался класс, реализующий блокировку. Я такой сценарий имел в виду. I>Ну так это не в STL.
Виноват, ввёл в заблуждение
Но идея, я думаю, понятна.
Здравствуйте, LaPerouse, Вы писали:
LP>Или множественным наследованием.
А МН даже с приватным наследованием тянет за собой слишком много связей.
LP>Так ведь я не предлагаю формализовать ЯП, я предлагаю формализовать знания о методиках программирования.
Можно формализовать знания о методиках психоанализа? О том, какая мелодия понравится? Какое кино будет интересным?
LP>Причина банальна: мало кто из авторов обладает по-настоящему экспертными знаниями в той области
Не не не. Либо экспертная оценка, либо формализация. Это принципиально разные методы.
LP>, о которой пишет. Действительно ценные книги и статьи, написанные профессионалами, теряются среди кучи всяких "Освой Java за 21 день".
Да не теряются они. Проблема куда глубже. В качестве примера — безобразную и безграмотную книгу Троелсена по дотнету здесь в форумах советует чуть ли не каждый второй. Что то ведь ее выделило среди тонн таких же безграмотных книг?
LP> Проблема может иметь решение — стандартизация экспертных знаний различных предметных областей путем создания семантической базы знаний
Что то тебя кидает в разные стороны. То был формализм, теперь вот экспертная оценка и базы знаний. Ты уж определись, которая из них серебряная.
LP>Предстоит многолетняя работа по созданию и стандартизации словарей и онтологий, эта работа уже идет.
Если она уже идет — где выхлоп?
LP> К сожалению, идет очень медленно, поскольку производительные процессы кап. общества завязаны на прибыль, а прибыль разработчикам онтологий если и светит, то не в ближайшем будущем.
Ага, то есть пользы ноль целых, ноль десятых.
... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, LaPerouse, Вы писали:
LP>>Или множественным наследованием. AVK>А МН даже с приватным наследованием тянет за собой слишком много связей.
Приватное наследование это не то, что я имею ввиду. Каковая задача? Отделить наследование реализации от наследования интерфейсов. Просто множественное наследование не работает, так как приводит к наследованию и реализации, и интерфейсов. А если мы запретим клиентам использование получившегося от множественного наследования класса (приватный в модуле), то мы запретим использование его интерфейса. То есть получили наследование реализации в чистом виде, без наследования интерфейса.
Вот что у нас есть:
public interface Interface1
{
void foo1();
void bar1();
}
public interface Interface2
{
void foo2();
void bar2();
}
public class Impl1 implements Interface1
{
public void foo1() {/*foo1 impl*/}
public void bar1() {/*bar1 impl*/}
}
public class Impl2 implements Interface2
{
public void foo2() {/*foo2 impl*/}
public void bar2() {/*bar2 impl*/}
}
Множественное наследование, если бы оно было в java:
public class Impl extends Impl1, Impl2
{
}
В результате имеем, что Impl наследует реализации foo1, bar1, foo2, bar2 и интерфейсы Interface1 и Interface2. То есть наследует и интерфейс, и реализацию. Как этого избежать?
Вариант 1 — делегирование:
public class Impl
{
Impl1 impl1;
Impl2 impl2;
}
Теперь мы можем использовать реализацию impl1 и impl2 без наследования интерфейсов Interface1 и Interface2. Однако задача решена плохо. Если нам нужно к примеру, чтобы Impl реализовал интерфейс Interface1, нам нужно писать делегирующий код:
public class Impl implements Interface1
{
Impl1 impl1;
Impl2 impl2;
public void foo1() {impl1.foo()}
public void bar1() {impl2.bar()}
}
В этом плане делгирование не самый лучший вариант. Давай попробуем вернуться к варианту с множественным наследованием. Так ли он плох? Проблема в том, что Impl помимо реализации Impl1, Impl2 наследует их интерфейсы. Чего нам совершенно не нужно. Как этого избежать? Решение — работать с Impl не напрямую, а исключительно через некоторый публичный интерфейс Interface (сделав его невидным извне модуля например). Отнаследовав Interface от Interface1, переписываем пример выше:
public Interface extends Interface1
{
}
class Impl extends Impl1, Impl2 implements Interface
{
}
Тогда мы можем наследовать его от каких угодно классов, не опасаясь появления ненужных связей. То есть у нас будет отделение дерева наследования реалазиации от дерева наследования интерфейсов. Вообще, эта практика полезна даже в случае одиночного наследования.
Таким образом, множественное наследование при правильном его применении способно помочь в отделении наследования реализации от наследования интерфейсов, причем эффективнее, чем делегирование.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, AndrewVK, Вы писали:
AVK>Можно формализовать знания о методиках психоанализа? О том, какая мелодия понравится? Какое кино будет интересным?
Эти — не нужно.
LP>>Причина банальна: мало кто из авторов обладает по-настоящему экспертными знаниями в той области AVK>Не не не. Либо экспертная оценка, либо формализация. Это принципиально разные методы.
Экспертная оценка — это из другой оперы.
Формализация знаний должна производиться экспертами. См. экспертные системы.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
LP>А если мы запретим клиентам использование получившегося от множественного наследования класса (приватный в модуле), то мы запретим использование его интерфейса. То есть получили наследование реализации в чистом виде, без наследования интерфейса.
Только это уже не совсем МН будет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>
Здравствуйте, LaPerouse, Вы писали:
AVK>>Можно формализовать знания о методиках психоанализа? О том, какая мелодия понравится? Какое кино будет интересным?
LP>Эти — не нужно.
С ЯП очень похожая ситуация. По тем же самым причинам.
LP>Формализация знаний должна производиться экспертами. См. экспертные системы.
Эксперты существуют для того, чтобы получать оценку там, где формализацию обеспечить не выходит. Погляди на мои примеры — там как раз никакой формализации не получается, поэтому в этих областях используют экспертную оценку.
... << RSDN@Home 1.2.0 alpha 4 rev. 1466 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, LaPerouse, Вы писали:
AVK>>>Можно формализовать знания о методиках психоанализа? О том, какая мелодия понравится? Какое кино будет интересным? LP>>Эти — не нужно. AVK>С ЯП очень похожая ситуация. По тем же самым причинам.
Ты кажется подумал, что я предлагаю сделать какой-то ИИ для атвоматического программирования. Ничего подобного. Возьми любой учебник по программированию, выдели ключевые понятия, задай отношения между ними (субъет-предикат-объект), расставь семантические ссылки — вот пример базы знаний. Только на базе одного учебника и одного специалиста база знаний получится убогой. А теперь представь, что то же самое делается на обширном материале трудом десятков тысяч специалистов — получим полноценную базу знаний для соответствующей предметной области.
Таким образом можно формализовать любую предметную область и любые знания. Ключевое слово — знания. Мелодия и кино — чувства. Психоанализ — лженаука. Хотя отдельные утверждения из психоанализа, конечно, можно формализовать.
LP>>Формализация знаний должна производиться экспертами. См. экспертные системы.
AVK>Эксперты существуют для того, чтобы получать оценку там, где формализацию обеспечить не выходит. Погляди на мои примеры — там как раз никакой формализации не получается, поэтому в этих областях используют экспертную оценку.
Экспертная оценка и в самом деле не имеет никакого отношения к тому, о чем я говорю.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, LaPerouse, Вы писали:
LP>>А если мы запретим клиентам использование получившегося от множественного наследования класса (приватный в модуле), то мы запретим использование его интерфейса. То есть получили наследование реализации в чистом виде, без наследования интерфейса.
AVK>Только это уже не совсем МН будет.
Используется МН для наследования реализации.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, LaPerouse, Вы писали:
LP>>Используется МН для наследования реализации.
AVK>Только вот побочные эффекты от наследования интерфейса все равно остаются, хотя бы и внутри модуля.
У всего есть свои недостатки.
Разработчик модуля знает про свой модуль и сможет воздержаться от неподобающего использования своих классов.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
LP>Ты кажется подумал, что я предлагаю сделать какой-то ИИ для атвоматического программирования. Ничего подобного. Возьми любой учебник по программированию, выдели ключевые понятия, задай отношения между ними (субъет-предикат-объект), расставь семантические ссылки — вот пример базы знаний. Только на базе одного учебника и одного специалиста база знаний получится убогой. А теперь представь, что то же самое делается на обширном материале трудом десятков тысяч специалистов — получим полноценную базу знаний для соответствующей предметной области.
Что потом с этой базой делать? Как справочник-учебник по программированию?
Слышал какая-то контора уже лет 15 вбивает в продукционную систеу правила из всех областей. Точно не помню, но порядка нескольких миллионов правил уже. Какая-то чатилка есть в инете с этой системой. Но такие системы имеют отношение скорее не к промышленности, а к индустрии развлечений.
Здравствуйте, Silver_s, Вы писали:
S_>Здравствуйте, LaPerouse, Вы писали:
LP>>Ты кажется подумал, что я предлагаю сделать какой-то ИИ для атвоматического программирования. Ничего подобного. Возьми любой учебник по программированию, выдели ключевые понятия, задай отношения между ними (субъет-предикат-объект), расставь семантические ссылки — вот пример базы знаний. Только на базе одного учебника и одного специалиста база знаний получится убогой. А теперь представь, что то же самое делается на обширном материале трудом десятков тысяч специалистов — получим полноценную базу знаний для соответствующей предметной области.
S_> Что потом с этой базой делать? Как справочник-учебник по программированию?
Использовать как более хорошую википедию. С типизированными ссылками. С возможностью выполнять сложные запросы. Например: найти список языков программирования, поддерживающих множественное наследование, выпущенных после 1991 года. Но самое главное — иметь надежный стандартизованный источник знаний.
См. например Semantik Wiki
S_>Слышал какая-то контора уже лет 15 вбивает в продукционную систеу правила из всех областей. Точно не помню, но порядка нескольких миллионов правил уже. Какая-то чатилка есть в инете с этой системой. Но такие системы имеют отношение скорее не к промышленности, а к индустрии развлечений.
Тратить труд тысяч квалифицированных специалистов ради чатилки? Бред. Это явно не цель этого проекта.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, AndrewVK, Вы писали:
AVK>А МН даже с приватным наследованием тянет за собой слишком много связей.
Есть такая практика — не использовать МН для создания базовых классов, а только лишь для создания самого последнего наследника. ATL и STL используют эту же практику, вполне надежно выходит.
