А используете ли вы вышеозначенную методологию в разработке (неважно на каком языке, устроит и JS). Можно привести пример каких-нибудь реальных задач, решенных с ее помощью? Как потом поддерживается код/какие особенности при написании юнит-тестов/да и какие возникают проблемы в целом?
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А используете ли вы вышеозначенную методологию в разработке (неважно на каком языке, устроит и JS). Можно привести пример каких-нибудь реальных задач, решенных с ее помощью? Как потом поддерживается код/какие особенности при написании юнит-тестов/да и какие возникают проблемы в целом?
Только в прототипах на C#
Пишутся методы типа Create<Type>, где, по сути, создаются копии прототипа, и потом иногда эти копии чуть-чуть тюнятся. К сожалению, для реального применения слишком просто и не подходит.
Здравствуйте, Aen Sidhe, Вы писали:
AS>Пишутся методы типа Create<Type>, где, по сути, создаются копии прототипа, и потом иногда эти копии чуть-чуть тюнятся. К сожалению, для реального применения слишком просто и не подходит.
Меня собственно интересует больше механизм управления "дочерними" экземплярами через изменение или подмену прототипа. Механизм весьма мощный, но весьма располагающий к "взрывоопасным" спецэффектам. Мне вот интересно, реально ли кто пользуется "на все 100" тем же JS, и какие лекарства/техники при этом применяются.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, Aen Sidhe, Вы писали:
AS>>Пишутся методы типа Create<Type>, где, по сути, создаются копии прототипа, и потом иногда эти копии чуть-чуть тюнятся. К сожалению, для реального применения слишком просто и не подходит.
ВВ>Меня собственно интересует больше механизм управления "дочерними" экземплярами через изменение или подмену прототипа. Механизм весьма мощный, но весьма располагающий к "взрывоопасным" спецэффектам. Мне вот интересно, реально ли кто пользуется "на все 100" тем же JS, и какие лекарства/техники при этом применяются.
Нет, такое не применяю. Я сторонник — создал объект из прототипа, всё, изменениями прототипа изменений объекта не добиться.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, Aen Sidhe, Вы писали:
AS>>Пишутся методы типа Create<Type>, где, по сути, создаются копии прототипа, и потом иногда эти копии чуть-чуть тюнятся. К сожалению, для реального применения слишком просто и не подходит.
ВВ>Меня собственно интересует больше механизм управления "дочерними" экземплярами через изменение или подмену прототипа. Механизм весьма мощный, но весьма располагающий к "взрывоопасным" спецэффектам. Мне вот интересно, реально ли кто пользуется "на все 100" тем же JS, и какие лекарства/техники при этом применяются.
Я боюсь, что большинство кто пишет на JS, например, не мыслят в категории ООП
То есть фактически вся мощь не задействована. Так же как и в в классическом ООП наследование не есть ООП, а только средство. А ООП это способ построения модели задачи
Здравствуйте, Aen Sidhe, Вы писали:
AS>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Здравствуйте, Aen Sidhe, Вы писали:
AS>>>Пишутся методы типа Create<Type>, где, по сути, создаются копии прототипа, и потом иногда эти копии чуть-чуть тюнятся. К сожалению, для реального применения слишком просто и не подходит.
ВВ>>Меня собственно интересует больше механизм управления "дочерними" экземплярами через изменение или подмену прототипа. Механизм весьма мощный, но весьма располагающий к "взрывоопасным" спецэффектам. Мне вот интересно, реально ли кто пользуется "на все 100" тем же JS, и какие лекарства/техники при этом применяются.
AS>Нет, такое не применяю. Я сторонник — создал объект из прототипа, всё, изменениями прототипа изменений объекта не добиться.
Здравствуйте, Aen Sidhe, Вы писали:
AS>Нет, такое не применяю. Я сторонник — создал объект из прототипа, всё, изменениями прототипа изменений объекта не добиться.
Здравствуйте, Ведмедь, Вы писали:
В>Я боюсь, что большинство кто пишет на JS, например, не мыслят в категории ООП
Ну как сказать... Не раз видел попытки сымитировать на JS class based OOP, т.е. когда люди пытались тем или иным способом ввести в язык явное описание контрактов. Видел, как его использовали как функциональный язык — причем весьма часто. А вот более родной, казалось бы, механизм несколько уступает в популярности.
Здравствуйте, Воронков Василий, Вы писали:
AS>>Пишутся методы типа Create<Type>, где, по сути, создаются копии прототипа, и потом иногда эти копии чуть-чуть тюнятся. К сожалению, для реального применения слишком просто и не подходит.
ВВ>Меня собственно интересует больше механизм управления "дочерними" экземплярами через изменение или подмену прототипа. Механизм весьма мощный, но весьма располагающий к "взрывоопасным" спецэффектам. Мне вот интересно, реально ли кто пользуется "на все 100" тем же JS, и какие лекарства/техники при этом применяются.
То, что в javascript-е называют прототипами, в нормальных языка называется иначе. Имхо, ближе всего подходит паттерн "стратегия". Стратегии, да, используются часто. Но чтобы подменять стретегию в рантайме, не могу придумать для чего это может понадобиться.
Здравствуйте, Lloyd, Вы писали:
L>То, что в javascript-е называют прототипами, в нормальных языка называется иначе. Имхо, ближе всего подходит паттерн "стратегия". Стратегии, да, используются часто. Но чтобы подменять стретегию в рантайме, не могу придумать для чего это может понадобиться.
Вроде как P-OOP в JS совсем не уникально и его реализация примерно такая же, как и в других, может быть, менее массовых языках. Обычный P-OOP через delegation.
Здравствуйте, Воронков Василий, Вы писали:
L>>То, что в javascript-е называют прототипами, в нормальных языка называется иначе. Имхо, ближе всего подходит паттерн "стратегия". Стратегии, да, используются часто. Но чтобы подменять стретегию в рантайме, не могу придумать для чего это может понадобиться.
ВВ>Вроде как P-OOP в JS совсем не уникально и его реализация примерно такая же, как и в других, может быть, менее массовых языках. Обычный P-OOP через delegation.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, Ведмедь, Вы писали:
В>>Я боюсь, что большинство кто пишет на JS, например, не мыслят в категории ООП
ВВ>Ну как сказать... Не раз видел попытки сымитировать на JS class based OOP, т.е. когда люди пытались тем или иным способом ввести в язык явное описание контрактов. Видел, как его использовали как функциональный язык — причем весьма часто. А вот более родной, казалось бы, механизм несколько уступает в популярности.
JS и есть функциональный язык, функции в нём first class.
Плюс корни у него схемовские.
Здравствуйте, Lloyd, Вы писали:
L>>>То, что в javascript-е называют прототипами, в нормальных языка называется иначе. Имхо, ближе всего подходит паттерн "стратегия". Стратегии, да, используются часто. Но чтобы подменять стретегию в рантайме, не могу придумать для чего это может понадобиться.
ВВ>>Вроде как P-OOP в JS совсем не уникально и его реализация примерно такая же, как и в других, может быть, менее массовых языках. Обычный P-OOP через delegation.
L>Зачем? Юзкейс можешь привести?
Зачем что? Сам механизм delegation-a? Ну одно из самых очевидных преимуществ этой парадигмы в меньших требованиях к памяти — у нас фактически происходит даже не клонирования, а передача новому объекту всех слотов исходного, а новые слота создаются только при явной записи значений в них.
Юз-кейс подмены прототипа может быть такой же, как и у паттерна стратегия, а может быть и другой. Это механизмы разные, иногда позволяющие решать аналогичные задачи.
В JS ты можешь подменить прототип на лету для всех уже созданных объектов — это равносильно подмене реализации интерфейса по ходу исполнения метода и даже теоретически невозможно в статических языках.
Здравствуйте, Курилка, Вы писали:
К>JS и есть функциональный язык, функции в нём first class.
Предлагаю не начинать спор о том, что делает язык функциональным
В JS — по кр. мере до 1.8 — кроме функций как первоклассных объектов ничего больше и нет. Плюс стоимость вызова функций весьма высока, если императивный алгоритм переписать в функциональном стиле, то он будет раз в 5 медленнее. Все же очень многое в языка располагает к созданию побочных эффектов, причем зачастую просто чудовищных, и нет никаких средств для борьбы с "нечистотой". На мой взгляд в функциональном языке такие средства быть должны.
А если бы в нем не было функций как первоклассных объектов, то вообще в функциональном стиле писать было бы нельзя.
К>Плюс корни у него схемовские.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, Курилка, Вы писали:
К>>Плюс корни у него схемовские.
ВВ>Разве? Не вижу связи. Откуда такое мнение?
Например, и ещё отсюда (надеюсь достаточно говорящий адрес?):
ES3 is a simple, highly dynamic, object-based language that takes its major ideas from the languages Self
and Scheme. The programming style is a mixture of object-based and functional programming: The
primary abstraction mechanisms in ES3 are lexically scoped higher-order functions and mutable objects
whose prototype objects contain methods that are accessible through a delegation mechanism.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, Курилка, Вы писали:
К>>Например, и ещё отсюда (надеюсь достаточно говорящий адрес?):
ВВ>Адрес говорящий, но недоумение осталось. Можете привести что-либо такое, что явно сближает третью редакцию именно со Схемой?
Не понимаю почему именно 3-ю и "сближает"?
По-моему лямбд и замыканий уж достаточно.
А вообще утверждается, что Эйх должен был выл встроить Схему в браузер (ед. упоминание, что сходу нашёл — http://wapedia.mobi/ru/JavaScript ), только синтаксис побоялись давать широкой публике, ну и (есть подозрение, что) Сан удалось в том числе близостью к Java взять в союзники против МС.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Можно привести пример каких-нибудь реальных задач, решенных с ее помощью?
Достоточно часто.
Например некий widget у которого есть два и больше режима работы.
Скажем есть начальное состояние "загрузка" и "нормальная работа":
class LoadingState: Behavior
{
...
function onMouse(evt) { ... еще не работа но уже надо что-то делать ... ; }
function whenLoaded() { this.prototype = WorkingState; } // changing class of the object
}
class ReadyState: Behavior
{
...
function onMouse(evt) { ... нормальная обработка ... ; }
}
Если "загрузка" это потенциально длительный процесс то чтобы не городить кучу конструкций типа
if(loading) ... else ...;
используем динамическое переключение класса. Кода меньше получается и работает быстрее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>>>Вроде как P-OOP в JS совсем не уникально и его реализация примерно такая же, как и в других, может быть, менее массовых языках. Обычный P-OOP через delegation.
L>>Зачем? Юзкейс можешь привести?
ВВ>Зачем что? Сам механизм delegation-a? Ну одно из самых очевидных преимуществ этой парадигмы в меньших требованиях к памяти — у нас фактически происходит даже не клонирования, а передача новому объекту всех слотов исходного, а новые слота создаются только при явной записи значений в них.
Гм. А при записи полей прототипы разве работают? Я был уврен, что нет. Надо бы проверить
ВВ>Юз-кейс подмены прототипа может быть такой же, как и у паттерна стратегия, а может быть и другой. Это механизмы разные, иногда позволяющие решать аналогичные задачи. ВВ>В JS ты можешь подменить прототип на лету для всех уже созданных объектов — это равносильно подмене реализации интерфейса по ходу исполнения метода и даже теоретически невозможно в статических языках.
Ну почему сразу невозможно? Делегирование методов на синглтон + подмена стратегии синглтона.
Здравствуйте, Lloyd, Вы писали:
L>Гм. А при записи полей прототипы разве работают? Я был уврен, что нет. Надо бы проверить
В смысле "прототипы при записи полей"? Я описал механизм по которому работает P-OOP через delegation. Если ты создал новый объект по некому прототипу, то память под "поля" выделяться не будет до тех пор, пока ты явно не запишешь в них значения (этой создаст новый слот). Если ты просто читаешь — то будешь брат данные из слота прототипа.
ВВ>>Юз-кейс подмены прототипа может быть такой же, как и у паттерна стратегия, а может быть и другой. Это механизмы разные, иногда позволяющие решать аналогичные задачи. ВВ>>В JS ты можешь подменить прототип на лету для всех уже созданных объектов — это равносильно подмене реализации интерфейса по ходу исполнения метода и даже теоретически невозможно в статических языках. L>Ну почему сразу невозможно? Делегирование методов на синглтон + подмена стратегии синглтона.
В том-то и дело, что через синглтон, т.е. некий глобальный инстанс. Почувствуй разницу, как говорится.
Если я правильно понял пример, то того же самого можно добиться и без P-OOP, собственно, достаточно вынести разную логику в отдельные классы, а затем делегировать в них вызов.
Хотелось бы что-то более... характерное именно для P-OOP что ли.
Здравствуйте, Воронков Василий, Вы писали:
L>>Гм. А при записи полей прототипы разве работают? Я был уврен, что нет. Надо бы проверить
ВВ>В смысле "прототипы при записи полей"? Я описал механизм по которому работает P-OOP через delegation. Если ты создал новый объект по некому прототипу, то память под "поля" выделяться не будет до тех пор, пока ты явно не запишешь в них значения (этой создаст новый слот). Если ты просто читаешь — то будешь брат данные из слота прототипа.
Я просто не понял, откуда тогда берется экономия по памяти, поля-то де-факто не шарятся.
ВВ>>>Юз-кейс подмены прототипа может быть такой же, как и у паттерна стратегия, а может быть и другой. Это механизмы разные, иногда позволяющие решать аналогичные задачи. ВВ>>>В JS ты можешь подменить прототип на лету для всех уже созданных объектов — это равносильно подмене реализации интерфейса по ходу исполнения метода и даже теоретически невозможно в статических языках. L>>Ну почему сразу невозможно? Делегирование методов на синглтон + подмена стратегии синглтона.
ВВ>В том-то и дело, что через синглтон, т.е. некий глобальный инстанс. Почувствуй разницу, как говорится.
Ну дык, он по факту и в js будет глобальным инстансом, только синтаксис иной. В чем отличие-то?
Здравствуйте, Lloyd, Вы писали:
L>Я просто не понял, откуда тогда берется экономия по памяти, поля-то де-факто не шарятся.
Я тебе уже два раза пытался объяснить, что как раз поля, а вернее, слоты, шарятся.
ВВ>>В том-то и дело, что через синглтон, т.е. некий глобальный инстанс. Почувствуй разницу, как говорится. L>Ну дык, он по факту и в js будет глобальным инстансом, только синтаксис иной. В чем отличие-то?
Здравствуйте, Воронков Василий, Вы писали:
L>>Я просто не понял, откуда тогда берется экономия по памяти, поля-то де-факто не шарятся.
ВВ>Я тебе уже два раза пытался объяснить, что как раз поля, а вернее, слоты, шарятся.
Они шарятся на чтение. То же самое поведение мы получим, если будем использовать статические поля. Никакого выигрыша по памяти не будет.
ВВ>>>В том-то и дело, что через синглтон, т.е. некий глобальный инстанс. Почувствуй разницу, как говорится. L>>Ну дык, он по факту и в js будет глобальным инстансом, только синтаксис иной. В чем отличие-то?
ВВ>Что значит глобальным инстансом?
ВВ>var f = new Foo(); ВВ>f.prototype = new Bar();
ВВ>new Bar — это глобальный интанс?
Нее, раз речь идет о "подмене наследования", то уж будь добр, приведи пример с подменой наследования.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, c-smile, Вы писали:
ВВ>Если я правильно понял пример, то того же самого можно добиться и без P-OOP, собственно, достаточно вынести разную логику в отдельные классы, а затем делегировать в них вызов.
Ну дык это все надо руками делать. А тут оно out of the box что называется.
ВВ>Хотелось бы что-то более... характерное именно для P-OOP что ли.
По-моему самое что ни на есть характерное.
Такой прием имеет смысл использовать именно когда есть объект который пребывает в двух сильно разных состояниях.
Здравствуйте, c-smile, Вы писали:
ВВ>>Хотелось бы что-то более... характерное именно для P-OOP что ли. CS>По-моему самое что ни на есть характерное. CS>Такой прием имеет смысл использовать именно когда есть объект который пребывает в двух сильно разных состояниях.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А используете ли вы вышеозначенную методологию в разработке (неважно на каком языке, устроит и JS).
Кстати, чтобы было понятно откуда "ноги растут", про теорию прототипа приведу цитату из моей книги про онтологии:
Мы пока не выясняли, что конкретно представляют собой отличительные особенности, на основе которых вещи объединяются в классы, каков механизм сопоставления вещи ее типу и какова вообще структура типа. Ответ на этот вопрос также был предложен еще Аристотелем. Согласно Аристотелю, каждому типу соответствует набор его специфических свойств (признаков или атрибутов). Атрибуты представляют собой различные характеристики вещи, важные в данном контексте рассмотрения. Атрибуты делятся на существенные и несущественные. Существенные атрибуты -- это такие свойства вещи, которые позволяют определить, к какому классу принадлежит данная вещь, т.е. отличительные свойства данного типа. Несущественные атрибуты -- это свойства, которые имеют все вещи данного типа, но которые не участвуют в соотнесении вещи данному классу. Например, для понятия <<яблоко>> существенными свойствами будут: плод (происхождение), круглый (форма), вкус (нечто общее для всех яблок) и некоторые другие. Несущественными свойствами будут цвет (яблоки бывают разных цветов), размер (есть райские яблоки, похожие на ягоды) вес и другие. Популярный в настоящее время объектно ориентированный подход к программированию также построен на аристотелевской традиции. Например, в языке программирования C++ типы задаются с помощью ключевого слова class, за которым идет перечисление типов и имен атрибутов класса, а также его методов. Конкретный экземпляр данного класса содержит конкретные значения свойств"~атрибутов и фактически представляет собой не что иное, как совокупность своих свойств. Здесь следует отметить, что существенные свойства типа в конструкции класса языка C++ не задаются, так как всегда имеют одни и те же значения для всех экземпляров класса. Эти значения содержатся во всех классах в качестве фиксированных значений соответствующих атрибутов родительского класса. Аристотелевская традиция задания типов вещей является в наше время основной, но существуют также и принципиально иные подходы для задания типов.
В 70"~х годах прошлого века в когнитивной семантике был предложен другой подход. Его автором считается Элеонора Рош (Eleanor Rosch) -- профессор психологии из Бэркли (Калифорния). Теория, описывающая данный подход к различению понятий, называется теория прототипа. Основная идея этой теории основывается на предположении, что каждый тип имеет по крайней мере одного характерного представителя, который называется прототипом данного понятия. Тогда, принадлежит или нет данная вещь данному типу, можно проверить степенью похожести этой вещи на прототип данного типа. Конечно, для каждого понятия еще надо выделить его прототип и большая проблема определить, является ли данная вещь типичным представителем данного типа или нет. Рош предлагает следующие признаки того, что данная вещь является прототипом понятия:
1. Время ответа. Время ответа на задание <<назвать вещи данного типа>> гораздо быстрее для прототипа данного понятия, чем для нетипичных элементов.
2. Предварительное связывание. Если предварительно связать субъекта с некоторым понятием более высокого уровня, то распознавание того, что два слова являются одинаковыми, происходит быстрее. Например, если сначала показать табличку с надписью "инструмент", то распознавание того, что на двух далее показанных табличках написано одно и то же слово "молоток", будет происходить существенно быстрее, чем распознавание слова "дробилка".
3. Экземпляры. Если попросить интервьюируемого назвать несколько экземпляров некоторого понятия, то прототипы будут называться чаще.
Наверняка читатель играл в такую игру. Загадывающий предварительно записывает на бумаге три слова, а затем просит партнера начать обратный отсчет от ста. Дождавшись момента, когда партнер отвлечется на счет, загадывающий просит:
1. Назвать любого поэта.
2. Назвать любой плод.
3. Назвать любой инструмент.
После того как партнер делает это, загадывающий торжествующе показывает записанные им предварительно на бумаге ответы: "Пушкин", "яблоко" и "молоток". Очевидно, что на самом деле таким образом выделяются прототипы соответствующих понятий.
В отличие от аристотелевского подхода, в котором все экземпляры класса представляются равноценными, в теории прототипа имеется мера соответствия экземпляра классу. Очевидно, что наиболее близкими к классу экземплярами являются прототипы. Эти экземпляры располагаются "центре" понятия. Другие экземпляры располагаются "чуть дальше". Понятие может иметь несколько почти равноценных прототипов. Например, в качестве прототипа понятия "поэт" может выступать также и экземпляр "Лермонтов", а для представления понятия "плод" можно использовать и "абрикос". Меру принадлежности экземпляра данному классу можно оценить сходством данного экземпляра с прототипом класса понятия. Оказывается, как мы увидим чуть позже, мера соответствия экземпляра классу этого экземпляра является метрикой, т.е. удовлетворяет всем формальным свойствам, предъявляемым к математическому определению функции метрики.
Другим новым подходом, связанным с теорией прототипа и также предложенным Рош, является метод, основанный на так называемых понятиях базового уровня. Такие понятия задаются в иерархии типов и обычно связаны с какими-нибудь моторными или сенсорными действиями. Например, на вопрос "На чем Вы сидите?" обычно отвечают: "на стуле", а не "на офисном кресле", "кухонном стуле" или просто "на мебели". Стул как понятие связан с его основной моторной функцией -- сгибанием ног в коленях. Кроме того, стул -- это наиболее высокое по уровню понятие, которое можно нарисовать. Для следующего по уровню понятия "мебель" этого сделать уже невозможно. Для традиции, которая основана на аристотелевском понимании типа как совокупности пар атрибут-значение, выделить на этом основании понятия базового уровня затруднительно. Функционально можно сказать, что понятия базового уровня представляют собой декомпозицию реальности на максимально информативные категории. Следовательно, они:
1. Максимизируют число атрибутов, которые имеют все представители данного понятия.
2. Минимизируют число атрибутов, которые имеют все представители других понятий.
Теорию прототипа можно представить и формально следующим образом. Для каждого понятия c выделяется его прототип p и задается специальная функция d(x,y,c) -- семантическое расстояние объекта x от объекта y, если рассматривать их как представителей типа c. Тогда объект x можно классифицировать следующей рекурсивной процедурой:
1. Предположим, что объект x уже был распознан как экземпляр типа c, который имеет подтипы s_1, s_2, ..., s_n.
2. Для каждого подтипа s_i измеряем семантическое расстояние d(x,p_i,c), где p_i -- представитель подтипа s_i.
3. Если среди всех таких семантических расстояний d(x,p_i,c) имеется величина, которая строго меньше всех остальных (уникальный минимум), то полагаем c=s_i и начинаем заново.
4. Если среди всех таких семантических расстояний d(x,p_i,c) не имеется величины, которая строго меньше всех остальных, то процесс классификации останавливается и считается, что объект x имеет тип c.
Например, рассмотрим два объекта: "черная кошка" и "рыжая кошка". В классе "Животные" эти два объекта очень похожи и почти не различаются, но в классе "Кошки" различие между этими объектами уже более значимо, т.к. объекты имеют все признаки, характерные для кошек. С другой стороны, если рассматривать тип "Черный объект", то в нем объект "черная кошка" будет больше походить на объект "ворона" или на объект "кусок угля", нежели на объект "рыжая кошка". Ввиду того, что описанный способ различения понятий основан на конкретных примерах, функцию семантического расстояния можно также определить исходя из таких примеров. По этой причине, такое определение типов особенно популярно в различных, основанных на статистике приложениях, таких, как кластерный анализ и нейронные сети.
В 2000 году была издана книга "Понятийные пространства" профессора университета Лунд (Швеция) Питера Гарденфорса. В этой книге Гарденфорс предложил использовать геометрический подход к представлению понятий. В этом подходе свойства понятий представляются в виде размерностей понятийного пространства, получаемого декартовым произведением свойств и снабженным определенной метрикой. Каждое понятие представляет собой выпуклую область пространства. Конкретные экземпляры понятия представляются в виде точек данной области. Между экземплярами определено расстояние, которое в предыдущем параграфе мы назвали "семантическим". Некоторые свойства связаны друг с другом, т.е. в человеческом сознании неотделимы друг от друга. Например, такие свойства цвета, как цветность, яркость и насыщенность, являются неотделимыми. Гарденфорс объединяет такие свойства в собственные пространства, называемые доменами (domains). Объединение свойств в домены чрезвычайно важно для правильного моделирования человеческого мышления, т.к. разделение свойств, которые являются в человеческом сознании неотделимыми друг от друга, приводит к некорректным моделям. Гарденфорс выделяет три уровня представления процесса человеческого мышления:
1. Базовый уровень, на котором рассматриваются биологические механизмы, обеспечивающие возможность мышления. Эти механизмы обычно моделируются посредством так называемых "нейронных сетей".
2. Геометрический уровень, на котором мышление представляется уже с помощью понятий, т.е. описанным выше способом. Но геометрия понятийных пространств такова, что связанные между собой свойства неотделимы друг от друга и на этом уровне представления.
3. Символьный уровень, на котором понятия и их свойства описываются с помощью символьных выражений, а связи между свойствами и понятиями задаются с помощью ограничивающих утверждений (аксиом).
Все три уровня представления связаны между собой и каждый используется для своих целей. Для объяснения этих связей, Гарденфорс использует метафору "джунглей". Предположим, что путник оказывается в джунглях, при этом ему неизвестен дальнейший путь. Он расспрашивает аборигена и тот ему объясняет дальнейший путь следующим образом: "пройдешь триста шагов прямо, потом свернешь направо и пройдешь еще двести шагов, после чего поворачивай налево и иди до тех пор, пока не попадешь на шоссе". В данной ситуации это объяснение является наилучшим способом донести информацию о пути к шоссе и это представление пути соответствует базовому уровню. Но предположим, что путь до шоссе слишком длинный и требует многих поворотов, запоминания количеств шагов и т.п. вещей. В этом случае подобное объяснение не годится, т.к. просто запутает путника еще больше. Необходимо дать путнику значимые ориентиры. Иначе говоря, хорошее описание пути до шоссе в этом случае выглядело бы примерно так: "иди прямо, пока не встретишь баобаб с дуплом чуть ниже моего роста, затем поверни направо и иди до берега реки, а по нему иди влево до тех пор, пока не встретишь грунтовую дорогу, вот по ней свернешь направо и дойдешь до шоссе". Это представление пути соответствует геометрическому уровню, здесь уже встречаются понятия (баобаб, река, дорога), но они связаны между собой, привязаны к джунглям естественным образом (нахождением в них). Если бы у путника была карта, то единственное, что было бы ему необходимо от аборигена, это указание на карте места, где в данный момент путник находится, и направление сторон света. Этого было бы достаточно, чтобы путник сам отыскал дорогу к шоссе. Карта соответствует символьному уровню представления. На карте местность четко размечена в соответствии с масштабом карты, выделены примечательные для данной местности области, этим областям даны имена и т.д.
Не вижу связи. Откуда такое мнение?
