Здравствуйте, merhalak. Так получилось, что только сейчас увидел Ваш комментарий. Спасибо за замечание. Исправление внесено вот в таком виде (все что ниже — это правка)
«что это всего лишь одна из возможных реализаций, которая не может реализовать всю акторную модель в „полном объеме“.
Действительно, в phd диссертации Foundations of Actor Semantics William Duglas Clinger (ученик Карла Хьюита) показывает, что акторная модель обладает неограниченным недетерминизмом, в то время как машина Тьюринга является ограниченно недетерминированной. Из этого он и Карл Хьюит делают вывод, что существуют алгоритмы, которые можно реализовать в акторной модели, но нельзя реализовать на машине Тьюринга. Поэтому любая попытка реализации акторной модели на „обычных“ компьютерах, реализующих вычислимость по Тьюрингу, приведет к тому, что будет реализован лишь частный случай акторной модели.»
До Вашего комментария не думал как-то в сторону групп. У меня хоть и есть примеры, где речь идет об отделах или проектных командах, но в них группа людей не рассматривается как единое целое, а просто как множество людей с преобладающими типажами. К сожалению, я таких исследований не знаю, но присоединяюсь к Вам — тоже хотел бы познакомиться.
Что касается разных фигур, то в данной модели это плюс. Именно этот факт позволяет быстро идентифицировать тип личности. Я пользуюсь обычно таким алгоритмом:
Сначала определяю ролевую функцию — она обычно сразу бросается в глаза.
Затем просто слушаю человека, как аргументирует свои действия. Так выявляется функция — средство достижения цели.
После этого оставшиеся два знака определяются автоматически.
Важный факт, что то как человека воспринимают окружающие не всегда то, кем он является на самом деле, объясняет, почему так трудно идентифицировать человека в других типологиях. Например, меня часто определяют как администратора (квадрата), хотя я на самом деле круг по цели.
нет противоречия: по данной типологии я — круг: для меня важны отношения с окружающими, еще круги умеют подстраиваться под окружающих, моя функция достижения цели — зиг-заг, поэтому данная типология для меня инструмент, который позволяет лучше понимать других, их мотивы и поступки, и на основе этого генерировать идеи. Именно, поэтому, например, мне эта типология кажется важной
Типология — это модель. Естественно, что любая модель будет гораздо проще, чем реальная жизнь. Тем, не менее, существует масса различных типологий, в том числе и психогеометрическая. У той типологии, что я описал можно найти общие черты с типологией Адизеса по стилям руководства — там тоже всего 16 типов.
Мне нравится именно функциональная, потому что она позволяет быстро и с высокой точностью отнести человека к определенному типу. Классифицировать же человека по типологии Адизеса и по многим другим гораздо сложнее.
Вам не понравился стиль изложения или сам идея? Если изложение, то согласен с Вами — сам остался недоволен то, как получилось. Если сама типология, что Вас в ней смущает?
Структура понятная, но рано или поздно попадается задача, которая может быть отнесена как к модулю 11, так и к модулю 12. Кроме того, при такой структуре не так уж и просто понять где и какие задачи уже сделаны, а какие еще нет.
Я нигде и не пытался сказать, что декомпозиция плохо. Я лишь отметил, что большинство наших пользователей испытывают трудности при проведении этой самой декомпозиции. Причем трудности настолько большие, что им проще отказаться от разбиения задачи на более мелкие и перейти к плоскому списку задач. Причем, я привел пример, что это не только с системами управления задач такое происходит, но и, например, при работе с файловой системой.
При этом вижу по результатам опроса, что большинство все же пользуется иерархией задач. Пока, что приходит в голову, что, возможно, нужна не иерархия в общем виде, а какие-то ее частные случаи: например, ограничение глубины, чек-листы, что-нибудь еще.
На более простых словах это можно описать так — все классы, функции и т.д. должны проектироваться так, чтобы для изменения их поведения, нам не нужно было изменять их исходный код.
Во-первых, не все программные сущности. 100% расширяемости достичь невозможно, поэтому замкнутость должна быть стратегической. Об этом написано у Uncle Bob. То есть программист заранее должен позаботиться и спроектировать свою программу так, чтобы она была расширяема только для определенного вида изменений.
Во-вторых, так интерпретировать OCP не совсем корректно. OCP говорит не об изменении поведения конкретного класса или функции, а добавлении нового поведения в программу. Например, если у нас уже есть класс, интерфейс которого не устраивает, то чтобы не нарушить OCP принцип, мы можем сделать для него адаптер с новым интерфейсом, при этом старый класс останется без изменения.
Я имею в виду, что наследование в С++ не является субклассированием в терминах Лисков.
Наследник дополняет предка своими членами-данными и новыми функциями, переопределяет виртуальные функции (в этом месте соблюдение контрактов и следование LSP — личная ответственность программиста, а язык ему лишь помогает) и перегружает и прячет невиртуальные функции. В том числе, оператор присваивания.
…
Поэтому — или LSP, или вся полнота возможностей языка. Верёвка заряжена разрывными.
Отвечу Вам словами Бьярна Страуструпа: "должна быть предоставлена возможность описать ожидаемое поведение объекта базового класса таким образом, чтобы можно было составить программу, ничего не зная о производном классе. " (Язык программирования С++. Специальное издание Глава 24. Проектирование и программирование. 24.3 Классы стр. 813). Автор C++ за LSP!
Срезка — это расплата за возможность работать с объектами по значению. "Этот эффект часто называют срезкой; он приводит к ошибкам и чреват сюрпризами. Одной из причин передачи указателей и ссылок на объекты в иерархии является желание избежать срезки." (Страуструп, Язык С++. Специальное издание. Глава 12. Производные классы. 12.2.3. Копирование стр. 355) Так что LSP еще одно подтверждение, что срезку стоит избегать.
Язык здесь не препятствует возможным нарушениям LSP, а заодно затрудняет его соблюдение.
Пример с квадратом и прямоугольником показывает, что нарушить LSP можно в любом ОО языке программирования, не вдаваясь в особенности синтаксиса.
LSP, если сравнивать со естественным языком, это одно из правил грамматики, которое накладывает ограничение на совместное использование слов (классов). Человек может писать с ошибками, игнорируя или просто не зная правила, и язык ему в этом воспрепятствовать никак не сможет.
(Чтобы соблюсти, — возможно, придётся в операторе присваивания сделать вызов виртуальной функции — фактического обработчика присваиваний; а это громоздко).
Насчет виртуальных функций в операторе присваивания — был такой прием — двойная диспетчеризация — это как то, о чем Вы пишите.
Ваш пример только подтверждает мысль, которую я озвучил в статье
Еще одно важное наблюдение — невозможно по самим абстракциям определить насколько удачными они получились. Это можно сделать, только если мы попытаемся их использовать на практике. И тут уж выясняется, что одни абстракции лучше подходят для задачи, а другие — хуже. А если еще немного изменить исходные условия, то и прежний «хороший» набор абстракций уже может не работать.
Только Вы идете от обратного — если немного изменить исходные условия, то «плохие» абстракции могут вполне работать.
Неужели этого не понимают (студенты)? Абстрагирование — понятие изначально из философии, появление аналогичного термина в ООП наводит на мысль, что неспроста: ).
К сожалению, не только студенты. Содержание курса философии и оценка тех или иных вещей сильно зависит от того, каких взглядов придерживается лектор. У нас, например, лекции начинал читать идеалист, а заканчивал читать ярый марксист. Надо сказать — тот еще коктейль получился. Но про абстракции речи не было.
Каждый читатель уныло отмечает: «Да, потому что так надо», откровения не происходит. Но Вы — не первый, так что всё нормально: ).
Но это не значит, то не надо пытаться.
P.S.: Жаль, что моя статья ничем Вам не помогла. Буду работать на улучшениями дальше
«что это всего лишь одна из возможных реализаций, которая не может реализовать всю акторную модель в „полном объеме“.
Действительно, в phd диссертации Foundations of Actor Semantics William Duglas Clinger (ученик Карла Хьюита) показывает, что акторная модель обладает неограниченным недетерминизмом, в то время как машина Тьюринга является ограниченно недетерминированной. Из этого он и Карл Хьюит делают вывод, что существуют алгоритмы, которые можно реализовать в акторной модели, но нельзя реализовать на машине Тьюринга. Поэтому любая попытка реализации акторной модели на „обычных“ компьютерах, реализующих вычислимость по Тьюрингу, приведет к тому, что будет реализован лишь частный случай акторной модели.»
Что касается разных фигур, то в данной модели это плюс. Именно этот факт позволяет быстро идентифицировать тип личности. Я пользуюсь обычно таким алгоритмом:
Сначала определяю ролевую функцию — она обычно сразу бросается в глаза.
Затем просто слушаю человека, как аргументирует свои действия. Так выявляется функция — средство достижения цели.
После этого оставшиеся два знака определяются автоматически.
Важный факт, что то как человека воспринимают окружающие не всегда то, кем он является на самом деле, объясняет, почему так трудно идентифицировать человека в других типологиях. Например, меня часто определяют как администратора (квадрата), хотя я на самом деле круг по цели.
Мне нравится именно функциональная, потому что она позволяет быстро и с высокой точностью отнести человека к определенному типу. Классифицировать же человека по типологии Адизеса и по многим другим гораздо сложнее.
При этом вижу по результатам опроса, что большинство все же пользуется иерархией задач. Пока, что приходит в голову, что, возможно, нужна не иерархия в общем виде, а какие-то ее частные случаи: например, ограничение глубины, чек-листы, что-нибудь еще.
Во-первых, не все программные сущности. 100% расширяемости достичь невозможно, поэтому замкнутость должна быть стратегической. Об этом написано у Uncle Bob. То есть программист заранее должен позаботиться и спроектировать свою программу так, чтобы она была расширяема только для определенного вида изменений.
Во-вторых, так интерпретировать OCP не совсем корректно. OCP говорит не об изменении поведения конкретного класса или функции, а добавлении нового поведения в программу. Например, если у нас уже есть класс, интерфейс которого не устраивает, то чтобы не нарушить OCP принцип, мы можем сделать для него адаптер с новым интерфейсом, при этом старый класс останется без изменения.
По заголовку
сразу вспомнил про Словарь ненормативной лексики программиста от Ашманова. Не читали? У Вас получилось неплохое дополнение.
Отвечу Вам словами Бьярна Страуструпа: "должна быть предоставлена возможность описать ожидаемое поведение объекта базового класса таким образом, чтобы можно было составить программу, ничего не зная о производном классе. " (Язык программирования С++. Специальное издание Глава 24. Проектирование и программирование. 24.3 Классы стр. 813). Автор C++ за LSP!
Срезка — это расплата за возможность работать с объектами по значению. "Этот эффект часто называют срезкой; он приводит к ошибкам и чреват сюрпризами. Одной из причин передачи указателей и ссылок на объекты в иерархии является желание избежать срезки." (Страуструп, Язык С++. Специальное издание. Глава 12. Производные классы. 12.2.3. Копирование стр. 355) Так что LSP еще одно подтверждение, что срезку стоит избегать.
Пример с квадратом и прямоугольником показывает, что нарушить LSP можно в любом ОО языке программирования, не вдаваясь в особенности синтаксиса.
LSP, если сравнивать со естественным языком, это одно из правил грамматики, которое накладывает ограничение на совместное использование слов (классов). Человек может писать с ошибками, игнорируя или просто не зная правила, и язык ему в этом воспрепятствовать никак не сможет.
Насчет виртуальных функций в операторе присваивания — был такой прием — двойная диспетчеризация — это как то, о чем Вы пишите.
Только Вы идете от обратного — если немного изменить исходные условия, то «плохие» абстракции могут вполне работать.
К сожалению, не только студенты. Содержание курса философии и оценка тех или иных вещей сильно зависит от того, каких взглядов придерживается лектор. У нас, например, лекции начинал читать идеалист, а заканчивал читать ярый марксист. Надо сказать — тот еще коктейль получился. Но про абстракции речи не было.
Но это не значит, то не надо пытаться.
P.S.: Жаль, что моя статья ничем Вам не помогла. Буду работать на улучшениями дальше