Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 555
Перечень схожих черт Аристотель назвал типом. А объект, обладающий этими чертами, — экземпляром данного типа.
Вы можете дать конкретную цитату из Аристотеля, где вводятся эти термины?
Да, в книгах, что я привел, есть ссылки на Аристотеля.
Сколько проблем только из-за того, что в джаве/плюсах/шарпе классы не являются объектами.
Какая-то сумбурная статья получилось. Видно, что у автора накипело :) Но в статье как-то очень мало описано о «надеждах и разочарованиях» ООП, ожидал увидеть больше конкретики, а не то, что термины употребляются не правильно.
Если автор предлагает использовать в качестве классов теорию множеств, то спешу его предупредить, что она довольно ограничена Парадокс Рассела и попытки решить ее привели к созданию теории категорий.
Если автор предлагает использовать в качестве классов теорию множеств, то спешу его предупредить, что она довольно ограничена Парадокс Рассела и попытки решить ее привели к созданию теории категорий.
Поэтому в ООП нет даже простейших операций над классами (сложение и вычитание множеств)Эту задачу в терминах ООП можно решить при помощи костылей, но если хочется красивого решения, то почитайте про ADT. Они позволяют то, что вы хотите: создавать типы из других типов используя операции логического сложения и произведения. О том как это реазиловать в ООП можно почитать тут
Спасибо за ссылки! Вопрос не в том, как решать эти задачи. Их решить можно. Вопрос в том, что ООП плохо подходит для моделирования предметной области, куда его пытаются запихнуть. А. если и подходит, то с терминами тип, а не класс.
Теперь про парадокс Рассела. Термин Класс отличается от термина Множество тем, что класс определяется в аксиоматике фон Неймана. И эта аксиоматика была создана для разрешения этого парадокса. Однако, в нашем случае до парадоксов Рассела как до звезды)).
Теперь про парадокс Рассела. Термин Класс отличается от термина Множество тем, что класс определяется в аксиоматике фон Неймана. И эта аксиоматика была создана для разрешения этого парадокса. Однако, в нашем случае до парадоксов Рассела как до звезды)).
Кроме того, в бизнес-анализе сейчас распространены другие некорректные пары терминов: событие и экземпляр этого события, процесс и экземпляр этого процесса, договор и экземпляр этого договора. В русском языке нет такого понятия как объект и экземпляр этого объекта. Есть термины тип объекта и экземпляр этого типа объекта.
Возможно, ошибочное употребление терминов возникло из-за неверного перевода термина instance с английского языка. Instance переводится как пример, или как случай, но он не переводится как экземпляр.
Простите, но кому и зачем нужно использовать в программировании термины на русском языке? 1C'нишков не берем, у них своя песочница. Я НИКОГДА не встречал использование русскоязычных переводов instance и event, это не имеет никакого смысла.
Деление на классы и объекты классов позволяет мне рассматривать любые объекты исследуемого класса, например, класса слонов (изучать продолжительность жизни любого из слонов, длину его бивней на различных этапах его жизни), а также — класс слонов (изучать среднюю длительность жизни слонов, средний рост и средний вес). Понятно, что любой слон класса не может «знать» информацию о средней длительности жизни всех слонов. Эту информацию «знает» только класс слонов. Попробуйте в парадигме Аристотеля придумать тот объект, который «знает» о среднем количестве событий в год, не используя при этом термин множество! Навряд ли у вас это получится.
Возможно вы удивитесь, но это называется статические поля и методы класса. При создании класса слонов сохраняем кол-во всех слонов, сумму длительности жизни, роста, веса всех слонов в статические поля и после получаем все средние величины. Вывод класс в ООП это одновременно и класс множеств и тип.
Простите, но кому и зачем нужно использовать в программировании термины на русском языке
Я не говорил про программирование. Я говорил про моделирование предметной области.
Возможно вы удивитесь, но это называется статические поля и методы класса
В предметной области нет переменных
Я не говорил про программирование. Я говорил про моделирование предметной области.
Если вы говорите про моделирование предметной области как часть аналитической деятельности, то ООП к ней неприменимо, следовательно вся ваша статья написана на пустом месте.
А если вы говорите о моделировании предметной области как части деятельности по разработке, то это как раз программирование, и вы о нем и говорите.
Я разделяю код и реальность. В реальности есть слоны и классы слонов. Есть классы в программе. Классы слонов описываются при помощи логической парадигмы. Типы слонов описываются при помощи типов. Но код описывается при помощи классов ООП, Классы ООП не имеют прямой связи с классами реальных объектов. Эта связь только у аналитика в голове. Поэтому в природе нет переменных, нет классов ООП, но есть классы объектов, объектов из атомов. А те объекты, которые создаются в системе — они из электромагнитных полей. Это разные объекты
… и как все это связано с тезисом «Простите, но кому и зачем нужно использовать в программировании термины на русском языке»?
Мы не в программировании находимся. Программисты пользуются исследованиями, сделанными аналитиком. А аналитик работает в предметной области и его модели в идеале не должны зависеть от той платформы, на которой будет писаться код. Есть две модели: концептуальная, (она вообще не про программирование) и физическая (вот она про код). Между ними (моделями) есть связь, о которой говорят много и много ее изучают, но эти модели разные
Если вы находитесь не в программировании, не говорите об ООП.
Я думаю вы не понимаете, о чем говорит maxstroy. Он рассматривает описание сущностей мира и их взаимосвязей с аналитической точки зрения, что дает основания для постановки задач программисту, который описывает кодом отражение этих сущностей в программе.
Строго говоря, получив такое формализованное описание — программу можно писать на любом языке, не важно есть в нем ООП или нет — должна получиться та же семантика, различия только в синтаксисе конкретного языка. Однако из-за того что в ООП концепции спутаны — это не так, и способ выражения накладывает ограничения на выражаемое, чего, очевидно, не должно быть.
Я знаю что ООП для многих пользователей этого сайта является священной коровой, которую трогать нельзя. Не уподобляйтесь таким людям.
Строго говоря, получив такое формализованное описание — программу можно писать на любом языке, не важно есть в нем ООП или нет — должна получиться та же семантика, различия только в синтаксисе конкретного языка. Однако из-за того что в ООП концепции спутаны — это не так, и способ выражения накладывает ограничения на выражаемое, чего, очевидно, не должно быть.
Я знаю что ООП для многих пользователей этого сайта является священной коровой, которую трогать нельзя. Не уподобляйтесь таким людям.
В ООП концепции не спутаны, в ООП концепции отличаются от тех, которые нужны maxstroy.
И да, я прекрасно понимаю, что такое «логическая модель сущностей», и какая от нее польза. И ее прелесть как раз в том, что она не зависит от реализации — в том числе, ее можно реализовывать в рамках функциональной парадигмы, и не думать о каких-то там проблемах ООП.
И да, я прекрасно понимаю, что такое «логическая модель сущностей», и какая от нее польза. И ее прелесть как раз в том, что она не зависит от реализации — в том числе, ее можно реализовывать в рамках функциональной парадигмы, и не думать о каких-то там проблемах ООП.
Мне, как программисту, было бы проще работать, если бы концепции программирования были возможно ближе к концепциям описания модели. Если этого нет начинается попытки натянуть жабу на глобус и прочие костыли
Мне тоже. Но тут проблема возникает в том, что это двунаправленное движение — концепции программирования движутся к описанию, но и описание движется к программированию. Это внезапно приводит к тому, что описание не удается сохранить независимым от реализации, и она начинает влиять сначала на описание, а потом и на бизнес-процесс.
А сделать такую концепцию описания, чтобы она идеально подходила для любой задачи, при этом не была избыточно абстрактной, но и не пахла реализацией — это и правда Святой Грааль. Прекрасный и недостижимый.
А сделать такую концепцию описания, чтобы она идеально подходила для любой задачи, при этом не была избыточно абстрактной, но и не пахла реализацией — это и правда Святой Грааль. Прекрасный и недостижимый.
Мне, как программисту, было бы проще работать, если бы концепции программирования были возможно ближе к концепциям описания модели.
Вот и я об этом же habrahabr.ru/post/249193/
Мне кажется, в такой постановке вопроса и с спорить не о чем.
Мы же не пишем 100% кода на ассемблере или на процедурном C,
а используем объектные C++, Java, C# и т.д.
Почему бы не продвинуться вперед, и концепции и средства разработки не поднять на уровень еще выше — чтобы они соответствовали концепциям и средствам описания модели предметной области.
Программист просит меня описать нечто. Я даю ему описание. А потом он приходит ко мне и говорит: я создал класс такой-то. Я должен уметь перевести на язык русский: он создал тип объектов, которые будут созданы в системе, и выглядеть эти объекты будут так.
Плохой программист, негодный. Зачем он вам это говорит?
А по мне, так создание класса(ов) без двусторонней связи разработки с аналитикой, вообще порочный путь.
в процессе проектирования\разработки (проектирование > разработка > анализ > проектирование и т.д.) нужно признать несколько вещей:
Самое главное, чтобы здесь и сейчас ваша идея, в чем бы она не состояла, работала, а её возможная интеграция в смежные предметные области проверяется временем.
Предполагаю, что вы сейчас скажете, что такой подход некорректен для разработки ПО, где нельзя взвалить роль аналитика на обычного разработчика (или даже ведущего). С одной стороны не спорю, с другой стороны предполагаю, что в таких проектах желательно привлекать специалистов соответствующего уровня
в процессе проектирования\разработки (проектирование > разработка > анализ > проектирование и т.д.) нужно признать несколько вещей:
- Идеал недостижим (о чем уже было сказано в этом трэде), надо сосредоточиться на выборе и использовании наиболее эффективных инструментов в вашей задаче
- Один программист\команда разработки в силу субъективности своего мышления в процессе работы как правило пишет ущербный код, который непрерывно дописывается и улучшается
Самое главное, чтобы здесь и сейчас ваша идея, в чем бы она не состояла, работала, а её возможная интеграция в смежные предметные области проверяется временем.
Предполагаю, что вы сейчас скажете, что такой подход некорректен для разработки ПО, где нельзя взвалить роль аналитика на обычного разработчика (или даже ведущего). С одной стороны не спорю, с другой стороны предполагаю, что в таких проектах желательно привлекать специалистов соответствующего уровня
Я с вами согласен. Команда — есть команда. роли в команде лишь условные. Разговор с оппонентом меня вывел на столь ортодоксальный вывод только потому, что оппоненту надо было докопаться, в чем же собственно роль аналитика. На самом деле роль аналитика интегрирована в структуру разработки настолько глубоко, что вычленение ее оттуда может привести к обычному водопаду, — методу разработки, которого часто стараются избежать. Но бывает, что именно так строится разработка и именно так и видят себя аналитики.
Дело не в русском языке. Есть глобальные проблемы классификации, упорядочивания, описания научной информации, речь о терминологии. В программировании очень серьезные проблемы с этим. Налицо проблема многозначности терминологии, смешения понятий, подмены исходных значений. Очень много трансформированных лексем.
Это порождает некий хаос и недопонимание между людьми, работающими в разных областях.
Конкретно с ООП все вообще очень неопределенно: тот же метод — фактически функция.
Обозвать это методом мог только человек, который слабо понимает разницу между алгоритмом, методом и принципом.
Применительно к программированию, вероятно, вина переводчика. Метод надо было переводить совершенно по-другому, так как то, что в русском языке понимается под методом — совершенно не отражает то, что понимается под этим программистами ООП.
Это порождает некий хаос и недопонимание между людьми, работающими в разных областях.
Конкретно с ООП все вообще очень неопределенно: тот же метод — фактически функция.
Обозвать это методом мог только человек, который слабо понимает разницу между алгоритмом, методом и принципом.
Применительно к программированию, вероятно, вина переводчика. Метод надо было переводить совершенно по-другому, так как то, что в русском языке понимается под методом — совершенно не отражает то, что понимается под этим программистами ООП.
Дело не в русском языке.
Как же «не в русском языке», если и автор поста пишет «Адепту ООП очень трудно понять, что термин экземпляр класса в русском языке указывает на класс объектов», и вы пишете «надо было переводить совершенно по-другому, так как то, что в русском языке понимается под методом»?
Это одна и та же совершенно не новая проблема «эти идиоты в своей области используют терминологию, которая в моей области/в общем употреблении/в другом языке обозначает совсем другое».
Надо мне было добавить слово «конкретно» или «именно» в русском.
Тут, думаю, все равно, в каком языке.
Вы правы, проблема не новая, но есть общеупотребительные термины, собственно, — это даже не термины, а какие-то глубоко устоявшиеся понятия. Я не зря привел как пример именно «метод», так как это что-то более широкое в восприятии любого человека независимо от специальности.
Тут, думаю, все равно, в каком языке.
Вы правы, проблема не новая, но есть общеупотребительные термины, собственно, — это даже не термины, а какие-то глубоко устоявшиеся понятия. Я не зря привел как пример именно «метод», так как это что-то более широкое в восприятии любого человека независимо от специальности.
Вы правы, проблема не новая, но есть общеупотребительные термины, собственно, — это даже не термины, а какие-то глубоко устоявшиеся понятия.
Многие «глубоко устоявшиеся понятия» со временем, как ни странно, меняются. Или, скажем, приобретают другие значения в специальных областях (вот, например, милое слово «рубашка»).
Я не зря привел как пример именно «метод», так как это что-то более широкое в восприятии любого человека независимо от специальности.
Я не знаю, как там в восприятии «любого» человека, а в моем личном восприятии наличие у слова «метод» в общеупотребительном и в узкоспециальном контексте двух разных значений ничему не мешает и не противоречит.
Вы никогда не задумывались, что, скажем, общеупотребительное значение слова «нота» — неправильное с точки зрения музыкальной теории (и при этом музыкальная теория «более права», потому что в ней этот термин появился раньше, а общее употребление его оттуда позаимствовало)? Но это никому не мешает, включая самих музыкантов.
Вы слишком уж углубились.
Мы часто, когда говорим об ООП, употребляем слово «модель», что в принципе — извините за такую поэзию — есть застывший метод, и, кстати, (наоборот тоже — модель — метод в динамике). Т.е. в общем и целом мы в праве говорить и говорим, что ООП — это метод программирования.
И теперь конкретный пример: человек открывает учебник по ООП и видит функцию обёрнутую в класс, а ему говорят, что это метод. А почему метод?
Почему не функция класса? Зачем так сужать понятие метода?
Мы часто, когда говорим об ООП, употребляем слово «модель», что в принципе — извините за такую поэзию — есть застывший метод, и, кстати, (наоборот тоже — модель — метод в динамике). Т.е. в общем и целом мы в праве говорить и говорим, что ООП — это метод программирования.
И теперь конкретный пример: человек открывает учебник по ООП и видит функцию обёрнутую в класс, а ему говорят, что это метод. А почему метод?
Почему не функция класса? Зачем так сужать понятие метода?
Мы часто, когда говорим об ООП, употребляем слово «модель»
Кто «мы»? И уверены ли вы в том, что эти «мы», употребляя слово «модель» применительно к ООП, действительно имеют в виду «застывший метод»?
Т.е. в общем и целом мы в праве говорить и говорим, что ООП — это метод программирования.
В каком-то смысле — да, однако доминирующая формулировка звучит так: ООП — это парадигма программирования.
И теперь конкретный пример: человек открывает учебник по ООП и видит функцию обёрнутую в класс, а ему говорят, что это метод. А почему метод?
Потому что это так называется в уже устоявшейся терминологии.
Почему не функция класса?
Во-первых, потому, что под функцией в программировании чаще понимают иное, нежели метод (и поэтому сторонники, скажем, функционального программирования на предложенный вами термин могут несколько расстроиться). А во-вторых, потому что придут математики и тоже скажут «какая же это функция?» — и чем их мнение отличается от вашего?
Математики не скажут, кстати. Потому что все же это функция.
Это, очевидно, зависит от математика, и от того конкретного метода, который вы ему покажете. Какое, бишь, определение функции лично вы используете в своем утверждении?
Определение в одно слово — преобразова́ние.
И оно кратко и полно отражает то, что происходит с переменной или экземпляром класса.
И оно кратко и полно отражает то, что происходит с переменной или экземпляром класса.
А во-вторых, потому что придут математики и тоже скажут «какая же это функция?» — и чем их мнение отличается от вашего?
Для полноты картины: придут музыковеды, и скажут, что с точки зрения Римановской теории функций то, что и математики, и программисты называют функциями, к функциям никакого отношения не имеет.
С момента написания статьи прошло много времени. Есть очень хорошая статья, которая подвела итог моим исследованиям на тот момент: www.ritba.ru/#!modeling/c64i Но и это еще не все. На текущий момент разработаны модели на основе данного подхода. И теперь разрабатываются соответствующие фреймворки для создания такого рода моделей. Так что вопрос о терминологии для нас уже пройден и закрыт. Да, терминология ООП вредна, она вводит в заблуждение.
Так что вопрос о терминологии для нас уже пройден и закрыт.
Поздравляю вас.
Да, терминология ООП вредна, она вводит в заблуждение.
Для кого вредна? Кого вводит в заблуждение?
Она вредна для использования в анализе предметной области. Вводит в заблуждение всех участвующих в этом процессе участников. И в конце концов она вредна для самих программистов, потому что через некоторое время у них возникает деформация, в которой они начинают в реальном мире видеть «инстансы» вместо объектов.
И в конце концов она вредна для самих программистов, потому что через некоторое время у них возникает деформация, в которой они начинают в реальном мире видеть «инстансы» вместо объектов.
… но нет. Для программистов (если, конечно, это ОО-программисты) терминология их доминирующей отрасли не вредна.
А про использование программистской терминологии в анализе (это касается любой терминологии, не только ОО-, я вот чаще всего следы от БД вижу) уже давно все сказано.
Класс слонов существует в поле, в Африке, мы его создать не можем, разве только путем специального разведения. В системе мы создаем объекты, моделирующие слонов. Я же в своей статье пишу про класс реальных слонов, а не тех, которые создаются в системе
Не существует класса реальных слонов. Класс это абстракция, которая возможна только в модели/системе, моделирующей реальный мир. В реальном мире есть некоторые реальные объекты, которые люди называют слонами и которые группируют по каким-то своим признакам. Например, в Китае класс медведь для большинства людей это панды. Класс и тип это исключительно человеческие абстракции по группировке реальных объектов и в реальном мире их нет. И тип и класс далеко не единственные и далеко не бесспорные критерии группировки объектов.
Думаю, что логическая парадигма с Вами не согласна. В природе существуют группы объектов. Эти группы называются множествами и обладают какими-то признаками, отличными от объектов этих множеств. Тип — это Аристотель придумал и его нет в природе, а вот с классом поосторожнее — они ровно такие же объекты, как и объекты. В логической парадигме у них даже название одинаковое — Thing. Рисунок из стандарта ИСО 15926:
Это лишь одна из систем абстракции, придуманных человеком. В другой системе все будет принципиально другим. Пока вы этого не поймете, будите так же ограничены, как программисты использующие чужие паттерны во всех случаях.
Да, но непротиворечивая абстракция. Это важно. ее придумали не случайно, а потому что она непротиворечива
Чему непротиворечива? Если бы она была наилучшей и единственно возможной системой придставления знаний, логики и мышления, ИИ уже был бы создан (по определению).
Она на сегодняшний день единственная непротиворечивая модель представления нашего мира. над ней работали 200 лет математики и философы. Интересно, что может быть круче?
Я не ослышался, над ISO 15926 (начат в 1991, работы ведутся) 200 лет работали математики и философы?
Над теорией игр работали сколько? неужто 2 года? нет, конечно, к ней шли много веков
Я, если честно, не понимаю, почему для ISO 15926 вы считаете возможным считать опыт предшественников в плюс, а для остальных парадигм — нет. Они не опираются на предыдущий опыт?
Опираются, конечно! ООП на Аристотеля, например. Я об этом и пишу
Любопытно.
Таким образом, можно сказать, что над ООП две с лишним тысячи лет работали математики и философы. Как какая-то там логическая модель, с ее всего-то двумястами годами, может быть круче?
Таким образом, можно сказать, что над ООП две с лишним тысячи лет работали математики и философы. Как какая-то там логическая модель, с ее всего-то двумястами годами, может быть круче?
Да, Аристотель круче)), Я не пользуюсь терминами круче)). Есть термин более или менее подходящий для данного класса задач
Советую поизучайте теории создания ИИ и все те системы, которые на их основе созданы. Там самых различных моделей представления нашего мира более чем достаточно. А «круче» от математика, которым мы себя называете, вообще смотрится абсурдом. Как и считать что система должна оцениваться возрастом или считать что математическая модель или система может быть идеальной или абсолютной.
создание ИИ, теория ИИ и теория создания ИИ — это разные вещи?
Смысл в том, чтобы с ростом сложности совершенствовать и свое понимание и свой язык. Если Вы делаете ошибки подобного рода, значит вы еще недостаточно много поработали в области онтологии. Язык становится такой же частью вооружения онтолога, как и модели, которые он строит.
Давайте еще раз по-порядку. Мы говорили не про программирование, не про код, а про реальные объекты в реальном мире. Я говорил про ту машину, что стоит у меня под окнами. У нее есть колеса, у нее есть класс колес, и это не имеет отношения к программированию никакого. Мы говорим только о предметной области и только о ней. В ООП есть конструкции, которые моделируют эти объекты предметной области. И я утверждаю в статье, что классы реальных объектов в ООП моделируются при помощи типов. Но не при помощи классов. Это беда, потому что целое поколение программистов выросло, не различая эти понятия. Например, кто-то даже написал, что мы используем типизированные классы, или что-то в этом роде. К сожалению, это нам в институте не преподают.
И надо просто понять, что есть классы в природе. Класс слонов — он тот класс, объектов, который состоит из слонов, пасущихся в Африке. И этот класс был задолго до появления компьютеров. Его (класс) тогда изучали биологи.
И надо просто понять, что есть классы в природе. Класс слонов — он тот класс, объектов, который состоит из слонов, пасущихся в Африке. И этот класс был задолго до появления компьютеров. Его (класс) тогда изучали биологи.
Я говорил про ту машину, что стоит у меня под окнами. У нее есть колеса, у нее есть класс колес,
Нет у неё класса колес, у неё есть 4 реальных предмета, которые люди называют колеса. Группировать по видам, классам, типам, родам, материалам и прочему можно только при построении абстрактной системы, частично моделирующей реальный мир, но к самому реальному мире она прямо не относится.
У машины 5 предметов, которые мы классифицируем, то есть относим к классу колес. Этот класс именованных объектов, из чего мы можем именовать объект данного класса. Есть неименованные классы, здесь нам приходится как-то выкручиваться
.
.
мы классифицируем, то есть относим к классу колес.
вот именно, что ВЫ классифицируете, то есть строите абстрактную СИСТЕМУ лишь частично моделирующую реальный мир. Для существа без зрения, а только с нюхом, там есть сильный металический запах, с запахом резины. Для системы искуственного интеллекта, для существ с другими органами чувств или мышления, мышина и колеса будут совсем другими абстрактными объектами. Надо понимать, что как только вы переходите к АБСТРАКЦИЯМ вы уже не в реальном мире, вы в своей собственной сугубо СУБЪЕКТИВНОЙ системе, которая не имеет 100% достоверности с реальностью, вплоть до того что то что вы называете слоном, может оказаться мухой в реальности.
Стоп! А как Вы получаете объекты в мире? Или Вы думаете, что они существуют вне вашего сознания? Ровно также существуют и классы
Не хотелось бы показаться резким и некорректным, но из таких советов:
можно в любой книжке по ООП составлять главу «Примеры, как не надо делать».
Если у нас есть тип данных (класс в понятиях ООП) «Слон», то для полноценной реализации сущности предметной области нам нужно реализовать типы данных «Список слонов» и «Слоны», которые и будут разруливать общее кол-во слонов, их средний вес и т.д.
В случае, если мы заводим в одном типе данных «Слон» статические поля «общее кол-во», какие-то средние величины, то даже говорить не хочется что будет с вашими этими полями при работе с многопотоком, с сопровождением кода двумя-тремя и более «поколениями» программистов, и т.д.
Есть впечатление, что при том, что ООП сейчас явно находится в кризисе, если не в конце жизненного цикла (тут и от функциональных языков какие-то ожидания, и чуть ли не скриптовый Golang, по моему мнению, являющийся одним из кандидатов на новый мейнстрим),
так вот при этом, к сожалению, ООП за этот период так и не «взлетел», т.е. не использовался так, чтобы получить отдачу, от того, что вообще заложено в ОО-концепцию.
А жаль — инструмент очень красивый и мощный.
При создании класса слонов сохраняем кол-во всех слонов, сумму длительности жизни, роста, веса всех слонов в статические поля и после получаем все средние величины.
можно в любой книжке по ООП составлять главу «Примеры, как не надо делать».
Если у нас есть тип данных (класс в понятиях ООП) «Слон», то для полноценной реализации сущности предметной области нам нужно реализовать типы данных «Список слонов» и «Слоны», которые и будут разруливать общее кол-во слонов, их средний вес и т.д.
В случае, если мы заводим в одном типе данных «Слон» статические поля «общее кол-во», какие-то средние величины, то даже говорить не хочется что будет с вашими этими полями при работе с многопотоком, с сопровождением кода двумя-тремя и более «поколениями» программистов, и т.д.
Есть впечатление, что при том, что ООП сейчас явно находится в кризисе, если не в конце жизненного цикла (тут и от функциональных языков какие-то ожидания, и чуть ли не скриптовый Golang, по моему мнению, являющийся одним из кандидатов на новый мейнстрим),
так вот при этом, к сожалению, ООП за этот период так и не «взлетел», т.е. не использовался так, чтобы получить отдачу, от того, что вообще заложено в ОО-концепцию.
А жаль — инструмент очень красивый и мощный.
В случае, если мы заводим в одном типе данных «Слон» статические поля «общее кол-во», какие-то средние величины, то даже говорить не хочется что будет с вашими этими полями при работе с многопотоком, с сопровождением кода двумя-тремя и более «поколениями» программистов, и т.д.
Ничего не будет, если поля потокобезопасные и приватные. AtomicInteger в java, например.
private static AtomicInteger sumWidth = new AtomicInteger();
private static AtomicInteger countWidth = new AtomicInteger();
private Integer width;
public setWidth(int width) {
this.width = width;
sumWidth.addAndGet(width);
countWidth.incrementAndGet();
}
public double static synchronized getAverageWidth(){
double sumWidth = this.sumWidth.get();
double countWidth = this.countWidth.get();
return sumWidth / countWidth;
}
Ответил разом на другой ваш комментарий.
И все же, не могу удержаться, напишу еще.
Вот вы пишите
Вы молодец, но в моей практике вы входите буквально в единицы программистов, которые заботятся о «потокобезопасности и приватности».
А уж кто там будет копаться, что там использовать — AtomicInteger в java, или какой аналог этого есть в C#, вообще сложно представить.
Полагаю, все-таки, с учетом назревших задач, рано или поздно назреют и новые парадигмы программирования.
Вот вы пишите
Ничего не будет, если поля потокобезопасные и приватные.
Вы молодец, но в моей практике вы входите буквально в единицы программистов, которые заботятся о «потокобезопасности и приватности».
А уж кто там будет копаться, что там использовать — AtomicInteger в java, или какой аналог этого есть в C#, вообще сложно представить.
Полагаю, все-таки, с учетом назревших задач, рано или поздно назреют и новые парадигмы программирования.
Кажется, только сейчас я понял, почему программисты так злоупотребляют статическими полями — видимо, они действительно думают, что статические поля это общие данные класса (т.е. всего множества объектов — экземпляров данного класса).
Но ведь в любой (любой!) хорошей книжке по ООП написано, что класс это всего лишь тип данных, а не множество объектов!
Соответственно, если мы заводим статическое поле класса — характеристику именно типа данных, то если мы пытаемся использовать это поле как общие данные множества объектов, то мы используем инструмент не по назначению (пытаемся завивать гвозди кусачками) => куча проблем.
Но ведь в любой (любой!) хорошей книжке по ООП написано, что класс это всего лишь тип данных, а не множество объектов!
Соответственно, если мы заводим статическое поле класса — характеристику именно типа данных, то если мы пытаемся использовать это поле как общие данные множества объектов, то мы используем инструмент не по назначению (пытаемся завивать гвозди кусачками) => куча проблем.
И тип и множество. Объясните зачем тогда вообще нужны статические поля, если не для хранение общих для всех классов данных?
Объясните зачем тогда вообще нужны статические поля, если не для хранение общих для всех классов данных?
Вы задаете вопрос на миллион.
Действительно, зачем нужны статические поля?
Статические элементы класса вообще к чистому ООП не имеют отношения.
Если их и использовать то для описания именно типа данных.
В этом случае статические поля должны быть readonly и immutable.
Например, поле (константу) Int32.MaxValue я отношу к описанию типа данных, а не к общим данным для всех экземпляров данного класса.
В соседнем посте вы привели пример, как сделать статические поля потокобезопасными — все это технические меры, в одном языке сработает, в другом нет. Вы напишите потокобезопасный код корректно — другой программист нет.
То, что вы написали для вычисления средних значений, суммы, все это можно реализовать и с помощью другого класса, статического хелпера или других конструкций (например, если есть класс «Машина», то вычислением этих величин могут заняться классы «Список машин» или «Машины»).
Поймите, статические поля не имеют отношения к концепции ООП.
А то, что вы пытаетесь с помощью них решить некие задачи, говорит только о том, что концепция ООП неполна/противоречива, и есть задачи, которые не имеют «нативного» решения с помощью ООП.
Конечно, использовать статические поля самое простое, проще, чем предложенные в отдельном посте сущности «Машина»/«Список Машин»/«Машины», которые образуют «метасущность».
Поскольку не хочется делать ни того, ни другого, поэтому я и пишу — хотелось бы новой парадигмы/платформы программирования, которая устраняла бы противоречивость ООП и соответствовала (маппилась) на теорию множеств.
Действительно, есть задачи, которые с помощью ООП решать неудобно. Это не значит, что концепция ООП неполна или противоречива, это просто значит что этот инструмент не универсален. No silver bullet there either.
На самом деле я рассказал про статические поля в своей статье. Если есть статическое поле «средний рост слона», то относится это поле не к слону, Слон понятия не имеет о среднем по слонам? Однако, в реализации статических переменных слон знает о среднем по слонам. С точки зрения логики — коллизия.
Неверно, конкретный слон ничего не знает о среднем по слонам. Возвращать статические полям должны только у статические функции, то есть функции, априори работающие со всеми слонами класса. Функцию
«public double static getAverageWidth()» нельзя (точнее можно, но неправильно) вызывать у конкретного объекта класса слон, только для всей группы слонов.
«public double static getAverageWidth()» нельзя (точнее можно, но неправильно) вызывать у конкретного объекта класса слон, только для всей группы слонов.
Отдельно взятый слон ничего не должен знать об агрегирующих данных, относящихся к «слонам».
А в вашем примере он может это сделать, просто обратившись с приватному статическому полю своего класса.
А в вашем примере он может это сделать, просто обратившись с приватному статическому полю своего класса.
(А как же эгрегор и родовая память?)
А если серьезно, то идея о том, что конкретный экземпляр не должен ничего знать об общих для типа данных — неоднозначна. Вас, вероятно смущает не то, что он «знает», а то, что он может туда что-то записать?
А если серьезно, то идея о том, что конкретный экземпляр не должен ничего знать об общих для типа данных — неоднозначна. Вас, вероятно смущает не то, что он «знает», а то, что он может туда что-то записать?
И знать тоже не должен.
Если мы моделируем войсковое соединение, то при таком подходе программист может так запрограммировать бойца (любого экземпляра типа данных «боец»), что тот будет знать о всем количестве войск.
Это, очевидно, неправильно.
Идея ООП в том, что есть данные, которые вот нельзя знать (и уже тем более изменить) — абстрагирование, инкапсуляция. Иначе бы мы спокойно программировали процедурно.
Если мы моделируем войсковое соединение, то при таком подходе программист может так запрограммировать бойца (любого экземпляра типа данных «боец»), что тот будет знать о всем количестве войск.
Это, очевидно, неправильно.
Идея ООП в том, что есть данные, которые вот нельзя знать (и уже тем более изменить) — абстрагирование, инкапсуляция. Иначе бы мы спокойно программировали процедурно.
Это, очевидно, неправильно.
Ну, так не программируйте так чтобы экземпляра типа данных «боец» знал о кол-ве войск, то есть не давайте экземпляра типа данных «боец» ни одного публичного метода, возвращающего агрегатные данные.
Программист может запрограммировать так чтобы по рефлексии обратиться к любому приватному полю любого класса в системе (говорю в терминах Java, но подозреваю в других языках есть аналогичные мехонизмы), но от кривого программиста, пишущего кривой класс, не спасет ничего кроме code review.
То есть в ООП объект класса НЕ МОЖЕТ знать о значении статической переменной? Если МОЖЕТ, то ООП нарушает логику. Если НЕ МОЖЕТ, тогда можно продолжать обсуждение. Но по моим сведениям, — МОЖЕТ. В логической же парадигме — не может.
Объясните простую вещь про вашу логическую парадигму:
Есть онлайн магазин, скажем, продающий мобильные телефоны. Главным объектом у него товары, у которых под сотню параметров (производители, размер, цена, цвет, вес, емкость аккумалятора и т.п.). В атрибутной-типовой моделе, тут все просто: сотня аттрибутов разных типов. В вашей логической парадигме где все класс, я правильно понимаю, что у вас будет несколько тысяч классов с разной ценой, сотни классов с разным весом, сотни классов с разными размерами длины и высоты телефона, десятки тысяч классов даты создания объявления и его модификации и т.п. То есть кол-во классов будет измеряться как все_параметры_товара * все_возможные_значения.
Во-первых, непонятно как при этом делать поиск на сайте, дата_обнавления > такой-то_даты, цена в диапазоне от столько_рублей до столько_рублей. Во-вторых, непонятно каким образом реализовывать миллионы классов, как строить отчеты и как получать средние суммы. В-третьих, при каждой продаже товара его нужно будет перемещать из класса товары с продажами в 32 штуки в классы с продажами с 33 штуки.
Можете на пальцах построить модель такого онлайн магазина в логической парадигме?
Кстати, заодно обясните как модель в логической парадигме должны будут реализовать программисты? Потому что, если нет нормального и понятного способа реализовать в коде модель в логической парадигме, программисты просто выкинут модель и все реализуют через ООП.
Есть онлайн магазин, скажем, продающий мобильные телефоны. Главным объектом у него товары, у которых под сотню параметров (производители, размер, цена, цвет, вес, емкость аккумалятора и т.п.). В атрибутной-типовой моделе, тут все просто: сотня аттрибутов разных типов. В вашей логической парадигме где все класс, я правильно понимаю, что у вас будет несколько тысяч классов с разной ценой, сотни классов с разным весом, сотни классов с разными размерами длины и высоты телефона, десятки тысяч классов даты создания объявления и его модификации и т.п. То есть кол-во классов будет измеряться как все_параметры_товара * все_возможные_значения.
Во-первых, непонятно как при этом делать поиск на сайте, дата_обнавления > такой-то_даты, цена в диапазоне от столько_рублей до столько_рублей. Во-вторых, непонятно каким образом реализовывать миллионы классов, как строить отчеты и как получать средние суммы. В-третьих, при каждой продаже товара его нужно будет перемещать из класса товары с продажами в 32 штуки в классы с продажами с 33 штуки.
Можете на пальцах построить модель такого онлайн магазина в логической парадигме?
Кстати, заодно обясните как модель в логической парадигме должны будут реализовать программисты? Потому что, если нет нормального и понятного способа реализовать в коде модель в логической парадигме, программисты просто выкинут модель и все реализуют через ООП.
Я не занимаюсь реализацией парадигмы в коде. Это надо понимать. Я занимаюсь построением моделей. И в этих моделях реально очень много классов. Вопрос в том, что не все из них нужно выносить на бумагу в момент проектирования систем. Достаточно лишь тех, о которых мы в данный момент ведем речь. Как решаются задачи построения промышленных моделей, надо спросить у Агроскина. Он знает, потому что работает именно над этим. Я же не строю эти модели, потому что в той области, в которой я работаю, ИСО не дает мне нужных классов сущностей. Их приходится думать самому. Вот о процессе выделения в сущем таких классов я и веду речь на хабре.
Я занимаюсь построением моделей.
Для кого и чего? Модель бессмысленна сама по себе, она всегда нужна для чего-либо, либо для реализации в системе, либо для упрощение понимания бизнес процессов. И в том и в другом случае нет проблемы описать модель интернет магазина с одни единственным типом товара.
Как решаются задачи построения промышленных моделей, надо спросить у Агроскина. Он знает, потому что работает именно над этим.
Зачем вы киваете на других людей? ВЫ лично НЕ УМЕЕТЕ использовать ВАШУ парадигму для построения ЭЛЕМЕНТАРНОЙ бизнес модели?
Хотя бы модели ПОИСКА товара на сайте по разным параметрам или ПОКУПКИ этого товара.
Я же не строю эти модели, потому что в той области, в которой я работаю, ИСО не дает мне нужных классов сущностей. Их приходится думать самому. Вот о процессе выделения в сущем таких классов я и веду речь на хабре.
Так какие модели вы строите и что выделяете? И почему вы ЛИЧНО не можете построить модель простейшего бизнес процесса по вашей парадигме?
Модель, если быть точным, существует в голове. На бумаге мы строим представление этой модели при помощи известной нам нотации. Мы можем представлять модели не только на бумаге, мы это делаем ртом, когда говорим на языке, мы делаем это, когда пишем, мы делаем это, когда рисуем. Но все эти представления — суть представление одной модели. Мы делаем представление модели каждый раз, когда открываем рот. Зачем? чтобы передать информацию о модели от одного субъекта другому. Вопрос — зачем строить представления моделей можно переформулировать в зачем мы разговариваем? Затем же мы пишем, затем же мы рисуем. У Вас очень ограниченное представление о целях этого процесса. Мы можем обмениваться моделями с разными, совершенно неожиданными целями. Я даже боюсь взяться классифицировать эти цели. Пуст этим занимаются психологи. Моя задача не объяснять цели моделирования, а рассуждать о конкретном способе представления моделей.
Я не ставлю задачу решать конкретные примеры. Я ставлю задачу объяснить конкретный тип мышления, который позволит строить конкретные модели. А те, кто объясняют, как стоить конкретные модели, — я указал на них.
Я не могу построить модель примитивного процесса, потому что, чтобы объяснить Вам что я построил, понадобится еще 10 статей на хабре.
Я не ставлю задачу решать конкретные примеры. Я ставлю задачу объяснить конкретный тип мышления, который позволит строить конкретные модели. А те, кто объясняют, как стоить конкретные модели, — я указал на них.
Я не могу построить модель примитивного процесса, потому что, чтобы объяснить Вам что я построил, понадобится еще 10 статей на хабре.
У Вас очень ограниченное представление о целях этого процесса. Мы можем обмениваться моделями с разными, совершенно неожиданными целями. Я даже боюсь взяться классифицировать эти цели.
Модель строится чтобы либо упростить понимание предметной области, либо упростить практическую реализацию. Какие ещё цели вы можете представить?
Я не ставлю задачу решать конкретные примеры. Я ставлю задачу объяснить конкретный тип мышления, который позволит строить конкретные модели. А те, кто объясняют, как стоить конкретные модели, — я указал на них.
Простите, но получается так что вы сами не понимаете как строить модели. Очень уж похоже на адептов заряженной воды Петрика и прочей лженауки. Или построение примитивной модели настолько сложно, что бесмысленно, или вы пишете о том чего совсем сами не понимаете. То вы говорите, что сами разработали свою версию модели, то говорите что не умете строить модели и отправляете к гуру. То говорите что она построена на логике Аристотеля, то что она напрочь её отрицает. То говорите что 200 лет её строят все ученые и математики, то оказывается что строят всего 10 лет два ГУРУ в России, которые только и знают как правильно. То вы говорите что дока в этой парадигме, то не можете построить простейший пример и обяснить его своими словами. Что-то тут не сходится.
Я не могу построить модель примитивного процесса, потому что, чтобы объяснить Вам что я построил, понадобится еще 10 статей на хабре.
Зачем нужна модель для понимания примитивного примера, которой нужно прочитать тонну книг? У любой модели есть назначение облегчить понимание для других людей предметной области(программистов, заказчика, аналитика).
Если клиент приходит к вам с задачей, вы тоже скажете «я не могу построить вам модель, так как вы её вообще не поймете без тысячи часов у ГУРУ»? Или всех программистов для понимаения что вы там намоделировали вы тоже отправляете на месяц к ГУРУ в монастырь?
P.S. Как говорил мой учитель высшей математики, если ученый не может доступно обяснить, чем он занимается, семилетнему ребенку — он шарлатан.
Я не объясняю, как строить модели. Это объясняет Агроскин, Я пытаюсь понять, как получить непротиворечивый язык для построения моделей. Такой, чтобы он удовлетворил мои потребности и делюсь этим с другими. Если Вас устраивает Ваш язык, я не пытаюсь Вас научить другому. Пользуйтесь им. Вопрос в том, что не у одного меня есть вопросы к существующим терминам ООП. Для решения этой задачи я пытаюсь разобраться с тем, что они значат и как построить модель без использования их.
Я уже пробовал пойти по этому пути (на другом примере). Конкретных ответов мне не дали, к сожалению.
Если МОЖЕТ, то ООП нарушает логику.
Нет. ООП не нарушает логику, в рамках которой построено ООП. Иными словами, внутренних противоречий в ООП в этом месте нет.
Не удержался и написал, это код на C# с комментариями.
// Класс «Слон»
class Elephant
{
// Общее число слонов — в рамках класса «Слон» эмулируем класс «Слоны»
private static int totalElephantCount;
// Имя слона — характеристика экземпляра
private string name;
// Конструктор экземпляра
public Elephant(
string name // имя слона — входной параметр
)
{
this.name = name;
}
// Имя слона — открытое экземплярное свойство только для чтения
public string Name
{
get { return this.name; }
}
// Экземплярный метод «Бежать» — заставляет слона бежать
public void Run()
{
// Здесь пишем код, который как-то обозначает, что слон бежит
// А вот тут зачем то мы обратились к данным, общим для всего множества слонов (класса «Слоны»)
// — читаем.
// Слон не должен знать эту информацию, если мы не не разрешили ему это через специальные конструкции
// Но прочитать статическое поле нам компилятор в любом случае разрешит
int count = totalElephantCount;
// А теперь отдельно взятый слон возьмет и вообще перезапишет число слонов в стаде
// (вопросы потокобезопасности вынесем пока за скобки — это схематичный пример)
totalElephantCount = 0;
}
}
// Класс «Слон»
class Elephant
{
// Общее число слонов — в рамках класса «Слон» эмулируем класс «Слоны»
private static int totalElephantCount;
// Имя слона — характеристика экземпляра
private string name;
// Конструктор экземпляра
public Elephant(
string name // имя слона — входной параметр
)
{
this.name = name;
}
// Имя слона — открытое экземплярное свойство только для чтения
public string Name
{
get { return this.name; }
}
// Экземплярный метод «Бежать» — заставляет слона бежать
public void Run()
{
// Здесь пишем код, который как-то обозначает, что слон бежит
// А вот тут зачем то мы обратились к данным, общим для всего множества слонов (класса «Слоны»)
// — читаем.
// Слон не должен знать эту информацию, если мы не не разрешили ему это через специальные конструкции
// Но прочитать статическое поле нам компилятор в любом случае разрешит
int count = totalElephantCount;
// А теперь отдельно взятый слон возьмет и вообще перезапишет число слонов в стаде
// (вопросы потокобезопасности вынесем пока за скобки — это схематичный пример)
totalElephantCount = 0;
}
}
А теперь правильный пример (упрощенный, код реального проекта будет сложнее):
// Класс "Слон"
class Elephant
{
// Имя слона - характеристика экземпляра
private string name;
// Конструктор экземпляра
public Elephant(
string name // имя слона - входной параметр
)
{
this.name = name;
}
// Имя слона - открытое экземплярное свойство только для чтения
public string Name
{
get { return this.name; }
}
// Экземплярный метод "Бежать" - заставляет слона бежать
public void Run(
int speed // скорость
)
{
// Здесь пишем код, который как-то обозначает, что слон бежит
}
}
// Класс "Слоны" (фабрика слонов)
class Elephants
{
// "Список слонов" - для упрощения его реализации используем готовый класс List<T>:
private System.Collections.Generic.List<Elephant> elephantList;
// Конструктор класса
public Elephants()
{
this.elephantList = new List<Elephant>();
}
// Добавить нового слона в множество слонов
public void AddNewElephant(
string name // Имя слона
)
{
this.elephantList.Add(new Elephant(name));
}
// Общее число слонов
public int TotalElephantCount
{
get { return this.elephantList.Count; }
}
// Метод Run - завставляет бежать слона с индексом "elephantIndex" со скоростью "speed"
public void Run(int elephantIndex, int speed)
{
this.elephantList[elephantIndex].Run(speed);
}
}… и этот код прекрасно демонстрирует, что непротиворечиво реализовать задачу в терминах ООП можно.
QED.
PS Хотите, я этот ваш «правильный» код сломаю с точки зрения логики?
QED.
PS Хотите, я этот ваш «правильный» код сломаю с точки зрения логики?
В моем понимании, должно быть не можно, а должно.
Т.е., в идеальной парадигме/платформе разработке первый пример не должен компилироваться, а второй должен.
И еще второй пример должен реализоваться проще, короче, «нативнее», чтобы не пришлось каждый раз плодить такой паттерн.
Т.е., в идеальной парадигме/платформе разработке первый пример не должен компилироваться, а второй должен.
И еще второй пример должен реализоваться проще, короче, «нативнее», чтобы не пришлось каждый раз плодить такой паттерн.
Т.е., в идеальной парадигме/платформе разработке первый пример не должен компилироваться
Аргументы? Должно быть запрещено любое обращение к статикам?
И еще второй пример должен реализоваться проще, короче, «нативнее», чтобы не пришлось каждый раз плодить такой паттерн.
Какой именно?
(ну а вообще, второй пример в .net нативно реализуется через Set. Причем с семантикой множества.)
Аргументы? Должно быть запрещено любое обращение к статикам?
Про аргументы я уже не раз писал,
а вот насчет статиков, на мой взгляд, статик-поля должны быть разрешены только в таком качестве:
readonly & immmutable.
В этом случае в таких статиках можно будет реализовать только характеристики типа данных, не данные, общие для множества,
и в этом случае, естественно, экземпляр должен иметь возможность их прочитать (как и сейчас экземпляр имеет информацию о своем типе — в C# это делается через this.GetType; да и про другие типы данных он экземпляр знает через typeof(T) — и это нормально).
Какой именно?
О котором не раз писал, и который сейчас привел — назовем его Метасущность (Объект — Список Объектов — Объекты).
(ну а вообще, второй пример в .net нативно реализуется через Set. Причем с семантикой множества.)
Вы про HashSet(T)?
Здорово, что вы знаете про это.
Однако, тут та же проблема: можно и должно.
Один из участников дискуссии, насколько я понял, сторонник первого приведенного мною примера со статиками.
Если мы с вами дадим ему задание, сильно нам поможет наличие в стандартной библиотеке класса HashSet(T)>?
Поэтому хотелось бы решения проблемы можно и должно, и реализации парадигмы множества не через класс HashSet (пусть и стандартный), а через синтаксис языка.
Про аргументы я уже не раз писал,
Я имел в виду «на основании каких формальных признаков компилятор должен дать ошибку». Но вы, в принципе, ответили — запись в статическое поле.
а вот насчет статиков, на мой взгляд, статик-поля должны быть разрешены только в таком качестве: readonly & immmutable.
Во-первых, вы только что запретили стандартную реализацию синглтона (и всех произвольных от него паттернов навроде Ambient Context). А во-вторых, каждый раз, когда вы хотите в ОО-языке сделать что-то immutable, задумайтесь — а вам точно не пора уйти в ФП?
О котором не раз писал, и который сейчас привел — назовем его Метасущность (Объект — Список Объектов — Объекты).
А вот неправда, у вас сейчас есть только объект и список объектов, причем для второй части паттерн встроен в любую разумную библиотеку — следовательно, поддержка уже есть.
Вы про HashSet(T)?
Да.
Поэтому хотелось бы решения проблемы можно и должно, и реализации парадигмы множества не через класс HashSet (пусть и стандартный), а через синтаксис языка.
И сильно вам это поможет от программиста, которого не устроит то, что предоставляет синтакисис языка, и который реализует собственный класс?
Понимаете, чем больше ограничений вы накладываете, тем меньше возможностей вы оставляете в языке. Именно поэтому когда вы хотите новую парадигму, не надо обрезать существующий язык, надо брать новый, и строить его с нуля. При этом у вас получится именно то, что нужно в вашей парадигме, а не непонятный костыль к существующей.
Повторюсь, дело не в реализации парадигмы множеств в ООП. Дело в решении задачи в ООП — без использования парадигмы множеств. В подавляющем большинстве случаев для решения задачи эта парадигма не обязательна.
Во-первых, вы только что запретили стандартную реализацию синглтона
О синглтоне я думал, но ведь вокруг него всегда столько споров, про него говорят даже «антипаттерн».
А вот неправда, у вас сейчас есть только объект и список объектов, причем для второй части паттерн встроен в любую разумную библиотеку — следовательно, поддержка уже есть.
А вот за это замечание спасибо.
Пример простой очень.
Сейчас — да, класс Elephants является всего лишь wrapper'ом (оболочкой) вокруг списка (List).
Однако, добавьте в класс Elephants поля вида:
— хозяин этого стада (множества) слонов;
— место жительства этого стада;
— да что угодно, в общем случая от предметной области зависит.
И вы получите класс, вполне подпадающей под определение «Слоны» («Стадо слонов»).
А в качестве «списка» (или «множества»?), кстати, действительно можно использовать не только List(T), но и тот же HashSet(T).
Именно поэтому когда вы хотите новую парадигму, не надо обрезать существующий язык, надо брать новый, и строить его с нуля. При этом у вас получится именно то, что нужно в вашей парадигме
Изначально речь шла о недостатках моделирования предметной области с помощью ООП.
Считаю, что недостатки ООП здесь очевидны.
Вполне можно подправить и существующую парадигму (тем более не такая уж она и догматичная — посмотрите на различия Delphi, C++, C++/CLI, Java, C#, VB.NET).
В целом, конечно, речь идет о новой парадигме. От ООП мы лишь отталкиваемся.
О синглтоне я думал, но ведь вокруг него всегда столько споров, про него говорят даже «антипаттерн».
Он, конечно, антипаттерн, но иногда он нужен в том или ином виде; а уж тем более — аналогично решаемые вещи типа наивного кэша.
И вы получите класс, вполне подпадающей под определение «Слоны» («Стадо слонов»).
Именно что стадо слонов. Вы из множества сущностей сделали новую сущность, которая (в терминах классического E-R) просто включает другие сущности. Все, вам больше не нужно абстрактное множество.
А в качестве «списка» (или «множества»?), кстати, действительно можно использовать не только List(T), но и тот же HashSet(T).
List(T) нельзя использовать в качестве множества, потому что он позволяет многократное включение одного и того же элемента.
Изначально речь шла о недостатках моделирования предметной области с помощью ООП.
Считаю, что недостатки ООП здесь очевидны.
Нет, не очевидны. Есть недостатки вашей реализации неизвестной задачи. А по мере конкретизации задачи (как можно видеть буквально в вашем примере) ООП обратно отыгрывает свои позиции.
Очевидно, дискуссия подходит к логическому концу, т.к. очевидно, что мы говорим об один и тех же вещах, но с разных сторон:
Об этом я говорил с самого начала: необходимость строить такую (мета)сущность считаю недостатком парадигм ООП и E-R.
Слишком большой соблазн прямо в классе «Слон» начать плодить статик-поля, относящиеся к классу «Слоны» («Стадо слонов»). Со всеми вытекающими — об этом мы тоже говорили.
Хотя в приведенном примере и не будет повторения (каждый раз добавляется в список новый «Слон»), то все верно:
система должна быть масштабируемой, следует ожидать в будущем добавления метода, который будет не просто добавлять нового слона в список, а добавлять уже имеющегося слона, переданного вызывающей стороной;
и здесь, чтобы не делать проверки самим на наличие экземпляра в списке (с потенциальными ошибками и уменьшением производительности), в случае использования стандартных классов, нужно использовать именно HashSet(T)
(если же проверка все равно нужна — для отслеживания повторных попыток добавления, то HashSet это позволит сделать).
Именно поэтому когда вы хотите новую парадигму, не надо обрезать существующий язык, надо брать новый, и строить его с нуля. При этом у вас получится именно то, что нужно в вашей парадигме
Нет, не очевидны. Есть недостатки вашей реализации неизвестной задачи. А по мере конкретизации задачи (как можно видеть буквально в вашем примере) ООП обратно отыгрывает свои позиции.
Об этом я говорил с самого начала: необходимость строить такую (мета)сущность считаю недостатком парадигм ООП и E-R.
Слишком большой соблазн прямо в классе «Слон» начать плодить статик-поля, относящиеся к классу «Слоны» («Стадо слонов»). Со всеми вытекающими — об этом мы тоже говорили.
List(T) нельзя использовать в качестве множества, потому что он позволяет многократное включение одного и того же элемента.
Хотя в приведенном примере и не будет повторения (каждый раз добавляется в список новый «Слон»), то все верно:
система должна быть масштабируемой, следует ожидать в будущем добавления метода, который будет не просто добавлять нового слона в список, а добавлять уже имеющегося слона, переданного вызывающей стороной;
и здесь, чтобы не делать проверки самим на наличие экземпляра в списке (с потенциальными ошибками и уменьшением производительности), в случае использования стандартных классов, нужно использовать именно HashSet(T)
(если же проверка все равно нужна — для отслеживания повторных попыток добавления, то HashSet это позволит сделать).
Об этом я говорил с самого начала: необходимость строить такую (мета)сущность считаю недостатком парадигм ООП и E-R.
Это не метасущность! У нее есть свои собственные атрибуты, собственная идентичность.
классу «Слоны» («Стадо слонов»).
Слоны и стадо слонов — это две разные вещи.
Это не метасущность! У нее есть свои собственные атрибуты, собственная идентичность.С точки зрения теории множеств — да.
С точки зрения ООП и E-R моделирования — формально и вне контекста обсуждаемой статьи — тоже да.
Я уже писал, почему в контексте «моделируем сущность средствами ООП и реляционной модели непротиворечивым образом» мы получаем конструкцию, которую можно назвать (мета)сущностью.
Хотите, берите в кавычки: создаем сущность с помощью паттерна «метасущность».
Однако, это вопрос терминов, которые неизбежно будут возникать при разработке новой парадигмы.
По более важным вопросам: достаточно сложной реализации в текущей парадигме непротиворечивой модели (мета)сущности и самой возможности реализации противоречивой модели (через один ООП-класс и статики), я уже высказался.
Слоны и стадо слонов — это две разные вещи.У нас есть три сущности: «Слон», «Список слонов» (точнее, множество слонов — Set) и «Стадо слонов».
По вашему, какую роль выполняет сущность «Слоны»?
Наличие самой метасущности — есть как раз тот камень, на который натыкаешься при проектировании данных при помощи ООП. Это то, обо что разбивается желание строить непротиворечивые модели. В лекции Агроскин упомянул тот факт, что структура метасущностей — не есть дерево. Если бы это было дерево, то ООП нам подходило для проектирования как нельзя лучше.Но на самом деле классификация устроена по другому принципу и описать ее при помощи метасущностей невозможно, разве что самые простые классификации. ООП не учит правильно классифицировать сущности и разруливать коллизии, при этом неизбежно возникающие. Как будто специально обходя этот острый угол стороной. Не думаю, что создатели ООП были настолько заторможены, что не увидели этот угол. Но тем не менее о нем не сказали).
Наличие самой метасущности — есть как раз тот камень, на который натыкаешься при проектировании данных при помощи ООП.
Ну нет.
«Метасущность» в ООП может возникнуть в одном из двух вариантов. Либо речь идет о метапрограммировании, и тогда это детали реализации, которые аналитика не касаются, либо речь идет о требованиях, и тогда это проблема не ООП, а требований.
С точки зрения теории множеств — да.
С точки зрения ООП и E-R моделирования — формально и вне контекста обсуждаемой статьи — тоже да.
Вот видите? Никаких противоречий кроме тех, которые вы придумали.
Я уже писал, почему в контексте «моделируем сущность средствами ООП и реляционной модели непротиворечивым образом» мы получаем конструкцию, которую можно назвать (мета)сущностью.
Вот только я не помню, чтобы я соглашался с вашими утверждениями. По-моему, ровно наоборот.
достаточно сложной реализации в текущей парадигме непротиворечивой модели
Один дженерик — это для вас сложно?
самой возможности реализации противоречивой модели
Вы не можете оставить инструмент достаточно мощным и одновременно не позволяющим сделать противоречивую модель.
У нас есть три сущности: «Слон», «Список слонов» (точнее, множество слонов — Set) и «Стадо слонов».
Есть две сущности — слон и стадо слонов. Список слонов — это не сущность вообще, это реализация связи между слонами и стадами.
По вашему, какую роль выполняет сущность «Слоны»?
Никакой. Ее тоже нет.
И знать тоже не должен.
Если мы моделируем войсковое соединение, то при таком подходе программист может так запрограммировать бойца (любого экземпляра типа данных «боец»), что тот будет знать о всем количестве войск.
Это, очевидно, неправильно
Не очевидно. Вы тут смешиваете «знать» в терминах программы и «знать» в терминах задачи. Не стоит моделировать бизнес-ограничения доступа в виде ограничений видимости в языке.
Ну и да, если задуматься, то в решении с множествами проблема приблизительно аналогичная.
Вообще вы путаете «отдельно взятого слона» и «класс слонов». Класс слонов может работать со статическим полем, но вот «отдельно взятый слон», то есть через объект класса слонов нельзя работать со значением статического поля, если мы явно не пропишем ему эту логику. То есть класс слонов со всеми статическими и обычными методами это тип и множество всех слонов этого типа. А вот объект класса слон это уже «отдельно взятый слон», который не будет иметь знания об агрегирующих данных, если мы ему это не позволим.
Слон понятия не имеет о среднем по слонам?
Не должен знать, с т.ч. зрения современных архитектур и шаблонов проектирования (паттернов).
Однако, при наличии соответствующего статического поля у ООП-класса — знает.
Именно поэтому я пишу, что статические поля у ООП-класса следует заводить только для описания типа данных, но никак не для определения данных, характеризующих множество объектов (средние значения, количество и прочие агрегирующие функции).
И потому статические поля — только readonly и immutable должны быть.
Однако, при наличии соответствующего статического поля у ООП-класса — знает.
Нее, он знает только в том случае если у него есть публичный не статический метод, позволяющий работать со статическим полем. Иначе объект класса слон не знает ничего о агрегатных функциях класса слон.
Статическое поле — это поле, назначение которого заключается в обеспечении наличия единого значения для всех экземпляров класса. Но стоит заметить, что статическое поле — это тоже свойство экземпляра класса, что следует из определения класса (совокупность объектов, которым присущи некоторые описанные классом характеристики). Отсюда, статическое поле «среднее по слонам» в классе Слон не должно быть, так как не является свойством экземпляра класса (среднее по слонам логически не может быть свойством объекта слон).
В ООП все понятия четко определены:
Класс — множество объектов, которым присущи свойства, описанные этим классом.
Экземпляр — сущность, которая обладает свойствами, описанными классом.
P.S. прошу прощения, не в ту ветку ответил
В ООП все понятия четко определены:
Класс — множество объектов, которым присущи свойства, описанные этим классом.
Экземпляр — сущность, которая обладает свойствами, описанными классом.
P.S. прошу прощения, не в ту ветку ответил
Да вроде в ту ветку…
Смотрите, здесь на уровне семантики мы понимаем, что такое статического поле не должно быть у класса «Слон»?
То, что компилятор это допускает, это как раз и является одним из противоречий текущей парадигмы ООП.
А вот отсюда на первый взгляд следует, что у класса «Слон» можно завести поле «Общее число слонов»?
На мой взгляд — нет.
Если отвлечься от путаного термина «класс», и исходить из того, что класс в ООП — всего лишь тип данных, то…
А что описывает тип данных? — Набор атрибутов (свойств) и, в ООП это еще и поведение, экземпляров этого типа данных.
Свойство «Общее число слонов» не является свойством «Слона».
Очевидно, что это атрибут «Стада слонов», и для этой сущности в ООП нам нужно завести отдельный класс (тип данных).
Таким образом, в классе ООП не нужны статические поля, а значит, если мы хотим непротиворечивой модели, то их не должно быть, т.е. компилятор их не должен допускать
Единственное исключение, на мой взгляд, я уже писал — полагаю, допустимы readonly & immutable поля (а также константы), т.к. с помощью них можно задать дополнительные характеристики типа данных (не экземпляра и не «стада экземпляров»).
Отсюда, статическое поле «среднее по слонам» в классе Слон не должно быть, так как не является свойством экземпляра класса (среднее по слонам логически не может быть свойством объекта слон).
Смотрите, здесь на уровне семантики мы понимаем, что такое статического поле не должно быть у класса «Слон»?
То, что компилятор это допускает, это как раз и является одним из противоречий текущей парадигмы ООП.
Статическое поле — это поле, назначение которого заключается в обеспечении наличия единого значения для всех экземпляров класса.
А вот отсюда на первый взгляд следует, что у класса «Слон» можно завести поле «Общее число слонов»?
На мой взгляд — нет.
Если отвлечься от путаного термина «класс», и исходить из того, что класс в ООП — всего лишь тип данных, то…
А что описывает тип данных? — Набор атрибутов (свойств) и, в ООП это еще и поведение, экземпляров этого типа данных.
Свойство «Общее число слонов» не является свойством «Слона».
Очевидно, что это атрибут «Стада слонов», и для этой сущности в ООП нам нужно завести отдельный класс (тип данных).
Таким образом, в классе ООП не нужны статические поля, а значит, если мы хотим непротиворечивой модели, то их не должно быть, т.е. компилятор их не должен допускать
Единственное исключение, на мой взгляд, я уже писал — полагаю, допустимы readonly & immutable поля (а также константы), т.к. с помощью них можно задать дополнительные характеристики типа данных (не экземпляра и не «стада экземпляров»).
Таким образом, в классе ООП не нужны статические поля, а значит, если мы хотим непротиворечивой модели, то их не должно быть, т.е. компилятор их не должен допускать
Вам не приходило в голову, что классы в ОО-программе — не только сущности из модели?
Задача правильно выделить свойства абстракции кладется на девелопера. Конечно, было бы неплохо, чтобы компилятор проверял корректность отношения свойства к некотор сущности… Никаких противоречий в ООП нет. То, что компилятор не запрещает ситуации из серии «а создам-ка я статическое поле Общее по слонам в классе Слон» — не есть проблема ООП. Если противоречие и возникает, то это скорее всего неверно выделены свойства сущности при абстрагировании.
А вот отсюда на первый взгляд следует, что у класса «Слон» можно завести поле «Общее число слонов»?
На мой взгляд — нет.
Да, это я имел ввиду — нельзя завести такое поля. Точнее выражаясь, технически завести-то можно, а логически нет.
Для класса Слон статического поля общее по слонам не должно быть, так как просто-напросто такого свойства у слона быть не может.
А вот отсюда на первый взгляд следует, что у класса «Слон» можно завести поле «Общее число слонов»?
На мой взгляд — нет.
Да, это я имел ввиду — нельзя завести такое поля. Точнее выражаясь, технически завести-то можно, а логически нет.
Для класса Слон статического поля общее по слонам не должно быть, так как просто-напросто такого свойства у слона быть не может.
И ведь пишут в книжках и мануалах, что тот же статический конструктор класса инициализирует _тип данных_ (читай, не используйте его, например, для подгрузки данных из БД — инфы, характерной больше для множества уже созданных объектов, чем для самого типа).
А потом удивляются, почему в случае ошибки чтения из БД (да еще в многопотоке) получаем ошибку «type initialization error» и программа вообще не может двигаться дальше.
Правильно, у нас же ошибка связана не с, например, наполнением множества объектов, а с инициализацией типа данных, т.е. мы не имеем описания типа данных => не можем создать ни одного экземпляра (объекта). И именно поэтому среда исполнения не дает повторной возможности (попытки) проинициализировать тип — очевидно, что инициализация типа данных это вещь детерминированная, поэтому возможен только перезапуск программы (подавлять исключение бесполезно, как это любят делать неквалифицированные и неответственные программисты, => все равно не одного экземпляра не создадим, все равно перезапускать программу).
А потом удивляются, почему в случае ошибки чтения из БД (да еще в многопотоке) получаем ошибку «type initialization error» и программа вообще не может двигаться дальше.
Правильно, у нас же ошибка связана не с, например, наполнением множества объектов, а с инициализацией типа данных, т.е. мы не имеем описания типа данных => не можем создать ни одного экземпляра (объекта). И именно поэтому среда исполнения не дает повторной возможности (попытки) проинициализировать тип — очевидно, что инициализация типа данных это вещь детерминированная, поэтому возможен только перезапуск программы (подавлять исключение бесполезно, как это любят делать неквалифицированные и неответственные программисты, => все равно не одного экземпляра не создадим, все равно перезапускать программу).
Аристотель считал, что у субъекта есть идея существования машин. Эта идея выражена в виде абстрактного типа объектов (машин), существующего в сознании у субъектов. Когда субъект смотрит на объект, он сравнивает то, что он видит, с тем образом, который есть у него в воображении (с типом машин), и, если находит схожие черты, то объект называет машиной, или экземпляром машины. Перечень схожих черт Аристотель назвал типом.
Простите, но после Аристотеля было over миллион философов и ученых, почему вы считаете что теория созданная несколько тысяч лет назад единственная правильная на все времена? Возможно Аристотель считал что земля покоится на спине черепахи, а солнце вращается вокруг неё, мы должны также считать? Тут вы мне кажется просто используете знакомое всем имя, чтобы объявить некую теорию и терминологию априори единственной и верной.
Я вам больше того скажу: Аристотель не говорил того, что ему приписывает maxstroy.
Хм, достаточные ли у вас основания это утверждать? Для того чтобы утверждать такое нужно прочитать и понять всего Аристотеля, так что прошу подтверждения, действительно ли Вами прочитан весь Аристотель
Чтобы это опровергнуть, достаточно привести цитату, где Аристотель такое утверждает.
(а я да, я еще витка два назад просмотрел «Категории», к которым, собственно, и отсылает maxstroy, и там Аристотель говорит о первых и вторых сущностях, а не о типах и экземплярах. Аристотель вообще не мог использовать слово «экземпляр», потому что оно латинского происхождения, а Аристотель писал по-гречески. Более того, Партридж, на которого ссылается maxstroy, тоже, говоря об Аристотелевской парадигме, использует термины «первичная и вторичная субстанция» (primary and secondary substance))
(а я да, я еще витка два назад просмотрел «Категории», к которым, собственно, и отсылает maxstroy, и там Аристотель говорит о первых и вторых сущностях, а не о типах и экземплярах. Аристотель вообще не мог использовать слово «экземпляр», потому что оно латинского происхождения, а Аристотель писал по-гречески. Более того, Партридж, на которого ссылается maxstroy, тоже, говоря об Аристотелевской парадигме, использует термины «первичная и вторичная субстанция» (primary and secondary substance))
Аристотель, конечно, не говорил про типы. Термины тип и экземпляр типа родились позже под действием логики Аристотеля. И они стали отражением способа мышления. Если мы говорим экземпляр, то сразу надо искать тип этого экземпляра. Потому что экземпляр предполагает объект из ряда себе подобных. Что значит подобных? Это значит, что существует субъект, у которого в сознании эти объекты выглядят похожими. Похожими их делает с точки зрения Аристотеля тип объектов, или первичная сущность, как он ее называл.
Но с точки зрения современных представлений мы говорим о некоей модели, которая существует в головах у субъектов одного социума. (В одном социуме эти объекты будут считаться похожими, а в другом — нет). И тогда, если мы находимся в том социуме, где есть одна на всех модель похожести объектов, мы говорим, что субъект на основании этой модели, выделяет объекты, схожие друг с другом по только ему (субъекту и социуму) известным признакам. Но вот тут мне становится сложно рассуждать в терминах тип и экземпляр типа. Потому что с точки зрения современных философов мы говорим об объектах способах их классификации и о классах, которые возникают на основе этих классификаций.
Если речь идет о классах, то в класс входят объекты. Класс описывается только одним способом — перечислением объектов, в него входящих. Почему? Если сказать. что признаками, то получится что никто и никогда не может сделать ошибку. И положить помидор вместе с яблоками в одну корзину. Но такое случается и тогда объекты класса, который лежит в корзине, будут обладать разными свойствами, но тем не менее, образовывать классом. Для рассуждений мы часто используем способы описания объектов одного класса. Это некий признак, который говорит нам о том, чем отличаются объекты данного класса от всех остальных объектов.
Мы можем обратить внимание, что объекты внутри класса чем-то похожи друг на друга. Мы можем определить это свойство и создать класс объектов с таким свойством. Но фокус в том, что в этот класс войдут все объекты с таким свойством, ВСЕ! В этом фундаментальное отличие логической парадигмы от ООП и Аристотелевских типов.
Но с точки зрения современных представлений мы говорим о некоей модели, которая существует в головах у субъектов одного социума. (В одном социуме эти объекты будут считаться похожими, а в другом — нет). И тогда, если мы находимся в том социуме, где есть одна на всех модель похожести объектов, мы говорим, что субъект на основании этой модели, выделяет объекты, схожие друг с другом по только ему (субъекту и социуму) известным признакам. Но вот тут мне становится сложно рассуждать в терминах тип и экземпляр типа. Потому что с точки зрения современных философов мы говорим об объектах способах их классификации и о классах, которые возникают на основе этих классификаций.
Если речь идет о классах, то в класс входят объекты. Класс описывается только одним способом — перечислением объектов, в него входящих. Почему? Если сказать. что признаками, то получится что никто и никогда не может сделать ошибку. И положить помидор вместе с яблоками в одну корзину. Но такое случается и тогда объекты класса, который лежит в корзине, будут обладать разными свойствами, но тем не менее, образовывать классом. Для рассуждений мы часто используем способы описания объектов одного класса. Это некий признак, который говорит нам о том, чем отличаются объекты данного класса от всех остальных объектов.
Мы можем обратить внимание, что объекты внутри класса чем-то похожи друг на друга. Мы можем определить это свойство и создать класс объектов с таким свойством. Но фокус в том, что в этот класс войдут все объекты с таким свойством, ВСЕ! В этом фундаментальное отличие логической парадигмы от ООП и Аристотелевских типов.
По причине того, что в современных представлениях под типом понимается модель, под объектам — объекты, а под классами — классы, я не вижу смысла тащить термины тип и экземпляр в современные модели. А. если тащить, то помнить, откуда ноги растут: если употребляешь термин экземпляр, то будь добр сообщить нам о типе объектов. В итоге аналитик, который использует термины тип и экземпляр начнет сам себе противоречить, потому что типы противоречивы по своей природе. И тогда надо будет отбрасывать все эти термины и переходить на термины объекты и классы. При этом мы можем говорить об описаниях объектов класса или об описании класса объектов, Но термин экземпляр исчезнет как туман. Останутся объекты и классы объектов
я не вижу смысла тащить термины тип и экземпляр в современные модели.
Тут ситуация двоякая. Тащить термины «тип» и «экземпляр» в инструментарий моделирования я смысла не вижу (термин «экземпляр» там вообще низачем не сдался, термин «тип» слишком неоднозначен). Но при этом если в бизнесе есть «тип» (например, «тип документа» как его простой атрибут) или «экземпляр» (например, «экземпляр договора» как тот конкретный комплект бумажек, который остается у каждой стороны), то в модели они оказаться должны.
Я, когда разговариваю с заказчиком, имею ввиду все смыслы, которые могут быть вложены в любой из терминов, но в модели термин тип не будет участвовать никогда. Потому что он из той логики, которая дает сбой. Вместо термина тип документа я использую термин класс документов и это будет равносильное утверждение. Тип документов «договор», экземпляр этого типа документов — конкретный документ, у меня будет звучать так: данный объект относится к классу информационных объектов, подклассу — договора, И мне понятно, и нет противоречий
но в модели термин тип не будет участвовать никогда
Даже если им пользуется заказчик?
Потому что он из той логики, которая дает сбой
Он не из логики, он из бизнесовой системы терминов.
Вместо термина тип документа я использую термин класс документов и это будет равносильное утверждение.
Нет, не будет. «Письмо» или «распоряжение» — это не класс документа в документообороте, это тип документа. Так уж устроен конкретный регламент. А классы там, внезапно — первый, второй и третий.
Пожалуйста, посмотрите на мои примеры еще раз, они как раз об этом.
Я говорю не о том, как нам хотелось бы, а о том, как будет непротиворечиво. Если Вы строите модели которые не подлежат расширению, то нет и проблем — стройте себе типы. Но как только мы строим сложные расширяемые конструкции, мы переходим к классам. Это доказано математиками и неизбежно как воздух
Это доказано математиками и неизбежно как воздух
Дайте ссылку на твердое доказательство математиками, что моделирование реального мира возможно только с помощью классов. Если вы математик, вы должны знать, что говорить ДОКАЗАНО, можно только тогда когда у вас есть ТОЧНОЕ МАТЕМАТИЧЕСКОЕ доказательства того или иного факта. Иначе это только ваша собственная ТЕОРИЯ.
Я привел две книги, в одной из них — доказательство, а в другой — решение и построение
Я говорил о МАТЕМАТИЧЕСКОМ доказательства. Вы не понимаете что это такое?
У криса строгое математическое доказательство от противного. Его, кстати, мой сын рассказывал на докладе по математике и получил первое место. так что математики проверили.
Какие математики? В школе учители математики? Не сомневаюсь, если бы вы сказали что защитили диссертацию доктора наук и вам поверили, это худо бедно могло сойти за вашу точку зрения.
Ну хорошо, тогда мы возвращаемся к истокам. Если Вы пожелаете, Вы найдете доказательство, благо ссылки я дал. Если не хотите искать, то даже указание на страницу Вам не поможет. Вы все равно будете ревностно защищать свою позицию. Это, к сожалению, я из своего опыта говорю. Нет смысла убеждать человека в том, в чем он не хочет быть убежден
Можете дать точную ссылку?
www.youtube.com/watch?v=Ioi68tNLmYw Это сегодня Виктор оставил.
Ну нет, так не пойдет.
Вы пишете:
Я так понимаю, речь идет о Партридже. И я так понимаю, что если ваш сын это рассказывал, то вы не сегодня про это узнали. Так можно точную ссылку, где у Партриджа строго математическое доказательство от противного?
Вы пишете:
У криса строгое математическое доказательство от противного. Его, кстати, мой сын рассказывал на докладе по математике и получил первое место. так что математики проверили.
ответить
Я так понимаю, речь идет о Партридже. И я так понимаю, что если ваш сын это рассказывал, то вы не сегодня про это узнали. Так можно точную ссылку, где у Партриджа строго математическое доказательство от противного?
Агроскин приводит одно из таких в своей лекции.
Я говорю не о том, как нам хотелось бы, а о том, как будет непротиворечиво.
Если бизнес непротиворечив, значит, и построенная модель будет непротиворечива.
Если Вы строите модели которые не подлежат расширению, то нет и проблем — стройте себе типы.
Все-таки, вы не понимаете, о чем я. Я не «строю тип», я фиксирую в модели тот факт, что заказчик в своем бизнес процессе разделяет документы в документообороте на типы — и это используемая им терминология — и этот «тип» является просто справочным атрибутом сущности «документ», не влияющим ни на что (ни на атрибутивный состав, ни на бизнес-процесс, ни на модель доступа).
Это доказано математиками
Так же, как Аристотель говорил о типах и экземплярах?
Если Вы фиксируете типы документов, то может наступить момент. когда модель станет противоречивой. Об этом в лекции Агроскина есть (ссылку он дал). Типы не обеспечивают непротиворечивость модели при ее расширении
То есть тот факт, что я фиксирую, что у документа может быть красная обложка или синяя обложка, может привести к тому, что модель станет противоречивой?
Посмотрите Агроскина. Он об этом говорит очень доходчиво
Я дискутирую с вами, а не Агроскиным. Вы за собственные утверждения не отвечаете?
Вы просите доказать теорему Ферма. Есть математики, которые знают. как ее доказать. Их человек пять — десять. Они проверили. Мы им доверяем. Вы просите докажи! Или отвечай за свое слово. Я отсылаю Вас к источнику, у которого я почерпнул эти знания. Это на мой взгляд — достаточно.
Тогда хотя бы приведите конкретную атрибутированную цитату, подтверждающую ваши слова.
Это требует обдумывания. Сходу я не могу сейчас придумать кейс. Поэтому предложил Вам посмотреть лекцию и подумать самостоятельно. Это хорошее упражнение.
Ээээ, стоп. Зачем мне кейс? Я попросил конкретную цитату, где авторитет на которого вы ссылаетесь, утверждает то же, что и вы сейчас.
Про красные обложки он не говорит)). Он говорит про аналогичные проблемы
Какие «аналогичные проблемы»? Ссылку, ссылку.
С какого момента (с точностью до пяти минут хотя бы)?
смотреть все! Теорема Ферма за одну минуту?
Я прошу не доказательство, а утверждение (не ваше, а человека, на которого вы ссылаетесь). Доказательство, если оно меня заинтересует, я потом найду сам.
Определения класса, типа, атрибута 19 минута. парадокс на 23 минуте
Забавно, насколько объяснение один в один совпадает с Партриджем. Включая проблему, которая у Партриджа описана в главе 5.1, Staff Example. Как это решается, описано там же. Противоречия в модели возникают из-за ошибок анализа и снимаются при консолидации моделей.
решать их можно. Вопрос в том, что вопрос возник. А не должен был, если бы парадигма была непротиворечивой
Вы думаете, парадигма, основанная на множествах вместо атрибутов, не может породить противоречий, когда разные люди независимо строят модели одной и той же задачи? Может и породит. И их тоже придется снимать.
Я не математик настолько, чтобы глубоко анализировать эти задачи. Я просто доверяю тем математикам, что думали над этой задачей довольно долго.
А я не доверяю. Потому что, с одной стороны, проблема, которая описана в докладе, имеет решение (описанное даже у Партриджа), а с другогой стороны, подход с множествами имеет аналогичную проблему (легко демонстрируемую).
Я не нашел проблемы с множествами.
Самый простой пример: два независимых разработчика модели вводят два множества «цвет» с конкретными подмножествами «красный» и «зеленый». Однако почему-то один и тот же объект в одном множестве «цвет» принадлежит к подмножеству «красный», а в другом — к «зеленый». Внезапно, противоречие.
Они не могут ввести два множества «цвет» — это невозможно.Если это сделать — то получится задвоение данных. Это все равно, что в таблице сделать две записи об одном факте. Можно создать класс цвет, класс красный и класс зеленый. Один предмет может принадлежать классу цвет, классу зеленый, но не принадлежать классу красный. Это вроде очевидно
Они не могут ввести два множества «цвет» — это невозможно.
Могут. Они независимо разрабатывают модели. Ввести два одинаковых типа сущностей в одну модель тоже нельзя, однако в примере Агроскина это делается. Если вы накладываете ограничения на то, что разработчик модели ведет себя добросовестно, то у вас и в атрибутивном подходе не будет противоречий.
(да, формальное определение взаимоисключающих классов тоже обещает быть веселым)
Два разработчика независимо ввели информацию об одном факте в систему. Я правильно понял проблему? кто им позволил? Кто позволит двум независимым операторам внести информацию об одном договоре? Тот и позволит внести два независимых класса с одним смыслом. От дураков не застрахован никто
Ну то есть ограничение лежит не в самой модели, а за ее пределами. Вот вам и источник противоречий.
Повторюсь, я могу к примеру из доклада сказать то же самое: «кто позволил трем студентам нарисовать несовпадающие модели данных для одной сущности?»
Повторюсь, я могу к примеру из доклада сказать то же самое: «кто позволил трем студентам нарисовать несовпадающие модели данных для одной сущности?»
Ограничений нет, потому что системы нет. Я повелся и тоже склеил мозги)). Нет класса красный в системе. Он есть в природе. А в системе есть объект, его моделирующий. А модель не всегда бывает корректна. Она может содержать ошибки оператора, например, но класс в природе не содержит ошибок — он- вот и я показываю на него пальцем
Кстати, а при чем тут система? Класс красный не существует в системе. он существует в природе. В системе мы моделируем этот класс, но не создаем его. Это надо помнить!
(Оооо, вы хотите поговорить со мной о том, какие цвета существуют в природе? Вот есть предмет, русский называет его красным, англичанин — red. Какой цвет существует в природе — красный или red?)
А я и говорю про модель: два разработчика независимо строят модель. И в модели возникает противоречие.
А я и говорю про модель: два разработчика независимо строят модель. И в модели возникает противоречие.
Об этом Агроскин говорит в начале лекции — лб общем глоссарии. Без него вы ничего не построите))
Если есть общий словарь, то описанной для атрибутивного подхода проблемы возникнуть не может, поскольку общий словарь описывает общий набор атрибутов. Все, нет противоречий (потому что они как раз общим словарем и снимаются).
Ой, как же! У кого-то атрибуты, у кого-то типы и все это указывает на один объект в природе. Было бы легко, если был атрибут у всех атрибутом. Но в том и загвоздка, что вы одной системе — это атрибут, а в другой — тип, а в третьей — значение, а в четвертой — связь. И еще бог знает как и чего! Ведь модель не в логической парадигме неоднозначна!
Общий словарь существует как раз для того, чтобы не было «у кого-то». У всех как в общем словаре.
Я, извините, не способен отследить вашу дискуссию, немотря на неоднократные упоминания моей фамилии.
Однако я, разумеется, согласен с тем, что логическая методология не может гарантировать одинаковости моделей.
Модели в логической парадигме будут, тем не менее, более схожи, чем модели людей, не знакомых с ней вовсе, и работающих исключительно на знании Аристотеля, знакомстве с листом бумаги, экселем, или даже стандартным курсом СУБД, начинающимся с рассказа про декартово произведение.
Несомненно также, что следующим этапом на пути к унификации является добавление к логике онтологий. То есть использование единого общего списка цветов и единой системы их идентификаторов.
Однако я, разумеется, согласен с тем, что логическая методология не может гарантировать одинаковости моделей.
Модели в логической парадигме будут, тем не менее, более схожи, чем модели людей, не знакомых с ней вовсе, и работающих исключительно на знании Аристотеля, знакомстве с листом бумаги, экселем, или даже стандартным курсом СУБД, начинающимся с рассказа про декартово произведение.
Несомненно также, что следующим этапом на пути к унификации является добавление к логике онтологий. То есть использование единого общего списка цветов и единой системы их идентификаторов.
Они, несомненно, будут более схожи концептуально, потому что логическая методология оперирует меньшим числом фундаментальных понятий, что уменьшает вариативность описания (и это бонус). При этом семантический их разброс может быть не меньшим (просто в силу того, что семантика неизбежно растет из головы).
Насколько я понимаю, именно поэтому тот же 15926 — это не только описание логики, но и — сразу же — предоставление базового набора классификаций, и изначально заложенная цель создать единый набор классификаций (vs независимый у каждого провайдера). Таким образом, имея униформную логику и предопределенный набор классификаций, мы радикально уменьшаем пространство возможных вариантов моделирования конкретной области (что тоже бонус).
Насколько я понимаю, именно поэтому тот же 15926 — это не только описание логики, но и — сразу же — предоставление базового набора классификаций, и изначально заложенная цель создать единый набор классификаций (vs независимый у каждого провайдера). Таким образом, имея униформную логику и предопределенный набор классификаций, мы радикально уменьшаем пространство возможных вариантов моделирования конкретной области (что тоже бонус).
сорри, модель в логической парадигме однозначна. А вот в других — нет
Это утверждение ничем не подтверждено. Я показал вам, как создать неоднозначность в модели, основанной на множествах.
Вы думаете, что она неоднозначна. Это я понял, но сам не увидел. Как может быть неоднозначна предметная область? Она либо либо. Мы не рассматриваем вероятностные пространства, конечно. Хотя и это укладывается в множество моделей, но с разной вероятностью
Так, стоп.
Вы обвиняли модель «не в логической парадигме» в неоднозначности. Я показал, как модель в логической парадигме тоже может быть неоднозначна.
При чем тут вообще предметная область?
(впрочем, предметная область тоже бывает неоднозначной, если уж совсем честно)
Вы обвиняли модель «не в логической парадигме» в неоднозначности. Я показал, как модель в логической парадигме тоже может быть неоднозначна.
При чем тут вообще предметная область?
(впрочем, предметная область тоже бывает неоднозначной, если уж совсем честно)
Спасибо большое за вопрос о модели! Мы сегодня только его разбирали! У нас в сознании есть модель мира. Эта модель для нас и есть мир. Удивительно, но для большинства людей мир — это сумма их представлений и не больше. Представление этой модели в натуре, или частей этой модели происходит путем применения к модели нотации. В своей статье, посвященной информационным объектам, я это рассмотрел подробно. habrahabr.ru/post/246313/. Поэтому Вы должны различать модель и ее представление. ИМХО, Вы называете представление модели моделью модели
Кстати, вот любопытный вопрос. Как в подходе с множествами описывать количественные характеристики (например, стоимость)? Тоже через множества? Эта книга принадлежит к множеству книг, стоящих 15 рублей? Как, в таком случае, просуммировать стоимость всех книг на складе?
Эти конструкции описаны во второй книге. Как строить температурные шкалы, денежные и так далее. На сегодняшний день описаны много сущностей)). Я не знаю сколько, потому что три года назад их было 50000 а сейчас — затрудняюсь сказать. Это библиотека сущностей, она пополняется.
В какой «второй книге»?
Мэтью Веста. Он рассказывает некоторые принципы, заложенные в ИСО 15926, и критикует некоторые из них. Но на самом деле я лишь проводник к тем гуру, которые в России являются адептами этого направления моделирования: Агроскину и Левенчуку. На этом можно остановиться и рекомендовать их статьи и их видеоматериалы. А при погружении, и курсы, которые они читают
В какой именно? У него 43 публикации.
Я в статье давал ссылки Вы читали статью?
Читал. Извините, не смог вычленить корректную ссылку сразу, смешалась с Партриджем.
К сожалению, в Safari Books Online эта книжка битая. Можете объяснить своими словами или дать ссылку на публичную статью?
Сорри, что не ответил. Я сейчас далеко от рабочего места. Итак, если ссылка битая, то могу выслать. Но смысл построений такой. Берется предмет. Все остальные предметы сравниваются с ним на предмет больше-меньше. И делятся на два класса объектов: больше и меньше образца. Это примитивное разделение на два класса. Если мы пользуемся более точными шкалами, то предметы разбиваются на большее количество классов. Каждый класс при этом больше какого-то предмета, но меньше другого. так образуются шкалы
То есть единственный способ, которым модель, построенная на множествах, может сказать, что у какого-то объекта, скажем, цена — 15 рублей, это (при точности измерения 0.01 рубля) создать два дополнительных объекта, о которых мы знаем, что их цена — 14.99 и 15.01, и включить наш предмет в класс «больше одного образца и меньше другого образца» (ну или включить в два класса, один «меньше образца», другой «больше образца», смысла это радикально не меняет). Так? Или я неправильно понял?
вопросом будет то, что субъект вкладывает в понятие 15 рублей. Он может создать класс объектов, стоимость которых 15 рублей и это будет более правильным решением. Все-таки оценка объектов происходит с точностью до копейки. Этот принцип построения шкалы отличается от построения шкалы пространственных размеров, времени и температуры. Однако, если в нашей модели мира мы исчисляем стоимость пропорционально весу золота, то картина резко меняется. Поэтому надо исходить из того, что в данном обществе понимается под ценностью
(Ээээ… мы же, вроде бы, говорили, что логическая модель позволяет моделировать бизнес ровно одним способом, и этот способ правильный?)
Окей, три способа (X — интересующий нас объект, A — образец со стоимостью 14.99, Б — образец со стоимостью 15.01):
— X принадлежит классу «стоимость 15 рублей»
— X принадлежит классу «больше А и меньше Б
— X приналежит классу „больше А“ и классу „меньше Б“
Все правильно? Какие-то фундаментально отличающиеся способы есть?
Окей, три способа (X — интересующий нас объект, A — образец со стоимостью 14.99, Б — образец со стоимостью 15.01):
— X принадлежит классу «стоимость 15 рублей»
— X принадлежит классу «больше А и меньше Б
— X приналежит классу „больше А“ и классу „меньше Б“
Все правильно? Какие-то фундаментально отличающиеся способы есть?
Денежная шкала в конкретных единицах (рулях, например) разбивает объекты на два класса: те, которые можно оценить и те, которые оценивать бессмысленно. Далее, денежная шкала разбивает объекты на классы одинаковой стоимости. Таких классов очень много. В каждом из них находятся много объектов. В зависимости от точности денежной шкалы мы получаем разные классы объектов.
То, что вы описываете, сводится к первому описанному мной случаю — «X принадлежит классу „стоимость Y“» (понятно, что таких классов много). Я правильно понимаю, что это правильный способ описывать стоимости (и аналогичные им количественные характеристики объектов) в предлагаемой вами логической парадигме?
Если не считать того, что сам термин стоимость тоже имеет описание, то да — этол верный способ классификации объектов. Вопрос лишь в том, что он имеет отличия в зависимости от сообществ. Это надо добавить в модель. Мы берем сообщество, в нем описываем классы объектов, но в другом сообществе мы получим другие классы, но с тем же рублем
(Примем за данность, что сообщество в рамках задачи ровно одно.)
Следующий вопрос: вот есть два класса, «стоимость Y» и «стоимость Z». Чем они отличаются друг от друга? Только идентификатором или чем-то еще?
Следующий вопрос: вот есть два класса, «стоимость Y» и «стоимость Z». Чем они отличаются друг от друга? Только идентификатором или чем-то еще?
Они отличаются объектами, их составляющими. Если найдется объект, который принадлежит и тому и другому классу — это коллизия. Такого быть не может
Они отличаются объектами, их составляющими.
Это рекурсия. Стоимость объекта определяется по классу, к которому он принадлежит, но класс определяется объектами в него входящими. Нет, что-то не так.
Все-таки, вот у меня есть объект. Вероятно, я могу, имея объект, получить информацию о всех классах, в которые этот объект входит (иначе я не узнаю, что машина красная). Предположим, что объект, который у меня есть, относится к некоему классу, входящему в иерархию классов стоимостей (т.е., утверждающему, что стоимость равна x). Как мне понять, чему равна его стоимость — 15 или 20? Как мне отличить друг от друга два класса?
Стоимость объекта определяется по классу. Верно. Класс определяется объектом. Тоже верно, и это понятно: книга лежит на столе, а стол держит книгу. У них отношения такие. Класс содержит объект, объект содержится в классе. Следуя Вашей логике, все объекты, которые имеют отношения (выше-ниже, толще, тоньше) — это рекурсивные определения? ИМХО, — это не рекурсия. Это отношения между объектами.
Так, тогда конкретизируем задачу до прикладной. Есть объект учета (здание, помещение или земельный участок, если интересно). У объекта есть учетная стоимость (чтобы не было вопросов о ее однозначности — это та стоимость, которая указана в документах, которые сейчас внесены в бумажный реестр). Заказчик хочет видеть печатную форму, где будет написано следующее:
«Здание — 15 млн руб» (дальше по одной строчке на каждый объект)
Как именно строится модель для решения этой задачи? Какие классы и объекты она содержит?
«Здание — 15 млн руб» (дальше по одной строчке на каждый объект)
Как именно строится модель для решения этой задачи? Какие классы и объекты она содержит?
надо понимать, что мы имеем дело не с моделью в системе? я много раз об этом говорил. Это понятно? Мы берем класс объектов стоимостью 15. Этот класс не в системе! Он в натуре! То, как мы замоделируем этот факт в системе зависит от тех средства, которые мы используем. Мы можем создать табличку, в которую будем помешать названия объектов( зданий, полей, заводов), стоимостью 15, можем создать таблички для каждого класса объектов: зданий, полей, и заводов и писать в этих табличках строки с цифрой 15. реализовать эту модель в БД можно многими способами. Но в реальности мы будем иметь всего один класс объектов — стоимостью 15
надо понимать, что мы имеем дело не с моделью в системе? я много раз об этом говорил. Это понятно?
Нет, это не понятно. Модель имеет конкретное прикладное значение — она строится для решения конкретной задачи. Сейчас я озвучил задачу, для которой нам нужно построить модель. Вы утверждаете, что логическая парадигма позволяет построить непротиворечивую модель для любой прикладной области — пожалуйста, покажите, как строится модель для озвученной мной предметной области.
(речь пока идет об аналитической модели, т.е. о том, что пишется в требованиях)
Модель существует у нас в голове. В натуре мы создаем описание этой модели при помощи нотации. Мы берем нотацию, которая используется в логической парадигме (их две, насколько я помню. одна — это express-g, а название второй я не помню, но выглядит она, как в стандарте ИСО 15926) Я не на рабочем месте и у меня нет под рукой этого стандарта. Модель, построенная в этой нотации и указывается в требованиях к системе.
То есть описать эту модель в требованиях обычным русским языком невозможно?
Она описывается языком, она описывается в виде рисунка, она описывается языком RDF.
Если она описывается русским языком, то опишите, пожалуйста, модель для данного случая русским языком. Я специально выбрал самый простой возможный случай.
я сказал самый простой кейс, без развертки его на всю страницу. Объект Х принадлежит классу объекктов стоимостью 15
Ладно, подойдем с другой стороны.
Та же самая задача, заказчику интересна табличка «объект — стоимость», внизу которой указан итог — т.е. общая стоимость всех объектов в таблице. Как выразить это требование заказчика в терминах логической парадигмы?
Та же самая задача, заказчику интересна табличка «объект — стоимость», внизу которой указан итог — т.е. общая стоимость всех объектов в таблице. Как выразить это требование заказчика в терминах логической парадигмы?
существует класс объектов, каждый из которых связан со своим классом стоимостей. Полученный класс объектов тоже можно отнести к классу объектов, имеющих стоимость. Получится, что можно оценить не только объекты, но и классы объектов
Как получить сумму стоимостей из объектов, входящих в множество?
В предметной области нельзя получить стоимость множества предметов. Множество предметов оценивается не как сумма стоимостей его предметов. Стоимость множества — есть стоимость множества. И точка. Вы можете построить табличку, связывающую стоимость любого подмножества множества товаров со стоимостью этого множества. И эту зависимость оформить в виде формулы, но в любой формуле есть область определения и область значения. Область определения будет все подмножества данного множества, а область значений — элементы множества стоимостей
Не, не так. В предметной области, есть объекты учета, для каждого известна стоимость, общая стоимость всех учтенных объектов равна сумме стоимостей каждого из объектов. Так это в предметной области, так это понятно заказчику и разработчику.
Теперь, собственно, вопрос: как же это непротиворечиво и единственным образом выразить в терминах логической парадигмы? Не тот факт, что для каждого объекта известна стоимость, а тот факт, что стоимость множества объектов равна сумме их стоимостей?
Теперь, собственно, вопрос: как же это непротиворечиво и единственным образом выразить в терминах логической парадигмы? Не тот факт, что для каждого объекта известна стоимость, а тот факт, что стоимость множества объектов равна сумме их стоимостей?
Общая стоимость не равна сумме стоимостей! Это частный случай. В реальности скорее исключение. Если Вы проектируете свою модель исходя из этого, Вы априори получаете проблемы при расширении, когда столкнетесь с реальным положением вещей (оптовой ценой и прочими ништяками)
В заданной предметной области это универсальное правило, которое используется для вычисления общей стоимости для определенного класса множеств. Иными словами в этой предметной области общая стоимость (для множеств класса «учтенные объекты») всегда равна сумме стоимостей.
Вы помните определение функции? это множество объектов: область определения, область значения и пары соответствий между элементами области определений и элементами области значений.Вот ровно в соответствии с этим определением и строится модель
Вот я и хочу увидеть такую функцию, которая бы выражала описанное выше правило. Область определения — множество множеств «учтенные объекты», область значений — множество стоимостей (whatever they are), а вот как описать алгоритм, переводящий одно в другое?
Функция может иметь ассоциацию с правилом, а может и не иметь. Наличие правила — не есть определение функции, а есть доп опция, которая может быть, а может и не быть. В предметной области мы можем указать связи между элементами множеств, а то, что эти связи подчиняются аналитическому закону, мы отобразим связью ассоциация между связями и законом.
Еще раз. Моделирование предметной области в ИТ нужно для того, чтобы решать задачи. Есть конкретная задача — заказчик хочет видеть общую стоимость всех учтенных объектов. Задача, будем честными, тривиальная. Как ее описать, скажем, используя модель, опирающуюся на атрибутивный подход — понятно и прозрачно.
Как эту же задачу описать в терминах логической парадигмы? Как именно в требованиях, опирающихся на логическую парадигму описания предметной области, формулируются конкретные правила, оперирующие этими объектами?
Как эту же задачу описать в терминах логической парадигмы? Как именно в требованиях, опирающихся на логическую парадигму описания предметной области, формулируются конкретные правила, оперирующие этими объектами?
Кажется, я вклиниваюсь в чужую дискуссию, но хочется высказаться.
Не могу найти в дискуссии о какой предметной области идет речь, но от слов есть объекты учета как-то повеяло скучными вещами типа ERP-систем.
Штука в том, о какой стоимости вы говорите.
Предположим, вы торгуете спортивными товарами в розницу, вам в августе дистрибутор поставил 100500 единиц учета, каждой единице вы прописали у себя в 1С розничную стоимость,
и предполагаете, что сумма стоимостей единиц и есть стоимость всего множеств единиц.
Т.е., вы рассчитываете, что к концу сезона вы все это добро продадите по назначенной вами цене, и получите искомую, заранее вычисленную сумму.
Самое простое: если вы вдруг решите поменять бизнес-модель и продать все это добро оптом, то вам придется от суммы, которую вы высчитали, сделать скидку 50%, а и то и 70%, с учетом, что на дворе, к примеру, ноябрь, а не август уже.
Чуть более сложное:
продолжаете торговать в розницу, а уже в декабре нужно делать скидки, т.е. вводить поправку с той сумме, которую вы высчитали изначально.
даже если вы скажете, что скидки и тот объем товара, который пойдет со скидками, заранее прогнозируется, и цены единиц (из которых складывается общая сумма заранее разбиваются на группы (первым 100 шт. номенклатуры XXX в ERP назначена цена Y руб, а следующим 100 шт. номенклатуры XXX — Y-Z руб.),
то точно вы это все равно не спрогнозируете, тем более, что в декабре внезапно изменился курс, и вы думаете, что делать то — повышать цены, чтобы с летнему сезону закупить летние коллекции по новой цене, или наоборот, резко снижать цены, т.к. продать бы то, что уже есть, т.к. часть покупателей вдруг потеряла интерес к покупкам.
В итоге, если вы заведете у себя в ERP параметр «Стоимость множества всех единиц товара» и вычислите ее как простую арифметическую сумму стоимостей всех единиц учета, то вы, конечно, будете очень рады простому решению, но толку от такой суммы мало, а если вы ее попытатесь использовать в бизнес-прогнозах, то прогорите.
Не могу найти в дискуссии о какой предметной области идет речь, но от слов есть объекты учета как-то повеяло скучными вещами типа ERP-систем.
Штука в том, о какой стоимости вы говорите.
Предположим, вы торгуете спортивными товарами в розницу, вам в августе дистрибутор поставил 100500 единиц учета, каждой единице вы прописали у себя в 1С розничную стоимость,
и предполагаете, что сумма стоимостей единиц и есть стоимость всего множеств единиц.
Т.е., вы рассчитываете, что к концу сезона вы все это добро продадите по назначенной вами цене, и получите искомую, заранее вычисленную сумму.
Самое простое: если вы вдруг решите поменять бизнес-модель и продать все это добро оптом, то вам придется от суммы, которую вы высчитали, сделать скидку 50%, а и то и 70%, с учетом, что на дворе, к примеру, ноябрь, а не август уже.
Чуть более сложное:
продолжаете торговать в розницу, а уже в декабре нужно делать скидки, т.е. вводить поправку с той сумме, которую вы высчитали изначально.
даже если вы скажете, что скидки и тот объем товара, который пойдет со скидками, заранее прогнозируется, и цены единиц (из которых складывается общая сумма заранее разбиваются на группы (первым 100 шт. номенклатуры XXX в ERP назначена цена Y руб, а следующим 100 шт. номенклатуры XXX — Y-Z руб.),
то точно вы это все равно не спрогнозируете, тем более, что в декабре внезапно изменился курс, и вы думаете, что делать то — повышать цены, чтобы с летнему сезону закупить летние коллекции по новой цене, или наоборот, резко снижать цены, т.к. продать бы то, что уже есть, т.к. часть покупателей вдруг потеряла интерес к покупкам.
В итоге, если вы заведете у себя в ERP параметр «Стоимость множества всех единиц товара» и вычислите ее как простую арифметическую сумму стоимостей всех единиц учета, то вы, конечно, будете очень рады простому решению, но толку от такой суммы мало, а если вы ее попытатесь использовать в бизнес-прогнозах, то прогорите.
Не могу найти в дискуссии о какой предметной области идет речь, но от слов есть объекты учета как-то повеяло скучными вещами типа ERP-систем.
Нет, это еще более скучная вещь типа реестрового учета.
В нем, правда, тоже есть более одной стоимости (исходная, текущая, оценочная и так далее), но для каждой из них переходы от объекта к множеству работают одним и тем же образом — стоимость множества равна сумме стоимостей объектов, средняя стоимость равна сумме на количество и так далее.
Я специально брал максимально простой сценарий, основной особенностью которого было то, что он оперирует количественными, а не качественными признаками.
Т.е., у вас несколько стоимостей множества, таких видов?:
— «идеальная стоимость», исходя из рекомендованной розничной цены;
— «прогнозируемая стоимость», исходя из оценки, какая часть товара будет продана со скидкой в конце сезона;
— «форс-мажорные стоимости», исходя из оценки, за сколько весь товар можно продать оптом (в начале, в середине и конце сезона",
— «форс-мажорная стоимость», исходя из оценки, если курс резко измениться в X, X, Z раз.
И для каждого случая вы высчитываете среднюю стоимость единицы номенклатуры, умножаете на кол-во единиц номенклатуры, суммируете полученные суммы по всем номенклатурам, и получаете стоимость множества. Так?
— «идеальная стоимость», исходя из рекомендованной розничной цены;
— «прогнозируемая стоимость», исходя из оценки, какая часть товара будет продана со скидкой в конце сезона;
— «форс-мажорные стоимости», исходя из оценки, за сколько весь товар можно продать оптом (в начале, в середине и конце сезона",
— «форс-мажорная стоимость», исходя из оценки, если курс резко измениться в X, X, Z раз.
И для каждого случая вы высчитываете среднюю стоимость единицы номенклатуры, умножаете на кол-во единиц номенклатуры, суммируете полученные суммы по всем номенклатурам, и получаете стоимость множества. Так?
Нет. У меня нет продаж, у меня есть имущество, принадлежащее конкретному владельцу, и владелец хочет знать его суммарные характеристики, в том числе — общую стоимость (как вообще, так и в разбиении по тем или иным группам).
И с точки зрения владельца (и пока мы так и не обнаружили ни одного противоречащего этой точке зрения случая) общая стоимость для множества равна сумме стоимостей всех элементов множества (хотя, конечно, владелец не оперирует терминами «множество» и «элемент»).
Не нравится этот пример, могу другой привести. Когда в адрес некоего получателя осуществляются платежи, то общая сумма, которая должна быть получена получателем, равна сумме осуществленных платежей (да, я опускаю комиссии и прочие подобные вещи, но к ним как раз применима та же логика, поэтому они не влияют на аргументацию).
И с точки зрения владельца (и пока мы так и не обнаружили ни одного противоречащего этой точке зрения случая) общая стоимость для множества равна сумме стоимостей всех элементов множества (хотя, конечно, владелец не оперирует терминами «множество» и «элемент»).
Не нравится этот пример, могу другой привести. Когда в адрес некоего получателя осуществляются платежи, то общая сумма, которая должна быть получена получателем, равна сумме осуществленных платежей (да, я опускаю комиссии и прочие подобные вещи, но к ним как раз применима та же логика, поэтому они не влияют на аргументацию).
Вот подробная модель стоимости индивида, сделанная по стfylfhne ШЫЩ 15926 15926.org/templatespecs/IN-INDPTY-03.xml
объект может не входить ни в один из классов, кроме одного — класса объектов, иначе мы не поймем, что это объект. Далее каждое свойство объекта — это в логической модели есть вхождение данного объекта в какое-то множество. Классы стоимостей линейны для любой шкалы. Мы выбираем шкалу и она определяет разбиение объектов на классы. На одном классе написано: 15, на другом 20. Мы смотрим, какому классу принадлежит объект и понимаем, что он относится к классу 15. ок.
На одном классе написано: 15, на другом 20.
Вот, вот это место меня интересует. «На классе написано» — имеется в виду некий идентификатор класса, или что-то иное?
Этот класс входит в класс классов с одинаковыми обозначениями: 15
А как отличить класс классов с обозначениями 15 от класса классов с обозначениями 20?
Благодаря связи этого класса с классом нумерованных классов. Я почему рекомендовал посмотреть модель в книге? потому что таких связей там много. Чтобы построить всю конструкцию, необходимо много классов. Сколько — не помню, но больше 4-х.
Что такое «нумерованный класс»?
Это класс, имеющий связь с какой-то цифрой
А что такое цифра? Очередной объект?
цифр а- это класс объектов. Но эдак мы пойдем по всем структурам всех данных))) Лучше остановиться и начать читать книги
Нумерованный класс связан с классом объектов «цифра» или с конкретным объектом (например, 15), входящим в этот класс?
цифра 15 — это класс, но на этом остановимся, иначе нам придется пересказать Matthew West Developing High Quality Data Models.
А я вас уже давно попросил дать ссылку на публично доступную статью, где описана эта методика (своми словами, как можно видеть, не удается).
Я не могу давать ссылки на пиратские ресурсы, это очевидно, нарушение прав
В свое время я поехал к Левенчуку в гости из другого города, чтобы у него почитать эту книгу. Потом нашел ее в электронном виде, но это не помешало мне заказать ее на Амазоне. Труд, потраченный мной на ее поиски был не напрасным. Хотите учиться — приложите усилия
Только в ней есть ошибки)), так что будьте внимательны
В свое время я поехал к Левенчуку в гости из другого города, чтобы у него почитать эту книгу. Потом нашел ее в электронном виде, но это не помешало мне заказать ее на Амазоне. Труд, потраченный мной на ее поиски был не напрасным. Хотите учиться — приложите усилия
Только в ней есть ошибки)), так что будьте внимательны
А я не прошу ссылку на пиратский ресурс, я прошу публично доступную статью, описывающую инструмент в рамках логической парадигмы. Или вы хотите сказать, что вам не известна ни одна общедоступная статья, которая описывает жизненно важный аспект парадигмы?
Обратитесь с этим вопросом к Левенчуку. Он и Виктор Агроскин Вам помогут разобраться в материале
Ну то есть (а) вам не известна такая статья и (б) вы не можете своими словами объяснить, как это работает. Более того, (ц) вы пока так и не построили модель для указанной простой предметной области.
Ок. So much for «непротиворечивая и однозначная парадигма».
Ок. So much for «непротиворечивая и однозначная парадигма».
проблема в том, что мы начали с одной задачи, перешли на другую и так мы не закончим до тех пор, пока не перескажем всю книгу, или весь стандарт. Нет смысла писать то, что уже описано. Читайте стандарт, он переведен на русский. Но без Левенчука как проводника, или Анроскина, Вам будет крайне трудно разобраться в этом. Поверьте мне, я знаю. Поэтому идите к ним, читайте, что они пишут, смотрите видео и постепенно Вы начнете понимать. Мне понадобилось полтора года для этого.
Читайте стандарт, он переведен на русский.
Я могу и по-английски. Дадите ссылку на публично доступную версию?
Нет смысла писать то, что уже описано [...] Поэтому идите к ним, читайте, что они пишут, смотрите видео и постепенно Вы начнете понимать.
Знаете, я очень не хотел прибегать к этому аргументу, но пожалуй, придется.
Нет смысла писать вам то, что описано у Вигерса и Эванса. Идите к ним, читайте, что они пишут, и постепенно вы начнете понимать.
Оригинальная английская версия стандарта — платная. На сайте ISO.
Части 1 и 2 перведены на русский и явлются ГОСТ Р. То есть могут быть найдены в интернете в более или менее уродских форматах. Переводы первой части (официальный ужасный и наш хороший) залинкованы на techinvestlab.ru/ISO15926
Официальный перевод второй части неожиданно не очень ужасен — vsegost.com/Catalog/52/52414.shtml
Из стандарта, разумеется, далеко идущие философские обобщения надо делать самому. В тексте их нет.
Части 1 и 2 перведены на русский и явлются ГОСТ Р. То есть могут быть найдены в интернете в более или менее уродских форматах. Переводы первой части (официальный ужасный и наш хороший) залинкованы на techinvestlab.ru/ISO15926
Официальный перевод второй части неожиданно не очень ужасен — vsegost.com/Catalog/52/52414.shtml
Из стандарта, разумеется, далеко идущие философские обобщения надо делать самому. В тексте их нет.
Спасибо за ссылки.
Проблема с далеко идущими философскими обобщениями в том, что каждый их делает по-своему. В данном случае maxstroy делает какие-то свои обобщения, на основании которых и пишет статьи. В итоге обсуждаем мы не 15926, который можно хоть как-то достать и читать, а постоянно меняющуюся точку зрения.
Ну это всё же не совсем так. Книжки Партриджа и Веста содержат примерно одинаковые философские обобщения.
Беда в том, что я уже видел, как maxstroy приписывает Партриджу то, что тот не пишет — иными словами, делает выводы, если не прямо противоречащие книге, то, по крайней мере, не совпадающие с теми, которые делаю я. Поэтому я предпочитаю обсуждать конкретные написанные слова.
Кстати. Правильно ли я понимаю из вашего комментария, что ISO 15926 полностью описывает пропагандируемую вами логическую парадигму, и в нем нет ничего, что ей бы противоречило?
Текст стандарта мне дали давно, года 4 или 5 назад. Поэтому я не знаю, где его взять сейчас. Давайте спросим Виктора. Я попрошу его ответить на этот вопрос. Ок?
Не ок. Автор статьи не Виктор, а вы. Дискутирую я не с Виктором, а с вами.
Виктор знает на порядки больше меня. Я так, слышал звон… Я работаю над созданием своего онтологического базиса. Потом буду маппить его на ИСО. Сейчас я не знаток ИСО, поэтому меня лучше не спрашивать.
Ага, то есть ваш базис, о котором вы в статье пишете — он ваш собственный, а не ISO-шный? Таким образом, преимущества ISO к нему не обязательно относятся?
Тогда тем более вы не можете отсылать к «в книгах пишут так», потому что у вас свой собственный базис, а не книжный. Придется вам его объяснять самому.
Тогда тем более вы не можете отсылать к «в книгах пишут так», потому что у вас свой собственный базис, а не книжный. Придется вам его объяснять самому.
Я неоднократно писал, что я не использую ИСО в своих построениях. Я использую постулаты логической парадигмы, чтобы строить свой базис. Это моя цель. Вы можете ознакомиться с ИСО, но задавать мне вопросы про ИСО бессмысленно, если есть тот, кто может рассказать про это много лучше.
Любой современный стандарт содержит ошибки. Вспомните то количество неточностей, которые есть в стандарте BPMN! Однако, это не мешает использовать эти стандарты там, под что они заточены. ИСО 15926 — это не просто стандарт, это — способ мышления. И он, способ, универсален. Сам стандарт в той части, где нужен мне лично, проработан плохо и скажем прямо с ошибками. Поэтому я разрабатываю тот подход, который бы позволил исключить эти ошибки и сделать стандарт лучше. Стандарт декларирует опору на логическую парадигму, но соответствует ли он ей полностью, или нет, я бы сказал, что пока есть шероховатости.
Так, все интереснее и интереснеее. Внезапно, в ISO 15926 есть ошибки. Значит, мы не можем его использовать как общую базу для изучения ваших предложений, потому что любой пассаж оттуда, на который я сошлюсь, может оказаться ошибочным. Любопытно.
Вопрос «есть ли хотя бы один общедоступный источник в котором можно ознакомиться с предлагаемой вами парадигмой» остается открытым.
Вопрос «есть ли хотя бы один общедоступный источник в котором можно ознакомиться с предлагаемой вами парадигмой» остается открытым.
Я не знаю чего-то, что не содержало бы ошибок. Я читаю монографии выдающихся ученых, но и там есть ошибки. Ошибки на языке программиста — это баги. Вы видели код без багов? Конечно, их вычищают. Но раньше к этому относились более тщательно. Стандарт ИСО 9000 не прошел бы проверку
Насчет парадигмы — Вы общаетесь с Виктором Агроскиным. ИМХО, лучше источника для ответов не найти.
Я использую логическую модель для той предметной области, в которой я работаю. Это не продажи. Это описание активности. Довольно сложная тема и ее разбором я занимаюсь вот уже на протяжении 11 статей. Это только начало. Чтобы довести разбор до конца нужно еще статей… много. Поэтому, если Вы хотите дойти до конкретных примеров, то придется еще много потрудиться. Так что желаю терпения. Если Вы желаете разобраться в этом самостоятельно, то обратитесь к корифеям. Левенчук и Агроскин — великие мастера, которые смогут Вам помочь.
То есть вы не можете применить логическую парадигму для другой предметной области? Это ограничение парадигмы или ваших навыков?
И еще. Когда вы говорите «я работаю в области» — какую деятельность вы имеете в виду? Работаете в качестве кого?
И еще. Когда вы говорите «я работаю в области» — какую деятельность вы имеете в виду? Работаете в качестве кого?
Нет, я не могу применить логическую парадигму к другой отрасли. Я работаю в отрасли.ю которая описывает активность. Любую. Предприятий, механизмов, топора и валенка. Работаю аналитиком
Нет, я не могу применить логическую парадигму к другой отрасли
Не можете потому, что парадигма неприменима, или потому что ваши навыки недостаточны?
Я работаю в отрасли.ю которая описывает активность.
Что это за отрасль? Она как-то связана с IT-индустрией?
Да, отрасль описания активности связана с ИТ, потому что описание предметной области служит для создания описаний данных в системе.
Что это за отрасль?
Если упростить ваше высказывание, то правильно ли я понимаю, что вы работаете аналитиком, результат работы которого используется для описания данных в некой информационной системе?
Если упростить ваше высказывание, то правильно ли я понимаю, что вы работаете аналитиком, результат работы которого используется для описания данных в некой информационной системе?
в разных информационных системах. Не в одной. Но о том, в каких и почему я пока не говорю специально. Я пока описываю теоретические основы.
Что это за отрасль?
Ваши теоретические основы, как мы уже видим, имеют ограниченную область применения (хотя вы утверждаете, что это универсальная парадигма).
Ваши теоретические основы, как мы уже видим, имеют ограниченную область применения (хотя вы утверждаете, что это универсальная парадигма).
Про отрасль узнаем чуть позже, когда выйдем на отраслевые задачи.
«У нас есть такие приборы, но мы вам про них не расскажем». Ок.
Дело в том, что для рассмотрения отраслевых задач надо ознакомиться с теоретической базой. Я давал тексты, исходя из отрасли, наткнулся на странное желание людей заменять одни тезисы на другие. Поэтому сейчас двигаемся от одного тезиса к другому. Без отвлечений по сторонам
Только неплохо бы тезисы, от которых мы движемся, доказывать, а не просто выдавать за данность, особенно учитывая, что в вашем изложении никогда нельзя понять, на чем они основываются.
Ну а пока — с ваших же слов — приходится считать, что предлагаемая вами методика работает не для всех отраслей, но для каких именно отраслей она работает, мы не знаем.
Ну а пока — с ваших же слов — приходится считать, что предлагаемая вами методика работает не для всех отраслей, но для каких именно отраслей она работает, мы не знаем.
В лекции Агроскина есть намек на решение Вашей задачи на 49 минуте
То, что описывает Агроскин, противоречит тому, что говорите вы. Агроскин вводит новое понятие «литерал», которое не является классом (это понятие, кстати, есть в RDF, но вот в 15926 его нет). Кому верить, вам или ему?
Литерал RDF, как и тип string, в онтологии ISO 15926 отмэплен на класс индвидов.
Класс индивидов — это class_of_individual?
Вообще, странно.
Возьмем целое число. Целое число ведь литерал?
ENTITY integer_number
SUBTYPE OF(arithmetic_number)
Логично, целое число — это всего лишь один из видов числа вообще.
Но:
ENTITY arithmetic_number
SUPERTYPE OF (ONEOF(real_number, integer_number,
multidimensional_number))
SUBTYPE OF(class_of_class);
Иными словами: arithmetic_number — это class_of_class, класс классов.
Либо я чего-то фундаментально не понимаю в этой нотации, либо целое число — это класс классов.
Вообще, странно.
Возьмем целое число. Целое число ведь литерал?
ENTITY integer_number
SUBTYPE OF(arithmetic_number)
Логично, целое число — это всего лишь один из видов числа вообще.
Но:
ENTITY arithmetic_number
SUPERTYPE OF (ONEOF(real_number, integer_number,
multidimensional_number))
SUBTYPE OF(class_of_class);
Иными словами: arithmetic_number — это class_of_class, класс классов.
Либо я чего-то фундаментально не понимаю в этой нотации, либо целое число — это класс классов.
Сорри, я слишком упростил. Там хитро. Целое число в этом стандарте — это не литерал.
Для литералов в стандарте есть тип class_of_information_representation и его подтипы, среди которых есть строка EXPRESS.
A class_of_information_representation is a class_of_arranged_individual that defines a pattern that represents information.
EXAMPLE The texts formed with the pattern of characters 's' concatenated with 'u' concatenated with 'n' are members of the 'sun' сlass_of_information_representation.
То есть конкретная символьная информация — это класс всех тех материальных 4D объектов, на которых она написана.
А число arithmetic_number — это как в теории множеств, класс эквивалентности, то есть класс классов. 15 — это множество всех множеств с 15 элементами. Только не надо меня спрашивать, что такое Пи, боюсь, что тут онтологический процесс продолжен по аналогии :-)
Далее между числом 15 и литералом «15» есть специальное отношение, относящееся к типу class_of_representation_of_thing. Такое же отношение между числом 15 и литералом «XV».
То есть в этой онтологии числа и информация — понятия существенно разные, число как абстрактная идея может быть по разному представлена.
Для литералов в стандарте есть тип class_of_information_representation и его подтипы, среди которых есть строка EXPRESS.
A class_of_information_representation is a class_of_arranged_individual that defines a pattern that represents information.
EXAMPLE The texts formed with the pattern of characters 's' concatenated with 'u' concatenated with 'n' are members of the 'sun' сlass_of_information_representation.
То есть конкретная символьная информация — это класс всех тех материальных 4D объектов, на которых она написана.
А число arithmetic_number — это как в теории множеств, класс эквивалентности, то есть класс классов. 15 — это множество всех множеств с 15 элементами. Только не надо меня спрашивать, что такое Пи, боюсь, что тут онтологический процесс продолжен по аналогии :-)
Далее между числом 15 и литералом «15» есть специальное отношение, относящееся к типу class_of_representation_of_thing. Такое же отношение между числом 15 и литералом «XV».
То есть в этой онтологии числа и информация — понятия существенно разные, число как абстрактная идея может быть по разному представлена.
A class_of_information_representation is a class_of_arranged_individual that defines a pattern that represents information.
EXAMPLE The texts formed with the pattern of characters 's' concatenated with 'u' concatenated with 'n' are members of the 'sun' сlass_of_information_representation.
Ээээ, то есть символ — это individual, конкретный экстент?
То есть в этой онтологии числа и информация — понятия существенно разные, число как абстрактная идея может быть по разному представлена.
Вот и место для неоднозначности трактовки. К сожалению.
Нет, откуда такой вывод? Символ — это такой же паттерн, как и строка символов. Класс.
Для однозначности трактовки надо принять онтологические предпосылки именно этого стандарта. В них всё однозначно. Там ещё большой раздел геометрии, например. Понятия круга, диаметра, числового выражения диаметра, отношения длины окружности к диаметру и его запись цифрами — представлете, сколько всего наворочено!
Для однозначности трактовки надо принять онтологические предпосылки именно этого стандарта. В них всё однозначно. Там ещё большой раздел геометрии, например. Понятия круга, диаметра, числового выражения диаметра, отношения длины окружности к диаметру и его запись цифрами — представлете, сколько всего наворочено!
Нет, откуда такой вывод? Символ — это такой же паттерн, как и строка символов. Класс.
Вот отсюда:
A class_of_information_representation is a class_of_arranged_individual
class_of_information_representation -> class_of_arranged_individual -> class_of_individual.
class_of_individual is a class whose members are instances of possible_individual.
Помню как в институте нас учили строить температурные шкалы. Что касается размеров — тут все просто. А вот с температурными шкалами — много сложнее. Понятно, что определить, что горячее, а что холоднее образца довольно просто. Но вот что такое равный интервал между единицами шкалы, на что опереться при этом — вот вопрос. Когад знаешь про энергию, хоть как-то можно привязаться к внутренней энергии, но а если нет, Тогда была придумана термодинамическая шкала, основанная на цикле Карно. В любом случае — шкалирование очень интересная тема
Теория типов не просто существует более 2000 лет, она проникла в наш язык настолько глубоко, что мы сами того не замечаем. Китайский язык построен на других принципах, например. Поэтому мы воспроизводим Аристотелевскую модель каждый раз, когда открываем рот)
Тогда бы её воспроизвели и в ООП, раз этого нет — значит все ваши построения неверны.
Я вижу здесь логическую ошибку — следствие не следует из посылки. В логическом программировании ее ведь воспроизвели, разве нет?
Нет, никакой ошибки, если верно утверждение «Теория типов не просто существует более 2000 лет, она проникла в наш язык настолько глубоко, что мы сами того не замечаем», значит при мышлении программистам должно было наиболее удобно использовать только её, значит неизбежно ООП должно было её включать как наиболее удобную систему мышления и моделирования. Если тысячи программистов-создателей ООП не использовали «теорию типов» как наиболее удобную и интуитивную, значит исходное утверждение ложно.
Где тут логическая ошибка?
Где тут логическая ошибка?
Моделирование при помощи типов — противоречиво. Поэтому, если мы хотим строить непротиворечивые модели, типы нам не подходят. Поэтому математики и бились над созданием другой, непротиворечивой модели описания мира и создали ее. Теперь мы пользуемся ей, когда нам надо построить непротиворечивые модели
Класс в ООП одновременно является типом и множеством. Для работы как с множеством существуют статические поля, классы. Совершенно не проблема посчитать любые общие для всего множества экземпляром классов параметры, достаточно использовать статические поля. Так же не проблема работать с отдельными множествами одного типа достаточно использовать Set, который кстати позволяет делать любые операции с множествами.
ООП позволил сократить кол-во сущностей тип, класс и множество, до одной сущности класса. Для «идеи» есть интерфейсы и абстрактные классы. Для множеств и типов с конкретной реализацией — классы.
ООП позволил сократить кол-во сущностей тип, класс и множество, до одной сущности класса. Для «идеи» есть интерфейсы и абстрактные классы. Для множеств и типов с конкретной реализацией — классы.
Не понял. Как тип и множества могут быть одновременно? покажите мне такую парадигму, в которой сосуществуют и типы и множества!
Очень просто, когда мы говорим слон мы автоматически понимаем тип слон (большое четырехногое животное), так и множество всех слонов на свете. Когда мы говорим средняя скорость слона, мы берем множество всех слонов, когда мы говорим каждый слон имеет 4 ноги это тип слона. Разницы тут нет.
«Это беда, потому что целое поколение программистов выросло, не различая эти понятия. » — вот как раз и яркий пример этого в коммертарии vedenin1980. Он может говорить о классе как о типе обьектов и как о множестве обьектов, а различает их исключительно по конексту — и поэтому часто может быть понят неправильно
Беда в том что выросло целое поколение «аналитиков» не понимающих что моделей представления реального мира может быть бесконечное множество и каждая имеет свои плюсы и минусы в той или иной задаче.
Отличное сравнение! Теперь давайте конкретизируем Ваш тезис более строго. Различные задачи требуют концентрации на разных аспектах нашего мира. Мы моделируем разные его стороны в зависимости от задачи. Спорить глупо с тем, что для разных задач нужна разная информация. Теперь шаг второй: в рамках одной задачи (одной информации) мы получили результат: модель. Теперь надо понять, что такая модель должна обладать свойствами быть однозначной, если мы говорим о моделировании предметной области. Не должно быть у нее альтернативных моделей, содержащих ровно ту же информацию. Логическая парадигма позволяет это сделать. потому ее и используют в качестве адаптера для разных систем. Типы, ЕР, ООП не позволяют построить такую модель однозначным образом. Вы что имели ввиду под разными моделями? Если разные представления одной информации, то это — бардак. Если разную информацию для разных задач, то это очевидно
Кстати, вы в курсе чем является интерфейс, абстрактный класс и класс? Что из них тип, а что множество в ООП?
Вы говорите в терминах ООП, я же в терминах логической парадигмы. Мы не можем говорить в разных терминологических базисах
Вы говорили что в ООП нет типа и нет множества. Но не понимаете, что класс это множество, а абстрактный класс и интерфейс это тип. То есть вы вообще просто не понимает, о чем говорите.
В ООП нет класса. Есть тип. Это из русского языка. Но в русском языке нет абстрактного класса. и нет интерфейсов -это из ООП. Поэтому я и говорю — программисты говорят на своем языке, который не имеет отношения к предметной области. Он имеет отношение к коду. Но я не программист и код не изучаю
я не программист и код не изучаю
vs
я представляю код как предметную область, затем произвожу его анализ и могу переводить термины программиста в термины логической парадигмы. Это нормальная практика. И я могу это делать
А ещё в русском языке нет абстракции, инкапсуляции, наследования и полиморфизма. Да, удивительно, но в каждой системе, теории, разделе науки или математики говорят на своих терминах. И как не странно группа в топологии не тоже самое что группа в теории категорий. Удивительно, не правда ли? :)
То, что существует в природе. я привел на картинке. Это сущности, которые есть в природе и только такие в логической парадигме. ООП вообще не опирается на парадигму, поэтому все термины ООП не про предметную область
ООП вообще не опирается на парадигму
Просто, чтобы вы знали: Object-oriented programming (OOP) is a programming paradigm (http://en.wikipedia.org/wiki/Object-oriented_programming)
Парадигма программирования, а не онтологическая. Нас интересует мир. а не код. Код — это вотчина программистов. предметная область — вотчина аналитика. Но аналитик может применить онтологию к коду и получить нужные конструкции про код, но выраженные не терминами ООП, а в терминах логической парадигмы. И это надо уметь делать
Вы бы уточняли, какую именно парадигму вы имеете в виду, а то так и будет недопонимание каждый раз.
Я в тексте написал какую. И подчеркнул это.
В своих изложениях я опираюсь на логическую парадигму, в которой есть объект и есть множество объектов, называемое классом объектов, но нет терминов экземпляр, тип и термина класс в смысле ООП.
ООП действительно не опирается на (вашу) логическую парадигму. Но зато ООП само представляет собой парадигму, вопреки тому, что вы о нем пишете. Понять, в каком контексте вы употребляете каждое конкретное слово, зачастую невозможно.
Все, что я пытаюсь сделать, — это отмаппить термины ООП в термины логической парадигмы, потому что аналитику надо уметь анализировать любой домен, в том числе и код. А для этого он должен владеть парадигмой и уметь отмаппиться с терминов ООП на термины любой из парадигм то ли типов, то ли классов. Это я показал, как сделать. не все. конечно
… вот только пост ваш не о том, как анализировать код, а о том, как ООП плохо для того, чтобы анализировать предметную область. Правда, есть разница?
Задача анализа кода неотличима от любой другой задачи анализа
Тем не менее, пост, в котором написано, что ООП не подходит для анализа предметной области, не решает задачу анализа кода как предметной области.
Не решает. он декларирует только то, что использовать ООП для анализа предметной области — нельзя. И не важно какая это предметная область.
Мне кажется, вы смешали понятие статических классов и статических элементов нестатических (экземплярных) классов.
Кроме того, вы упомянули эти вещи как средства реализации теории множеств в ОО-программировании.
Но именно злоупотребление этими вещами не по назначению, приводит к куче проблем в отладке, к трудностям сопровождения кода, к торможению и завалу проектов и т.д.
Попробуем по пунктам:
1. Статические классы это не более чем «хелперы», содержащие несколько процедур (вычисляющих 2 + 2, например, т.е. не имеющие отношения ни к конкретному типу объектов, ни к предметной области в целом), которыми мы можем пользоваться там, где нам нужно что-то вычислить, и при этом мы не хотим заниматься копи-пастом.
Статические классы — это в чистом виде процедурное программирование (то, что несколько процедур оборачиваются в отдельный статический класс, экземпляр которого нельзя создать — чистая условность, т.к. многие большинство ОО-языков не позволяют объявить процедуру вне класса — и это правильно).
Относить процедурное программирование к теории множеств перебор, иначе бы те, кого не устраивает противоречивость ООП, просто пользовались бы процедурным программированием.
2. Что же касается статических элементов нестатического класса (поля, методы), то это очень опасный инструмент — но это необходимое зло.
К теории множеств это не имеет не малейшего отношение. Назначение таких элементов чисто техническое.
Полагаю, если бы не необходимость реализации экземплярного конструктора — технически в виде статического метода — то не было бы в чистом ООП статических методов и полей в нестатических классах.
Не говорю уж таких вещах, как «статические методы» и «методы класса», которые оба являются неэкземплярными (в Delphi language есть такое) — не думаю, что стоит пытаться реализовывать теорию множеств, полагаясь на такие сугубо технические вещи.
Идея ООП в том, что есть тип данных, и экземпляры этих данных.
«Расшаривание» между экземплярами неких данных (полей) на уровне именно класса, а не специальных структур — отдельных объектов (экземпляров других классов), приводит к гарантированному завалу кода и проекта (тут и проблемы при многопоточности, и внезапное изменение данных другим экземпляром и т.д.).
Использование статических методов в нестатических классах — тоже опасная вещь, и лучше выносить их в хеплер (статический класс),
т.к. наличие в нестатическом классе статического метода имеет подводный камень:
что если, в будущем этот метод все же начнет пользоваться экземплярными данными класса (состоянием объекта)? придется объявлять метод экземплярным, а ведь есть уже куча кода, которая его вызывает и считает статическим; если вы четко видите, что метод не вынести в хелпер, значит, понимаете, что метод неразрывно связан с классом и потенциально может стать экземплярным.
3. Таким образом, для обхода ограничений и противоречивости ООП, при работе над проектом приходится для каждой сущности городить огород — конструировать одну «метасущность» из нескольких ООП-сущностей, да еще придумывать какие-то структуры для расшаривания данных между объектами — экземплярами одного типа данных.
Об этом, и то том, чего бы хотелось взамен, я уже писал в другом отзыве.
Кроме того, вы упомянули эти вещи как средства реализации теории множеств в ОО-программировании.
Но именно злоупотребление этими вещами не по назначению, приводит к куче проблем в отладке, к трудностям сопровождения кода, к торможению и завалу проектов и т.д.
Попробуем по пунктам:
1. Статические классы это не более чем «хелперы», содержащие несколько процедур (вычисляющих 2 + 2, например, т.е. не имеющие отношения ни к конкретному типу объектов, ни к предметной области в целом), которыми мы можем пользоваться там, где нам нужно что-то вычислить, и при этом мы не хотим заниматься копи-пастом.
Статические классы — это в чистом виде процедурное программирование (то, что несколько процедур оборачиваются в отдельный статический класс, экземпляр которого нельзя создать — чистая условность, т.к. многие большинство ОО-языков не позволяют объявить процедуру вне класса — и это правильно).
Относить процедурное программирование к теории множеств перебор, иначе бы те, кого не устраивает противоречивость ООП, просто пользовались бы процедурным программированием.
2. Что же касается статических элементов нестатического класса (поля, методы), то это очень опасный инструмент — но это необходимое зло.
К теории множеств это не имеет не малейшего отношение. Назначение таких элементов чисто техническое.
Полагаю, если бы не необходимость реализации экземплярного конструктора — технически в виде статического метода — то не было бы в чистом ООП статических методов и полей в нестатических классах.
Не говорю уж таких вещах, как «статические методы» и «методы класса», которые оба являются неэкземплярными (в Delphi language есть такое) — не думаю, что стоит пытаться реализовывать теорию множеств, полагаясь на такие сугубо технические вещи.
Идея ООП в том, что есть тип данных, и экземпляры этих данных.
«Расшаривание» между экземплярами неких данных (полей) на уровне именно класса, а не специальных структур — отдельных объектов (экземпляров других классов), приводит к гарантированному завалу кода и проекта (тут и проблемы при многопоточности, и внезапное изменение данных другим экземпляром и т.д.).
Использование статических методов в нестатических классах — тоже опасная вещь, и лучше выносить их в хеплер (статический класс),
т.к. наличие в нестатическом классе статического метода имеет подводный камень:
что если, в будущем этот метод все же начнет пользоваться экземплярными данными класса (состоянием объекта)? придется объявлять метод экземплярным, а ведь есть уже куча кода, которая его вызывает и считает статическим; если вы четко видите, что метод не вынести в хелпер, значит, понимаете, что метод неразрывно связан с классом и потенциально может стать экземплярным.
3. Таким образом, для обхода ограничений и противоречивости ООП, при работе над проектом приходится для каждой сущности городить огород — конструировать одну «метасущность» из нескольких ООП-сущностей, да еще придумывать какие-то структуры для расшаривания данных между объектами — экземплярами одного типа данных.
Об этом, и то том, чего бы хотелось взамен, я уже писал в другом отзыве.
Супер! Спасибо за комментарий, из которого я понял, что термины ООП весьма изворотливые))
Прикол в том, что при переводе на русский язык правильно говорить: экземпляры этих типов данных.
экземплярными данными типа))).
Я не глумлюсь! Я просто фиксирую отклонения терминов ООП от терминов русского языка.
Идея ООП в том, что есть тип данных, и экземпляры этих данных.
Прикол в том, что при переводе на русский язык правильно говорить: экземпляры этих типов данных.
метод все же начнет пользоваться экземплярными данными класса
экземплярными данными типа))).
Я не глумлюсь! Я просто фиксирую отклонения терминов ООП от терминов русского языка.
Использование статических методов в нестатических классах — тоже опасная вещь, и лучше выносить их в хеплер (статический класс), т.к. наличие в нестатическом классе статического метода имеет подводный камень: что если, в будущем этот метод все же начнет пользоваться экземплярными данными класса (состоянием объекта)? придется объявлять метод экземплярным, а ведь есть уже куча кода, которая его вызывает и считает статическим; если вы четко видите, что метод не вынести в хелпер, значит, понимаете, что метод неразрывно связан с классом и потенциально может стать экземплярным.
Тут неоднозначно. Есть больше одного случая, когда статические методы безопасны. Пара классических примеров — это фабрики (которые имеют доступ ко внутреннему состоянию объекта для его инициализации), и внутренние хелперы (которые просто не нужны всему остальному миру, поэтому спрятаны в область видимости).
1. Фабрики да, однако в данном случае их статические методы фактически играют роль конструкторов.
Более того, класс, создание экземпляров которого предусмотрено через фабрику, без фабрики, видимо, лучше вообще не употреблять и его конструктор сделать internal, и положить класс в одну сборку с фабрикой. Тогда создание только через статик-метод фабрики.
Более того, я являюсь сторонником известной концепции «конструктор не должен порождать исключений» (по причине того, чтобы не получить экземпляр класса — объект с несогласованным внутренним состоянием, т.к. уж очень многие любят подавлять исключения).
Мы не можем полагаться на реализацию «экземплярный конструктор реализован через статический метод». К экземплярным полям он имеет доступ как-то? Значит есть вероятность получения объекта в несогласованном состоянии при подавлении исключения.
А тогда, если конструктор получает на вход параметры, значения (сочетания значений) которых могут оказаться недопустимыми,
остается только идти путь:
— экземплярный конструктор класса делаем вообще закрытым (private), который получает на вход значения и без проверок значений инициализирует поля (предполагаются, что со значениями OK);
— объявляем у класса открытый (public) статик-метод, который принимает на вход параметры, проверяет их значений, если NOT OK — генерирует исключение вида ArgumentException, если OK — вызывает экземплярный конструктор, передает ему проверенные значения входных параметров, и, собственно, возвращает вновь созданный экземпляр.
Насчет закрытых методов-хелперов согласен, можно на них пойти, если они больше никому (другим классам) не нужны.
Но открытые методы — только экземплярные.
Однако, тут я не вижу с вами каких-то противоречений пока.
Это все как раз примеры того, что статики — это именно необходимый и опасный инструмент, применять его нужно к месту.
Сами средства и возможные Причины их применения — специализированные и технические.
Настаиваю на том, что их нельзя применять «концептуально» — например, для реализации теории множеств.
Более того, класс, создание экземпляров которого предусмотрено через фабрику, без фабрики, видимо, лучше вообще не употреблять и его конструктор сделать internal, и положить класс в одну сборку с фабрикой. Тогда создание только через статик-метод фабрики.
Более того, я являюсь сторонником известной концепции «конструктор не должен порождать исключений» (по причине того, чтобы не получить экземпляр класса — объект с несогласованным внутренним состоянием, т.к. уж очень многие любят подавлять исключения).
Мы не можем полагаться на реализацию «экземплярный конструктор реализован через статический метод». К экземплярным полям он имеет доступ как-то? Значит есть вероятность получения объекта в несогласованном состоянии при подавлении исключения.
А тогда, если конструктор получает на вход параметры, значения (сочетания значений) которых могут оказаться недопустимыми,
остается только идти путь:
— экземплярный конструктор класса делаем вообще закрытым (private), который получает на вход значения и без проверок значений инициализирует поля (предполагаются, что со значениями OK);
— объявляем у класса открытый (public) статик-метод, который принимает на вход параметры, проверяет их значений, если NOT OK — генерирует исключение вида ArgumentException, если OK — вызывает экземплярный конструктор, передает ему проверенные значения входных параметров, и, собственно, возвращает вновь созданный экземпляр.
Насчет закрытых методов-хелперов согласен, можно на них пойти, если они больше никому (другим классам) не нужны.
Но открытые методы — только экземплярные.
Однако, тут я не вижу с вами каких-то противоречений пока.
Это все как раз примеры того, что статики — это именно необходимый и опасный инструмент, применять его нужно к месту.
Сами средства и возможные Причины их применения — специализированные и технические.
Настаиваю на том, что их нельзя применять «концептуально» — например, для реализации теории множеств.
Более того, класс, создание экземпляров которого предусмотрено через фабрику, без фабрики, видимо, лучше вообще не употреблять и его конструктор сделать internal, и положить класс в одну сборку с фабрикой. Тогда создание только через статик-метод фабрики.
С этим согласен.
Более того, я являюсь сторонником известной концепции «конструктор не должен порождать исключений» (по причине того, чтобы не получить экземпляр класса — объект с несогласованным внутренним состоянием, т.к. уж очень многие любят подавлять исключения).
Есть языки, в которых исключение, порожденное в конструкторе, приведет к тому, что объект не будет создан вообще (например, C#).
Мы не можем полагаться на реализацию «экземплярный конструктор реализован через статический метод». К экземплярным полям он имеет доступ как-то?
Ээээ, а в чем проблема? Прелесть статического метода (по крайней мере, в C#) в том, что можно создать объект, а потом обращаться к любым его полям, потому что область видимости — внутренняя.
А тогда, если конструктор получает на вход параметры, значения (сочетания значений) которых могут оказаться недопустимыми, остается только идти путь:
Вы усложняете.
ArgumentException в конструкторе — прекрасная вещь. Чтобы далеко не ходить: конструктор FileStream может кинуть девять разных искключений.Настаиваю на том, что их нельзя применять «концептуально» — например, для реализации теории множеств.
С этим я не спорю. Для реализации теории множеств применять статические поля нельзя. При этом, как ни странно, их иногда можно применять для решения задач, про которые утверждается, что они решаются только через теорию множеств.
Есть языки, в которых исключение, порожденное в конструкторе, приведет к тому, что объект не будет создан вообще (например, C#).
Вы усложняете. ArgumentException в конструкторе — прекрасная вещь. Чтобы далеко не ходить: конструктор FileStream может кинуть девять разных искключений.
Понятно, но в общем случае (берясь за какой-то язык или его версию) нужно смотреть спецификацию — такое поведение это детали реализации конкретной версии компилятора, или же нам спецификация гарантирует это.
Т.е., экземплярный конструктор, будучи реализованным как статик-метод, что вначале делает?:
— выполняет прописанный нами код (проверки значений параметров и последующими генерацией исключений или присвоением значений полей);
— или вначале создает экземпляр, а, затем выполняет написанный нами код (проверки/исключения/присвоения значений полей).
Ээээ, а в чем проблема? Прелесть статического метода (по крайней мере, в C#) в том, что можно создать объект, а потом обращаться к любым его полям, потому что область видимости — внутренняя.
Да, упустил это момент из виду. Хотя можно и рассмотреть, как это влияет на качество кода и его сопровождаемость.
Вопрос поиска середины «возможности — строгость».
А вот обратная возможность — как вам?:
возможность из экземплярных методов получать доступ к статик-полям класса (типа данных)? А ведь, в т.ч, именно это провоцирует программистов на ложное представление, что, заведя статик-поля, можно использовать их не просто как часть типа данных, а как данные, общие для множества объектов — всех экземпляров данного класса (экземпляров типа данных).
Начале мы с вами начали немного отклоняться от темы статьи — а вот этот момент как раз по теме.
Понятно, но в общем случае (берять за какой-то язык или его версию) нужно смотреть спецификацию — такое поведение это детали реализации конкретной версии компилятора, или же нам спецификация гарантирует это.
В случае C# это гарантирует спецификация.
Т.е., экземплярный конструктор, будучи реализованным как статик-метод, что вначале делает?
Реализованный кем? Если разработчиком, то это не конструктор, а фабричный метод. А если платформой/компилятором, то это не статический метод.
А ведь, в т.ч, именно это провоцирует программистов на ложное представление, что, заведя статик-поля, можно использовать их не просто как часть типа данных, а как данные, общие для множества объектов — всех экземпляров данного класса (экземпляров типа данных).
Это представление не ложное, а истинное. Статические поля действительно можно использовать как данные, общие для конкретного множества объектов (всех экземпляров этого типа в рамках application domain, если мы говорим о .net). Вопрос в том, когда это использование оправдано, а когда — нет. И тут уже надо на примерах.
Это представление не ложное, а истинное. Статические поля действительно можно использовать как данные, общие для конкретного множества объектов (всех экземпляров этого типа в рамках application domain, если мы говорим о .net).
Предмет данной статьи как раз в том, что утверждается (мною, сама статья выше технического уровня) представление это именно ложное.
Когда вы пишите «Статические поля действительно можно использовать как данные», под словом «можно» что имеется в виду?
Что ничто не препятствует их использованию (т.е., компилятор не запрещает, а он действительно не запрещает), или с вашей точки зрения «можно» — что с точки зрения концепции можно (а, значит, и нужно) использовать эти поля как общие между всеми экземплярами типа данных (всеми элементами множества).
Поясню на примере:
в Delphi language есть секцию private, которая на самом деле никакая не private, а internal, т.к. позволяет внутри одного модуля расшаривать поля/методы/свойства класса между разными классами.
Очевидно, это «косяк» архитектуры языка, т.к. если поле помечено private, то компилятор не должен позволить обратиться к этому полю из другого класса.
Особенно, учитывая, что именно в Delphi было особенно модно внутри одного модуля писать тысячи классов.
С точки зрения ООП, есть понятие класс, и неважно где он лежит — в том же модуле/файле и т.д. Private, значит Private.
И тогда горе-программисты мне говорят — ну так и не обращайся. Да вот только суть ООП в том, чтобы здесь компилятор контролировал программиста. Программист однажды написал private (думать надо было), и все.
А иначе чем это отличается от процедурного программирования.
Появление в новых версиях секции strict private ситуации не исправляет — никто не мешает использовать обычный private, да у старый код никуда не делся.
Так и в нашем случае — что вы имеете в виду под словом «можно»? Компилятор допускает это, или «можно» вы понимаете как «нужно» (по крайней мере, в для определенных случаев)?
Так и в нашем случае — что вы имеете в виду под словом «можно»? Компилятор допускает это, или «можно» вы понимаете как «нужно» (по крайней мере, в для определенных случаев)?
Я это понимаю как «нужно (по крайней мере, для определенных случаев)». Классический пример — Int32.MaxValue.
Пример хороший, однако:
1. не является все же ли MaxValue характеристикой типа данных (тем более, что технически это не поле, а константа)?
2. если же нет, то (это не характеристика типа данных, а данные общие для всех экземпляров типа данных.
Если 1, то я хотел бы языка/платформы, которые четко отделяли бы 1 от 2 — на эту тему у меня отдельная статья есть.
Если 2 (как я понял, ваш вариант), то что получается: да, для Int32.MaxValue использование статиков оправдано. А для 95% других случаев это к чему приводить, т.е. когда механизм статиков из-за неверного понимания используется, когда нельзя?
Мне все-таки кажется, что в т.ч. об этом стать.
1. не является все же ли MaxValue характеристикой типа данных (тем более, что технически это не поле, а константа)?
2. если же нет, то (это не характеристика типа данных, а данные общие для всех экземпляров типа данных.
Если 1, то я хотел бы языка/платформы, которые четко отделяли бы 1 от 2 — на эту тему у меня отдельная статья есть.
Если 2 (как я понял, ваш вариант), то что получается: да, для Int32.MaxValue использование статиков оправдано. А для 95% других случаев это к чему приводить, т.е. когда механизм статиков из-за неверного понимания используется, когда нельзя?
Мне все-таки кажется, что в т.ч. об этом стать.
не является все же ли MaxValue характеристикой типа данных
Является.
тем более, что технически это не поле, а константа
Технически это константное поле.
если же нет, то (это не характеристика типа данных, а данные общие для всех экземпляров типа данных.
Характеристика типа данных — это, одновременно, и данные, общие для всех его экземпляров.
когда механизм статиков из-за неверного понимания используется, когда нельзя?
К сожалению, механизм статиков возможно использовать не для того, для чего его оправданно использовать. Но так бывает со многими инструментами.
И еще насчет фабрик.
Так ли необходимо, чтобы они имели доступ ко внутреннему состоянию объекта?
Пусть фабрика находится в одной сборке с классом, объекты которого мы создаем через фабрику.
Но почему бы нам поля — состояние объекта не сделать все-таки закрытыми (private, а не internal), и пусть фабрика инициализирует объекты путем вызова конструктора и передачи в него параметров (а еще лучше через статический метод Create — паттерн, описанный выше)?
Тем более, что если одно из назначений фабрики — скрытие деталей реализации объекта (т.е. возвращение экземпляра интерфейса или абстрактного класса), то не факт, что класс-реализация будет находиться именно в одной сборке с фабрикой. Это может быть и вполне самостоятельный класс, доступный для использования, а значит, и поля у него все будут private.
Так ли необходимо, чтобы они имели доступ ко внутреннему состоянию объекта?
Пусть фабрика находится в одной сборке с классом, объекты которого мы создаем через фабрику.
Но почему бы нам поля — состояние объекта не сделать все-таки закрытыми (private, а не internal), и пусть фабрика инициализирует объекты путем вызова конструктора и передачи в него параметров (а еще лучше через статический метод Create — паттерн, описанный выше)?
Тем более, что если одно из назначений фабрики — скрытие деталей реализации объекта (т.е. возвращение экземпляра интерфейса или абстрактного класса), то не факт, что класс-реализация будет находиться именно в одной сборке с фабрикой. Это может быть и вполне самостоятельный класс, доступный для использования, а значит, и поля у него все будут private.
Так ли необходимо, чтобы они имели доступ ко внутреннему состоянию объекта?
Это неправильное направление вопроса.
Если нужно, чтобы фабрика имела доступ ко внутреннему состоянию объекта, то их придется реализовывать как статический метод на этом классе.
Если это не нужно (т.е., задача фабрики не в инициализации внутреннего состояния, а, например, в выборе правильного типа), то ее не обязательно реализовывать как статический метод на этом классе (хотя контрпример тоже есть: XmlReader.Create).
Хорошие примеры подумать:
— Упомянутый вами конструктор FileStream;
— И классы XmlTextReader/XmlTextWriter, которые тоже имеют свои открытые конструкторы.
Но начиная с .NET Framework 2.0, MS создала замену: абстрактные классы XmlReader/XmlWriter, возвращающие свои экземпляры (на самом деле, понятно, реализация другая) через статические методы Create.
Почему так, и почему для тех же FileStream, StreamReader, StreamWriter по-прежнему используются конструкторы.
— Упомянутый вами конструктор FileStream;
— И классы XmlTextReader/XmlTextWriter, которые тоже имеют свои открытые конструкторы.
Но начиная с .NET Framework 2.0, MS создала замену: абстрактные классы XmlReader/XmlWriter, возвращающие свои экземпляры (на самом деле, понятно, реализация другая) через статические методы Create.
Почему так, и почему для тех же FileStream, StreamReader, StreamWriter по-прежнему используются конструкторы.
Ответ очень прост:
XmlReader.Create возвращает экземпляр некоего неизвестного пользователю типа, наследующегося от XmlReader (который абстрактный). Собственно, поэтому это фабричный метод, а не конструктор.Мы с вами, кажется, обсуждали особенности и сравнивали разные подходы инициализации объектов — конструкторы и фабричные классы (как частный случай — фабричные методы у того же самого класса).
Я задал вопрос, почему для схожих случаев, в одном случае MS использует конструкторы, а в другом — конструкторы заменила на «фабричный метод».
Вы же можете не отвечать, это вопрос как бы в воздух, для размышления. Ответ все равно только MS знает (если там вообще осмысленные причины были).
Но мне показалось, что вы ответили в стиле «Это фабричный метод, потому это фабричный метод».
Я задал вопрос, почему для схожих случаев, в одном случае MS использует конструкторы, а в другом — конструкторы заменила на «фабричный метод».
Вы же можете не отвечать, это вопрос как бы в воздух, для размышления. Ответ все равно только MS знает (если там вообще осмысленные причины были).
Но мне показалось, что вы ответили в стиле «Это фабричный метод, потому это фабричный метод».
Дело в том, что ООП подменил понятия. В ООП под классом понимается не множество, как обычно принято в математике, или лингвистике.
По первых, класс ОПП является множеством, во-вторых почему забыли про биологию, где
Домен: Эукариоты
Царство: Животные
Тип: Хордовые
Класс: Млекопитающие
Отряд: Приматы
?
Её же тоже надо поставить к стенке и расстрелять из пулемета, как она посмела порочить светлое имя класса и типа.
Это терминология существует только в биологии. Я же говорю про онтологические стандарты. Ими занимаются философы, математики, лингвисты, но не биологи и программисты.
А с чего вы взяли, что онтологические стандарты применимы к программированию? Они же к биологии не применяются? Вот и к программированию не надо их применять.
Я не применяю онтологию к программированию. Я применяю ее к описанию предметной области.
Тогда не говорите, что в ООП используются неправильные термины. В ООП используются термины из области программирования, которым вы не занимаетесь.
Да, ООП про код, а не про предметную область. Я объясняю, как строить модели предметной области, а не кода
В таком случае вся ваша статья написана на пустом месте — вы говорите о том, какие недостатки у инструмента, который по вашим же словам не предназначен для решения задачи, которую вы пытаетесь решить.
Я против применения терминов ООП к моделированию предметной области. Как только я слышу термин ООП про события, ли, процессы, то у меня возникает вопрос: понимает ли говорящий, что он говорит, или просто повторяет словарные шаблоны
К моделированию в рамках анализа или разработки/проектирования?
Если анализа — то я с вами согласен, я тоже против применения этих терминов. А если разработки/проектирования — то вы же не занимаетесь этим, какое вам дело?
Если анализа — то я с вами согласен, я тоже против применения этих терминов. А если разработки/проектирования — то вы же не занимаетесь этим, какое вам дело?
Мне никакой разницы нет, кроме того, что мне учить студента и надо дать ему все необходимые знания.
Вам учить какого студента? Разработчика или аналитика?
математика
Тогда, опять-таки, не трогайте программирование вообще и ООП в частности. Оно не имеет к вашей задаче никакого отношения.
Когда вы говорите ООП, вы имеете в виду OOP или OOD – программирование или проектирование? )
А может и вообще — объектно-ориентированную ПАРАДИГМУ???! )
или ПОДХОД?
У ООП парадигмы нет. Она не заявлена. Есть онтологический фундамент — это стандарт MOF. Он (MOF) целиком воспроизводит парадигму Аристотеля насчет типов (ставит во главу угла описание при помощи атрибутов). В онтологическом стандарте ИСО 15926 нет атрибутов, кроме тех, которые признаны первичными: ИД, ИМЯ, Время создания, Время смерти. И еще что-то, что я, возможно, забыл. Больше никаких атрибутов! Эта парадигма построена на классах, а в классах нет атрибутов. Вы же в природе их не видите? Вот и в логической модели их нет.
Я говорю про ООП подход. Потому что проектировать при помощи ООП опасно, как я постоянно утверждаю. Это вызовет трансформацию сознания (В природе появятся наследование и полиморфизм).
Подход ООП нацелен на создание работающего кода на основе созданной модели предметной области. Подход ООП нацелен только на код, но не на предметную область. Если он целится в предметную область, то надо тут же маппить термины ООП на термины русского языка, что я и показал, как надо делать. И тот, кто это делает, должен обладать очень серьезными знаниями.
Пример я привел немного раньше. Приходит ко мне программист и говорит, что он создал класс. Как я, аналитик, должен перевести это на русский язык? Он создал описание типа объектов, на основе которого машина в процессе работы создаст объекты, устроенные определенным способом. Ни о предметной области, ни о классах объектов при этом программист нам не сообщил ничего. Это просто надо понимать.
Я говорю про ООП подход. Потому что проектировать при помощи ООП опасно, как я постоянно утверждаю. Это вызовет трансформацию сознания (В природе появятся наследование и полиморфизм).
Подход ООП нацелен на создание работающего кода на основе созданной модели предметной области. Подход ООП нацелен только на код, но не на предметную область. Если он целится в предметную область, то надо тут же маппить термины ООП на термины русского языка, что я и показал, как надо делать. И тот, кто это делает, должен обладать очень серьезными знаниями.
Пример я привел немного раньше. Приходит ко мне программист и говорит, что он создал класс. Как я, аналитик, должен перевести это на русский язык? Он создал описание типа объектов, на основе которого машина в процессе работы создаст объекты, устроенные определенным способом. Ни о предметной области, ни о классах объектов при этом программист нам не сообщил ничего. Это просто надо понимать.
Да, чуть не забыл! MOF используется в ООП для описания кода, а не предметной области. Это очень важно помнить. ООП к описанию предметной области не имеет отношения даже через MOF.
Звучит как:
«Я против применения английского языка к моделированию предметной области. Как только я слышу английский язык, то у меня возникает вопрос: понимает ли говорящий, что он говорит, или просто повторяет словарные шаблоны»
«Я против применения английского языка к моделированию предметной области. Как только я слышу английский язык, то у меня возникает вопрос: понимает ли говорящий, что он говорит, или просто повторяет словарные шаблоны»
ООП можно назвать языком, но очень специфическим. Я не хочу навязывать программистам язык. Я лишь даю трактовку тем терминам, которые они употребляют в общепринятом смысле. Кроме того, я бы хотел разделить аналитиков и программистов. Все-таки аналитики работают с заказчиком, а у заказчика нет наследований и инкапсуляций. Зачем им эти термины?
Проблема в том, что быть аналитиком требуется каждому программисту, если, конечно, он не быдлокодер. А такой аналитик-программист, знающий исключительно ООП, в котором нет разграничения между множеством обьектов и типом обьектов может довольно много наворотить такого, с чем придется потом долго разбираться. И все из-за неточностей терминологии
(Вообще-то, у аналитика и программиста несколько конфликтующие интересы.)
В любом случае, аналитику-программисту нельзя писать требования, его анализ направлен только на его же реализацию, поэтому его терминологические неточности не так опасны.
В любом случае, аналитику-программисту нельзя писать требования, его анализ направлен только на его же реализацию, поэтому его терминологические неточности не так опасны.
Если аналитик не пишет требования, не вмешивается в составление тз — то какая от него польза?
Вообще-то аналитик как раз пишет требования. Это программист их не пишет. И программист вмешивается в составление ТЗ, указывая на неоднозначности и неполноту, но задача аналитика — не допустить «загрязнения» ТЗ реализацией.
Хорошо было бы понимать аналитику, что имел ввиду программист, когда сказал, что создал класс. Аналитик должен точно понимать, что программист не создавал класс объектов в предметной области, он даже не создал класс объектов в информационной системе! Он создал описание объектов, которые в процессе исполнения программы будут созданы в системе. Не больше и не меньше. Если аналитик это понимает, то ему все равно, какой язык для описания этого факта использовал программист — аналитик его понял. Но, если аналитик сидит с программистом и решает задачу описания предметной области, используя термин создадим класс, то я усомнюсь в том, что аналитик обсуждает сейчас предметную область. А это я слышу постоянно. Мы создаем классы в предметных областях! Мы производим класс полицейских, например. Это каким способом, интересно знать?
Хорошо было бы понимать аналитику, что имел ввиду программист, когда сказал, что создал класс.
Хорошо бы, но не обязательно, потому что программисту не надо бы об этом говорить аналитику.
Но, если аналитик сидит с программистом и решает задачу описания предметной области, используя термин создадим класс, то я усомнюсь в том, что аналитик обсуждает сейчас предметную область.
Правильно усомнитесь. Он обсуждает реализацию (чего ему делать не стоило бы).
Мы можем обсуждать код программиста, используя для этого логическую парадигму. И тогда код станет объектом исследования, то есть доменом для аналитика. И тогда аналитик будет маппить термины программиста на термины логической парадигмы
Всё-таки зря вы написали статью, направленную на антагонизацию и противопоставление терминологии. Гораздо лучше было бы написать статью, показывающую разумный мэппинг терминологий и онтологий аристотелевского и логического подходов, ограничения этого мэппинга, и принципы выбора подходов.
Я не знаю, как достучаться до сознания ИТишников, чтобы объяснить суть проблемы. Как только она будет понята, можно будет маппиться. К сожалению, я провел несколько лет в попытках показать, как можно отмаппиться, но меня называли сумасшедшим. Теперь я стараюсь пользоваться аргументами. Иначе не получается.
Кстати, своему сыну я показываю как то или иное отношение в природе моделируется при помощи ООП. И показываю неоднозначность решений. Как только была понята неоднозначность, сразу стало понятно, что ООП не про предметную область. Оно по код.
Кстати, Вы посмотрите, кто-то считает, что класс слонов существует не в Африке, а в информационной системе.
А в Африке не существует класса слонов. В Африке существуют слоны. А их «классы» существуют в той модели, которую вы придумали.
Это интересный вопрос. А существует ли класс слонов в природе. Если нет класса, то у какого объекта в природе мы можем указать такой параметр, как средняя высота слонов?
Средняя высота слонов класса? или типа? или чего?
Ни у какого. В природе нет такого объекта. Средняя высота слонов — это свойство в модели, которую кто-то придумал.
Я не понимаю, о чем Вы говорите, потому что, если в природе нет объекта, у которого есть свойство, которое нам дано. как известное, то такого аналитика, который придумал такое свойство надо уволить, либо наоборот, наградить за новое открытие в области онтологии. В случае награждения надо быстро пойти и всем миром поискать объект, А если его не найдем, сказать, что наша парадигма дала трещину и требует пересмотра.
Начнем с того, что если вы в присутствии биолога скажете «класс слонов», на вас тоже странно посмотрят. Слоны — это семейство слоновых, класс млекопитающих.
А во-вторых, в природе действительно нет такого объекта. Есть произвольным образом выделенная группа объектов, у которой посчитана характеристика.
А во-вторых, в природе действительно нет такого объекта. Есть произвольным образом выделенная группа объектов, у которой посчитана характеристика.
Выше я ответил на вопрос о существовании классов в логической парадигме. ИСО постулировало наличие таких объектов в природе:
К сожалению, природе забыли сказать, что она подчиняется решениям ISO.
А если серьезно, то в ISO решили, что природу можно моделировать таким образом, а не то, что в природе есть такие объекты.
А если серьезно, то в ISO решили, что природу можно моделировать таким образом, а не то, что в природе есть такие объекты.
Я указал Вам на стандарт, построенный математиками и философами. Приведите свой.
Есть тысячи стандартов, которыми пытались описать исскуственный интеллект, базы знаний и т.п. Очень плохо, что вам неизвестно, что в математике и философии далеко не одна система и далеко не один стандарт. Вам привести их ВСЕ?
Ну. я скажу так: я согласен с этим стандартом по многим причинам. Хотя бы потому что я виж уклассы также как вижу объекты классов. Это было со мной еще со школы, когда я читал Колмогорова и его заметки о логике. И осталось до сих пор
Не может быть стандарта, который описывает «как есть в мире». Конкретно взятый 15926 — это стандарт на описание (интеграцию, обмен, разделение и передачу) данных между компьютерными системами. Изначально он вообще называется «Industrial automation systems and integration—Integration of life-cycle data for process plants including oil and gas production facilities», и к природе отношение имеет постольку поскольку, но даже в теперешнем более широком его понимании это стандарт на моделирование данных.
А Вы знаете другие онтологические стандарты?
Я знаю, что человеку, для того, чтобы воспринимать действительность, не нужен стандарт, равно как он не нужен птице для того, чтобы лететь.
(а вы термин «онтология» употребляете в значении из философии или из информатики?)
(а вы термин «онтология» употребляете в значении из философии или из информатики?)
онтология употреблен в смысле учение о мире. То есть, мы пытаемся описать то, как мы види мнаш мир
Так то, как мы видим, или то, как мир устроен? Это на минуточку две разных задачи.
(и я хочу заметить, что 15926 не является ни тем, ни тем)
(и я хочу заметить, что 15926 не является ни тем, ни тем)
Мы изучаем то, как мы воспринимаем сущее. Наш мир — это наше восприятие этого сущего. Как устроено сущее никто и никогда понять не сможет. Это логически невозможно, разве выйдя за рамки логики. А вот понять воспринимаемый нами мир и то, как он устроен, мы можем. Правда и тут засада — мы всегда будем упираться в парадоксы, потому что логика по своей сути ограничена.
Как устроено сущее никто и никогда понять не сможет.
Вас не смущает тот факт, что онтология (на которую вы опираетесь) в философии (на которую вы тоже опираетесь) изучает как раз, то как устроен мир, в то время как наше восприятие мира изучает гносеология (эпистемология)?
Как устроен мир не знает никто и никто, кроме пророков на это не покушается. А кто покусится, отправляется сдавать философию
Ну то есть вы только что признали несуществующим раздел философии, на который вы опираетесь в своих суждениях. Ок.
Боюсь, что в Вашем утверждении ошибка. Философия не изучает мир, она изучает наше представление о мире. Иначе, она бы посягнула на то, что мир постижим. А это противоречит опыту
Oh, really. Расскажите это философам, посмотрим на их реакцию.
А пока две цитаты:
А пока две цитаты:
ОНТОЛОГИЯ – учение о бытии как таковом; раздел философии, изучающий фундаментальные принципы бытия, наиболее общие сущности и категории сущего.
Эпистемоло́гия — теория познания, раздел философии.
Я читаю философов, математиков, которые посвятили себя изучению искусственного интеллекта, я сам физик по образованию и работал с выдающимися физиками. Никто из них никогда не замахивался на идею описания сущего. Максимум мы пытались описать наше представление о нем. Я вырос в этой философской школе ине вижу причин ее менять. Если мне докажут, что наше представление совпадает с реальностью, я поколеблюсь. но пока никто не сумел это сделать
То, что вы выросли в этой философской школе, не означает, что она единственная (и тем более — что она верная). Как следствие, употребляя термины, будьте добры употреблять их в правильном контексте — в частности, употребляя термин «онтология», четко оговаривать, что вы имеете в виду онтологию из информатики, а не онтологию из философии.
Если человек убежден, что его чувства описывают реальность, это очень сильное утверждение, требующее доказательства
Этими доказательствами (равно как и их опровержением) занимается гносеология.
это хорошо. Но я не видел такого доказательства в натуре. Я даже не могу его себе представить, потому что оно недоказуемо с моей точки зрения, и не только с моей. Поэтому надо понять, как можно доказать тот факт, что ощущения и реальность — одно и то же, а потом только доказывать. Я не могу представить себе методы такого доказательства, хоть и видел весьма изощренные. Поэтому стоит познакомиться с методами доказательства таких утверждений, а потом и с самим доказательством. Но мне проще — у меня философ рядом и он уже все рассказал, что думает об этом.
Еще раз. Есть раздел философии — онтология. Он занимается изучением бытия. Не представления о бытии, а именно бытия. Вы можете считать, что изучать бытие невозможно, а возможно только изучать наше представление о нем. Окей, это ваше право. Но в этом случае вы не можете опираться на философскую онтологию, поскольку вы ее отрицаете. Вот и все.
Хорошо, тогда что такое бытие, если это не наше представление о сущем?
Вы не поверите, но в терминах онтологии бытие и есть сущее. Онтос — сущее, то, что существует.
Хорошо, я различаю сущее и представление о нем. И это разделение разделяют те философы, с кем я знаком. Других философов я не встречал. Познакомьте, если знаете
Кстати, у меня знакомый — работает в отделе персонала. Он говорит, что ИТишники имеют профессиональную деформацию в том, что начинают считать мир, который они видят, реальностью. И он говорит, что переобучить их крайне сложно, если вообще это надо делать. Он считает, что это делать и не надо. Однако, когда я показал ему задачи, с которыми приходится работать ИТишникам, он изменил свое мнение.
Хотелось бы прокомментировать статью, действительно замечательную.
Вот только комментарий получился развернутым, поэтому я дал его в виде отдельной статьи:
habrahabr.ru/post/249193/
Вот только комментарий получился развернутым, поэтому я дал его в виде отдельной статьи:
habrahabr.ru/post/249193/
Я не программист, и не берусь судить о тех трудностях, которые программисты испытывают от множественности реализации. Но могу догадываться. Я сталкивался с тем, что программист начинает мыслить шаблонами. То есть у него мир сужается до одного «правильного» способа моделирования. Остальные по «веским» причинам он называет «неверными». Находится другой перец, который начинает с ним спорить. И начинается холивар, какой из способов реализации модели предметной области — лучше. Ни тот ни другой не понимают, что и тот и другой способ — одинаково верны, просто все зависит от контекста, его окружающего. И вот тут начинается головная боль. Поэтому я стараюсь разрабатывать модели максимально далекие от реализации. И хочу, чтобы программисты осознавали сам процесс переноса модели в код.
И хочу, чтобы программисты осознавали сам процесс переноса модели в код.
Вам стоит понимать, что ООП это не язык описания знаний и не язык описания модели. ООП это инструмент для создания кода, он совсем не предназначен для создания серьезных моделей знаний, для таких вещей есть языки где система описания знаний и моделей зашита в самом языке.
Да, я с этим не спорю! Я именно это и имею ввиду, когда утверждаю, что ООП не надо тащить в предметную область. А те термины, что там употребляются, надо уметь сказать на русском языке. А если и тащить, то знать все камни
Если улучшить ООП так чтобы он больше соответствовал описанию модели — это бы существенно упростило перенос модели в код и сделало бы инструмент более высокоуровневым
Иначе получается, что «мне ваши онтологии и ЯВУ не нужны, мне нужен более навороченный ассемблер»
Иначе получается, что «мне ваши онтологии и ЯВУ не нужны, мне нужен более навороченный ассемблер»
Я как аналитик должен понимать, что говорит программист. То есть уметь переводить его язык на язык логической парадигмы. Для этого я представляю код как предметную область, затем произвожу его анализ и могу переводить термины программиста в термины логической парадигмы. Это нормальная практика. И я могу это делать
Хотелось бы иметь такие язык программирования, платформу разработки, теорию БД, СУБД, которые позволили бы в „нативных“ для себя терминах реализовывать модель предметной области в терминах именно теории множеств.
Мне кажется, необходимость появления таких инструментов в мейнстриме давно уже назрела.
А давайте спросим vvagr: Есть ли такие языки?
Я очень плохо разбираюсь в программировании, и в ООП ещё хуже чем в других направлениях. Поэтому для меня это во многом две области реальности со случайно совпадающими терминологиями. Однако в моделирование данных ООП проникает через объектные модели данных, и тут я разбираюсь чуть лучше. В этой области простое понимание разницы между объектами и их описаниями творит чудеса. Становится понятно, как разделить концептуальную модель и её реализацию без конфронтации.
Реализация концептуальной логической модели средствами СУБД или ООП как правило вообще проблемы не представляет. Хотя конечно если реализатор не понимает сути того, что он реализует — выгод от концептуальной модели остаётся после реализации ноль.
В обратную сторону хуже — восстановить концептуальную логическую модель по объектной или реляционной крайне сложно, чаще проще поработать со специалистом предметной области.
Реализация концептуальной логической модели средствами СУБД или ООП как правило вообще проблемы не представляет. Хотя конечно если реализатор не понимает сути того, что он реализует — выгод от концептуальной модели остаётся после реализации ноль.
В обратную сторону хуже — восстановить концептуальную логическую модель по объектной или реляционной крайне сложно, чаще проще поработать со специалистом предметной области.
Спасибо. Для разработки программы в соответствии с логической моделью надо иметь специалиста, которых я нас нет в свободном доступе. Обучать пока — тоже не обучают(. Я даже на физтехе не нашел таких курсов, кроме курсов Левенчука, но они. если и рядом, то не о программировании. Язык, или фреймвокр спас бы ситуацию. Поэтому вопрос к тем, кто знает, что такое логическая модель и знает языки программирования: есть ли такие, которые позволяют построит логическую модель в коде, имея все контролки)
Язык не спасет ситуацию, потому что владеть языком тоже нужно уметь.
Мы обучаем, курс 3 дня. Ни язык, ни фреймворк без понимания никого не спасут :-(
Запомним)
Дайте пожалуйста более подробную информацию о курсе
Мы его не то чтобы регулярно читаем, это иногда делается как заказная работа для клиентов.
Программа трёхдневного курса «с погружением» по моделированию данных по ISO — 15926 dot15926.livejournal.com/30913.html.
Ну ISO 15926, которым вдохновляется уважаемый maxstroy — это идальный пример очень развесистой онтологии, на которой демонстрируется работа со сложной моделью данных, с применением стандартных справочных данных. Можно и на других примерах структурировать, если нет нужды работать с чем-то сравнимым с инженерной сферой по сложности предметной области.
Вводная лекция для молодёжной аудитории есть онлайн — www.youtube.com/watch?v=Ioi68tNLmYw
Есть онлайн и несколько примеров обратного свойства — доклады по специальным аспектам моделирования данных для тех, кто в теме:
vimeo.com/29740919
vimeo.com/49364193
vimeo.com/69191401
vimeo.com/33273117
vimeo.com/77624514
vimeo.com/68708415
vimeo.com/65080741
Программа трёхдневного курса «с погружением» по моделированию данных по ISO — 15926 dot15926.livejournal.com/30913.html.
Ну ISO 15926, которым вдохновляется уважаемый maxstroy — это идальный пример очень развесистой онтологии, на которой демонстрируется работа со сложной моделью данных, с применением стандартных справочных данных. Можно и на других примерах структурировать, если нет нужды работать с чем-то сравнимым с инженерной сферой по сложности предметной области.
Вводная лекция для молодёжной аудитории есть онлайн — www.youtube.com/watch?v=Ioi68tNLmYw
Есть онлайн и несколько примеров обратного свойства — доклады по специальным аспектам моделирования данных для тех, кто в теме:
vimeo.com/29740919
vimeo.com/49364193
vimeo.com/69191401
vimeo.com/33273117
vimeo.com/77624514
vimeo.com/68708415
vimeo.com/65080741
Конечно есть
Я не vvagr, но в лиспе обьектная модель ближе к теории множеств — там проще реализовать «класс класса» за счет довольно мощного метаобьектного протокола. Однако проблему точного описания модели одним метаобьектным протоколом не решить. Я справляюсь с этим, разрабатывая языки предметной области, которые описывают модель лучше и понятне
Но вот почему тип был назван классом, не раскрывают.
А вы хоть раз спрашивали?
А ответ-то прост: тип в программировании шире, чем класс. Может быть тип, который не является классом.
Можете привести пример типа, который не является классом?
От языка зависит. Например, в C# — все value types.
Но к ValueTypes относятся структуры. А структуры как раз и описывают свойства, присущие определению типа данных, а именно — операции, внутреннее представление, занимаемая память. Ну, операции структура не описывает, точнее сказать операции описываются относительно структуры, ну т.е. у экземпляра этой структуры нет поведения как такового.
Взять даже тот же int, опишем его:
Тип данных: int;
Свойства: (Операции: сложение, умножение и т.д. | Внутреннее представление — набор битов (причем это скрыто от пользователя этого типа, а значит int можно считать абстрактным типом данных | Занимаемая память — зависит от разрядности целевой машины).
Взять даже тот же int, опишем его:
Тип данных: int;
Свойства: (Операции: сложение, умножение и т.д. | Внутреннее представление — набор битов (причем это скрыто от пользователя этого типа, а значит int можно считать абстрактным типом данных | Занимаемая память — зависит от разрядности целевой машины).
Но при этом структура — это не класс. QED.
Более того, в языках постарше было даже разделение на «объекты» и «простые типы», и вот все, что порождалось из классов, было объектами, а все остальное ими не было (Правда, в языках еще постарше было наоборот).
Более того, есть же вообще ОО-языки без классов.
В общем, когда вводилось понятие класса (для ООП), понятие типа в программировании уже было, и означало другое, поэтому было необходимо выбрать другой термин.
Более того, в языках постарше было даже разделение на «объекты» и «простые типы», и вот все, что порождалось из классов, было объектами, а все остальное ими не было (Правда, в языках еще постарше было наоборот).
Более того, есть же вообще ОО-языки без классов.
В общем, когда вводилось понятие класса (для ООП), понятие типа в программировании уже было, и означало другое, поэтому было необходимо выбрать другой термин.
Смешно сказать, но если система типов создана не программистами (то есть не про последовательность битов), а онтологами (то есть про реальный мир) — value types прекрасно становятся классами (множествами).Впрочем, это не может удивить никого, кто знаком с математикой. Вспомите определение натуральных чисел как классов эквивалентности конечных множеств.
Речь идет о том, что программист в программе пишет класс, а создает описание типа данных. Затем он становится аналитиком и говорит: тип и класс одно и то же. Это нормально с его точки зрения, потому что он никогда не различал эти понятия. А класс — это множество и множество отличается от объектов множества. А он начинает реально думать, что объекты множества, собранные в кучу, есть множество объектов. И сам объект множество исчезает в его сознании. Можно много говорить о то, что такое множество и чем оно задается. Я так понимаю, над этим работают со времен Фурье, когда создавалось понимание того, что такое функция. Как задать ее? Перечисление соответствий, или правилами соответствий? На основе каждого из этих определений была создана своя школа. Я не знаком с современными концепциями, но в справочнике по математике у меня картинка есть. Дело не в том, чем заданы классы. При помощи правил, или при помощи связей, главное помнить, что класс и описание объектов класса — разные вещи. Тогда тип становится описанием объектов класса. но не классом. И тогда удобно говорить: ты создал тип для описания объектов класса. А может мы создадим описание для класса, а не для объектов класса? Нам ничего не стоит это сделать? А вот этот механизм в ООП вообще отсутствует.
Да нет, ничего особо смешного. Просто в момент, когда создавали систему типов, на которой основывается ООП, создавали систему типов про биты. Так дальше и пошло.
Уточню:
Value Types в терминах современных ОО-языков это так называемые структуры.
На самом деле это те же классы (важно: в терминах ООП, не теории множеств!), отличия там чисто технические.
Если экземпляр класса (опять же, в терминах ООП) можно передавать в качестве значения параметра метода по ссылке, т.е. передается указатель на данные, то экземпляр структуры (в терминах) ООП: передается путем копирования — т.е. данные (значения полей) копируются и передаются именно они.
Можно структуру передавать и по ссылке (если выполнить так называемую «упаковку» — boxing).
Отличие между классами и структурами чисто техническое, выбирая в качестве «базы» для создаваемого вновь типа данных — структуру или класс, мы ищем баланс между экономией памяти и производительностью обработки данных.
Более того, в современных ООП языках все структуры являются потомками класса (класса!!) Object — т.к. родителя всех классов.
И еще. Да, были в более ранних языках «простые типы данных» (но это процедурная тема, и к статье отношения не имеет), а сейчас все простые типы данных реализованы как структуры (а, значит, классы).
Итого, с точки зрения предмета данной статьи, нет никакой разницы между классами (в терминах ООП) и структурами (в терминах ООП). И то, и другое — ООП-шные классы.
Поэтому в проблеме «Класс как тип данных и Класс как множество объектов» не стоит зацикливаться на технических деталях.
Иначе можно погрязнуть в технических ООП-нных чисто технических терминах — классы, структуры/value types, свойства, атрибуты, перечисления, флаги, имя им легион.
Value Types в терминах современных ОО-языков это так называемые структуры.
На самом деле это те же классы (важно: в терминах ООП, не теории множеств!), отличия там чисто технические.
Если экземпляр класса (опять же, в терминах ООП) можно передавать в качестве значения параметра метода по ссылке, т.е. передается указатель на данные, то экземпляр структуры (в терминах) ООП: передается путем копирования — т.е. данные (значения полей) копируются и передаются именно они.
Можно структуру передавать и по ссылке (если выполнить так называемую «упаковку» — boxing).
Отличие между классами и структурами чисто техническое, выбирая в качестве «базы» для создаваемого вновь типа данных — структуру или класс, мы ищем баланс между экономией памяти и производительностью обработки данных.
Более того, в современных ООП языках все структуры являются потомками класса (класса!!) Object — т.к. родителя всех классов.
И еще. Да, были в более ранних языках «простые типы данных» (но это процедурная тема, и к статье отношения не имеет), а сейчас все простые типы данных реализованы как структуры (а, значит, классы).
Итого, с точки зрения предмета данной статьи, нет никакой разницы между классами (в терминах ООП) и структурами (в терминах ООП). И то, и другое — ООП-шные классы.
Поэтому в проблеме «Класс как тип данных и Класс как множество объектов» не стоит зацикливаться на технических деталях.
Иначе можно погрязнуть в технических ООП-нных чисто технических терминах — классы, структуры/value types, свойства, атрибуты, перечисления, флаги, имя им легион.
В C# все value types являются структурами, а любая структура — потомок класса Object.
Дальше — вопрос жонглирования терминами, является структура классом.
Можно пойти и дальше:
сказать, что в C# есть простые типы данных (byte, int, long), и что это не классы и даже не структуры.
Другое дело, что в .NET эти «простым типам» соответствуют структуры (а, значит, и классы?) «Byte, Int32, Int64».
Далее следует вопрос:
а что, разве можно отделить C# от CLR и .NET?
Ведь тогда простые типы данных становятся действительно простыми типами данных.
А если и так, то в случае именно такой реализации C# это уже не будет иметь отношения к теме статьи: это процедурное программирование, а обсуждается ООП.
Дальше — вопрос жонглирования терминами, является структура классом.
Можно пойти и дальше:
сказать, что в C# есть простые типы данных (byte, int, long), и что это не классы и даже не структуры.
Другое дело, что в .NET эти «простым типам» соответствуют структуры (а, значит, и классы?) «Byte, Int32, Int64».
Далее следует вопрос:
а что, разве можно отделить C# от CLR и .NET?
Ведь тогда простые типы данных становятся действительно простыми типами данных.
А если и так, то в случае именно такой реализации C# это уже не будет иметь отношения к теме статьи: это процедурное программирование, а обсуждается ООП.
Дальше — вопрос жонглирования терминами, является структура классом.
В терминах C# — нет, не является. У них существенные отличия в поведении.
В C# достаточно строго выдерживается подход «все есть объект», поэтому с value-типами тоже можно работать как с объектами. Однако это не делает все типы данных классами.
В терминах C# — нет, не является. У них существенные отличия в поведении.Можете ли вы назвать такие отличия, которые вывели бы структуры C# из обсуждения «Классы как тип данных — Классы как множество объектов», или наоборот, ввели бы в формате «Классы как тип данных — Структуры как тип данных — Классы как множество объектов»?
В C# достаточно строго выдерживается подход «все есть объект», поэтому с value-типами тоже можно работать как с объектами. Однако это не делает все типы данных классами.
А как тогда быть с этим?:
ValueType Class
public abstract class ValueType
Предоставляет базовый класс для типов значений.
Provides the base class for value types.
Int32 Structure
public struct Int32
Structs (C# Programming Guide)
All structs inherit directly from System.ValueType, which inherits from System.Object.
Так структуры и классы одно и то же?
Или это одно в терминах .NET CLR, но разное в C# (просто реализованы через механизм классов)?
Пусть даже разное с точки зрения «чистого» C#, но вот эти отличия структур от классов позволяют ли сказать, что структуры не классы и вывести их из данной дискуссии, или наоборот, ввести, но как новую величину?
Structs (C# Programming Guide)
Within a struct declaration, fields cannot be initialized unless they are declared as const or static.
A struct cannot declare a default constructor (a constructor without parameters) or a destructor.
Structs are copied on assignment. When a struct is assigned to a new variable, all the data is copied, and any modification to the new copy does not change the data for the original copy. This is important to remember when working with collections of value types such as Dictionary<string, myStruct>.
Structs are value types and classes are reference types.
Unlike classes, structs can be instantiated without using a new operator.
Structs can declare constructors that have parameters.
A struct cannot inherit from another struct or class, and it cannot be the base of a class. All structs inherit directly from System.ValueType, which inherits from System.Object.
A struct can implement interfaces.
A struct can be used as a nullable type and can be assigned a null value.
Или все же оставим формулировку «Классы как тип данных — Классы как множество объектов», т.к. ООП-структуры с онтологической точки зрения есть ООП-классы (а если в неком языке вырождаются до «простых типов данных», то вообще не имеют отношения к данной дискуссии")?
Можете ли вы назвать такие отличия, которые вывели бы структуры C# из обсуждения «Классы как тип данных — Классы как множество объектов», или наоборот, ввели бы в формате «Классы как тип данных — Структуры как тип данных — Классы как множество объектов»?
А зачем? Противоречие классов и структур в C# возникло из вопроса, почему в ООП (которое частично реализуется C#) есть типы и классы, и они отделены друг от друга. Ответ прост: потому что изначально в ООП были типы, а потом появились классы, и их надо было различать. Я вам более того скажу, бывает ООП вообще без классов (но с типами).
В частности, критичное с точки зрения ООП различие между классами и структурами в C# — это отсутствие наследования структур (напомню, что для понятия «класс» в ООП наследование критично).
Конечно, я в курсе, было/есть ООП и без классов.
Если помните, в Pascal изначально были не классы, и даже не структуры.
Вспомните, как это называлось?
— объекты!!!
Да, и как же это звучит — экземпляр объекта! (т.е. объект это тип данных).
Зато теперь из дискуссии с вами мне понятно, что в контексте обсуждаемой статьи, нет разницы между такими «группами» ООП-типов данных, как «класс», «структура», «объект» (см. выше — объект как тип данных), и, собственно, типа данных.
Точнее, мне это и раньше было понятно, но теперь вижу, что с вами вроде не должно быть разногласий по этому вопросу?
Те, данные которые вы приводите как критические для различия классов и структур, некритичны в контексте статьи.
Тем более, что приведенное вами различие — отсутствие наследования и структур (ну надо так для реализации) можно сделать и для классов — достаточно объявить его ненаследуемым (запечатанным — sealed).
Если бы для структур не были критичны еще другие признаки (передача по значению — не по ссылке, прежде всего), то для объявление структуры достаточно было бы объявить запечатанный (sealed) класс.
Можно поднять инфу, но я почти уверен, что на уровне CLR/компилятора структура (struct) и объявляется как sealed class.
Точно так же, как статический класс есть синтаксический сахар — когда мы пишем «static class» компилятор генерирует sealed class с закрытым (private) конструктором. Если не ошибаюсь, Рихтер писал об этом в CLR via C# 2.0?
В итоге что имеем:
Одна из причин темы обсуждаемой — как раз то, что устоявшееся в ООП название «класс» для обозначения типа данных входит в противоречие с термином «класс» в теории множеств, применяемой аналитиками в онтологии.
Не находите, что в некоем воображаемом новом языке программирование было бы неплохо ввести ключевое слово type (или datatype) для обозначения типа данных, а ссылочность/значимость, запечатанность, статичность задавать всегда клювевыми словами модификаторами?:
datatype MyCar
sealed datatype Int32
static datatype MyHelper
Если помните, в Pascal изначально были не классы, и даже не структуры.
Вспомните, как это называлось?
— объекты!!!
Да, и как же это звучит — экземпляр объекта! (т.е. объект это тип данных).
Зато теперь из дискуссии с вами мне понятно, что в контексте обсуждаемой статьи, нет разницы между такими «группами» ООП-типов данных, как «класс», «структура», «объект» (см. выше — объект как тип данных), и, собственно, типа данных.
Точнее, мне это и раньше было понятно, но теперь вижу, что с вами вроде не должно быть разногласий по этому вопросу?
Те, данные которые вы приводите как критические для различия классов и структур, некритичны в контексте статьи.
Тем более, что приведенное вами различие — отсутствие наследования и структур (ну надо так для реализации) можно сделать и для классов — достаточно объявить его ненаследуемым (запечатанным — sealed).
Если бы для структур не были критичны еще другие признаки (передача по значению — не по ссылке, прежде всего), то для объявление структуры достаточно было бы объявить запечатанный (sealed) класс.
Можно поднять инфу, но я почти уверен, что на уровне CLR/компилятора структура (struct) и объявляется как sealed class.
Точно так же, как статический класс есть синтаксический сахар — когда мы пишем «static class» компилятор генерирует sealed class с закрытым (private) конструктором. Если не ошибаюсь, Рихтер писал об этом в CLR via C# 2.0?
В итоге что имеем:
Одна из причин темы обсуждаемой — как раз то, что устоявшееся в ООП название «класс» для обозначения типа данных входит в противоречие с термином «класс» в теории множеств, применяемой аналитиками в онтологии.
Не находите, что в некоем воображаемом новом языке программирование было бы неплохо ввести ключевое слово type (или datatype) для обозначения типа данных, а ссылочность/значимость, запечатанность, статичность задавать всегда клювевыми словами модификаторами?:
datatype MyCar
sealed datatype Int32
static datatype MyHelper
Точно так же, как статический класс есть синтаксический сахар — когда мы пишем «static class» компилятор генерирует sealed class с закрытым (private) конструктором. Если не ошибаюсь, Рихтер писал об этом в CLR via C# 2.0?
Статический класс — это вообще костыль, не имеющий отношения к ООП. Но формально класс.
Не находите, что в некоем воображаемом новом языке программирование было бы неплохо ввести ключевое слово type (или datatype) для обозначения типа данных, а ссылочность/значимость, запечатанность, статичность задавать всегда клювевыми словами модификаторами?
«Воображаемом»? Возьмите JavaScript, он нифига не воображаемый.
Но вообще — нет, не нахожу. В рамках ООП под классом уже понимается вполне конкретная вещь, терминология уже устоялась. Если вы хотите другую терминологию, вам придется найти другую парадигму.
Статический класс — это вообще костыль, не имеющий отношения к ООП. Но формально класс.
Здорово, что у вас есть это понимание.
Я привел его как самый простой пример синтаксического сахара, когда нам нужно свести язык и исполняющую среду.
Если вы хотите другую терминологию, вам придется найти другую парадигму.
Об этом я и пишу — в том числе тут — да, хочу другую парадигму.
Да и так ли устоялась терминология?
Хотите сказать, что термины class, struct устоялись?
А как быть с ref class и value class в C++/CLI?
А другие тогда устоялись или нет?:
sealed, final или NotInheritable?
internal или friend?
protected или family?
Это навскидку только.
Тип — это описание объектов класса, если следовать ООП, но сам класс, который есть набор объектов, не есть описание этих объектов. И надо сказать, что все, что я сейчас написал — полный бред. потому что мне пришлось говорить о совершенно разных вещах. Это все равно, что если бы меня спросили, привести пример здания, которое не является совестью. Наверно, для кого-то здание и совесть одно и то же. Но не для всех
1) По-моему, автор статьи все усложняет. Есть уже устоявшиеся термины в ООП, смысл которых всем известен.
Класс — набор объектов, обладающих общими характеристиками. Класс описывает свойства (присущие типу данных конечно же, а это: интерфейс, внутреннее представление, занимаемая память), присущие каждой сущности, относящиеся к данному классу.
Экземпляр класса — некая сущность из множества всех сущностей, относящихся к некоторому классу.
Класс — набор объектов, обладающих общими характеристиками. Класс описывает свойства (присущие типу данных конечно же, а это: интерфейс, внутреннее представление, занимаемая память), присущие каждой сущности, относящиеся к данному классу.
Экземпляр класса — некая сущность из множества всех сущностей, относящихся к некоторому классу.
Скорее автор слабо разбирается в программировании и ООП и поэтому его уносит совсем в другую степь. Это равносильно тому чтобы жаловаться что тип и класс в биологии означают не то же как в математике.
Если класс — набор объектов, обладающих общими свойствами, то Вы должны уточнить: класс объектов в системе, или в домене? Если в системе, то я не против такого определения. Только тогда синтаксис языка неверен, потому что класс в языке описывает структуру данных. а не класс объектов, созданных на основе этой структуры. Если в домене, то ООП не про домен
Хорошая статья про терминологичесекие неточности в ООП
Мне кажется, ООП делает еще одну вещь неправильно, что сказывается на всем процессе проектирования: в реальном мире мы сначала получаем объекты, а потом их классифицируем (причем один объект может принадлежать к разным классам, динамически), а в ООП мы определяем класс, полностью его описываем, а потом объекты создаем. Отсюда и часть шаблонов проектирования растет
Мне кажется, ООП делает еще одну вещь неправильно, что сказывается на всем процессе проектирования: в реальном мире мы сначала получаем объекты, а потом их классифицируем (причем один объект может принадлежать к разным классам, динамически), а в ООП мы определяем класс, полностью его описываем, а потом объекты создаем. Отсюда и часть шаблонов проектирования растет
в ООП мы определяем класс, полностью его описываем, а потом объекты создаем
Не в ООП, а в ООП, основанном на классах. Это не единственный вариант ООП (хотя и, будем честными, самый известный).
Логично. А вы знакомы с другими вариантами ООП, где описанной проблемы нет? Я просто не встречал, может вам что-то известно.
Например, ООП в динамически-типизированных языках.
… вот такая милая вещь, например: Object#extend
Хороший пример, спасибо ) Думаю, подходы ООП еще есть куда улучшать, и, на мой взгляд, лучше делать это системно, а не костылями.
Вы заметили одну из главных проблем ООП. Я не стал на ней концентрировать внимание, спасибо, что заметили! ООП действительно можно значительно улучшить, как Вы сказали.
Ну хорошо, ну разные термины в логике и ООП. Ну хорошо, пусть класс в логике это не типа объекта, а просто множество объектов этого типа. Что дальше-то? К чему вся эта такая длинная статья? Выразить то, что выражается одним предложением? Не понятно…
П.С. А еще, во многих областях знания одни и те же слова имеют разное, но устоявшееся значение. И что теперь-то? :)
П.С. А еще, во многих областях знания одни и те же слова имеют разное, но устоявшееся значение. И что теперь-то? :)
На мой взгляд, есть существенная проблема в логическом подходе. Когда мы вводи класс «красные», то подразумеваем, что в него в качестве элементов войдут все красные объекты, класс «круглые» — все круглые, то вроде все понятно: есть атрибут, признак, и все объекты обладающие им попадают в этот класс. А что войдет в класс «колеса»? Колесо — это не атрибут, не признак — это слово или понятие. Должны ли мы понимать, что в этот класс должны попасть все, на чем написано «колесо»? Или все, что подпадает подо понятие «колесо» — по сути, тип «колесо», представление, которое есть у кого-то в голове? С колесом-то еще полбеды, а есть слова, с которыми в разных головах связаны разные понятия, свои типы. И поэтому, создавать класс по имени понятия (колесо, машина, вино, философ, причина и пр.) предельно некорректно. Ведь, по сути, как образовались эти имена? Сначала был осознан класс (множество) похожих объектов, а потом этому множеству присвоено имя. Не отдельный первый увиденный куст назвали именем «куст», а только тогда, когда осознали, что таких объектов множество, то решили, что это множество может и должно быть поименовано.
Классы бывают двух типов)). Первый — это класс заданный перечислением его объектов. Второй — правилом, по которому объекты попадают в класс. Правила эти иногда находятся в головах у субъектов. И мы прекрасно понимает, что два субъекта при выборе объектов для класса где-то разойдутся во мнениях. Почему? потому что пограничные объекты буду классифицированы по-разному. Тип объектов — это нечто. что хранится в голове у субъекта индивидуально. Но типы объектов в разных головах должны быть притерты друг к другу. Иначе мы получаем хаос в общении. На эту притирку мы тратим кучу сил. И тогда тип приобретает общий для множества людей смысл и его именуют.
Так что я пока не нашел в Ваших словах противоречий со своей моделью.
Так что я пока не нашел в Ваших словах противоречий со своей моделью.
Первый — это класс заданный перечислением его объектов. Второй — правилом, по которому объекты попадают в класс.Я бы не стал разделять на эти типы, поскольку «перечисление» — это то же правило по которому объект попадает в класс. )))
Я не выявлял противоречие, а писал о моменте, который требует прояснения. Хотел указать на другой необходимый способ выделения видов классов. Одни классы образуются указанием атрибута (черный, круглый, алюминиевый), а другие — указанием типа (машина, колесо, ложка). Мало того, что вы контрабандой протаскиваете понятие «тип» в описание через классы, так еще и возникает проблема соотношение этих двух видов классов. Ведь тип (к примеру класс в ООП) описывается через набор атрибутов. То есть каждый класс вида «тип», по сути должен образовываться пересечением классов вида «атрибут». В то время как классы вида «атрибут» можно сказать, унитарны.
А нельзя ли классы вида «атрибут» считать частным случаем классов вида «тип», где тип описан через набор из единственного атрибута?
С позиции понимания предметной области это однозначно некорректно. «Тип» это всегда «что», а «атрибут» — «какой». Думаю и с формально стороны возникнут проблемы: нам придется как-то ограничивать количество атрибутов у класса вида «атрибут», то есть в любом случае отделять их от класса вида «тип». Эту проблему надо как-то иначе разрешать.
А чем, например, «красный предмет» не «что»? Всё равно ведь «красные» в контексте класса – это существительное.
То есть у нас есть понятие «красный» и понятие «колесо» и мы просто включаем в классы «красный» и «колесо» все, что по чьему-то мнение подпадает под эти понятия. При этом к классу «красный» прицепляем только один атрибут «красный», а к классу «колесо» — неограниченное количество. Ну вроде все нормально. Но ведь два вида классов как было так и осталось. Ведь ограничение на количество атрибутов должно быть формально зафиксировано: вот классы с произвольным числом атрибутов, а вот — только с одним.
Красный — это значение атрибута «цвет». Атрибуту «цвет» соответствует класс объектов, которые можно назвать «цветные». Значению атрибута соотвествует подмножество этого класса, про которые можно сказать, что они имеют красный цвет. Такми образом, атрибут и его значение — это определение класса объектов и его подкласса. Класс объектов под название колеса является подмножеством цветных объектов. Некие объекты этого множества относятся к классу красных объектов. Тем самым мы завершаем рассмотрение предметной области с точки зрения теории множеств.
To maxstroy
Я озвучил некоторую проблему. Но вы ее не прокомментировали, а только описали ваше видение до и вне проблемы. Возможно это мнимая проблема, возможно не существенная, но это надо обосновать. Существенно или не существенно, что одни классы образованы по принципу единства атрибута («красный»), а другие по указанию на тип объекта («колесо»).
Вы писали, что тип — это понятие неоднозначное, что его лучше исключить из терминологии, но оно проползает с черного входа, когда мы строим класс по принадлежности типу (колесо, автомобиль).
Я озвучил некоторую проблему. Но вы ее не прокомментировали, а только описали ваше видение до и вне проблемы. Возможно это мнимая проблема, возможно не существенная, но это надо обосновать. Существенно или не существенно, что одни классы образованы по принципу единства атрибута («красный»), а другие по указанию на тип объекта («колесо»).
Вы писали, что тип — это понятие неоднозначное, что его лучше исключить из терминологии, но оно проползает с черного входа, когда мы строим класс по принадлежности типу (колесо, автомобиль).
А какова прагматика этого разделения классов на два вида? Почему может быть важно их различать?
классы не делятся на виды. ИМХО. класс- это произвольное множество. Вот описания классов делятся. Описывать классы можно по-разному. Причина этого в желании наиболее кратко изъясняться.
Одному виду классов могут быть приписано множество атрибутов, а другому только 1. Значит формально они должны отличаться.
Не всякому классу мы приписываем тип, но тому, кому приписали, у того появляется в воображении у субъектов некое описание в виде множества моделей. Это не обязательно вербализуемые модели. Однако, какая-то часть выражается в виде набора атрибутов. набор может состоять из одного или нескольких атрибутов. Это уже не важно.
Не всякому классу мы приписываем типКак классу приписывается тип?
Классу слонов мы приписываем тип: тип слонов. А слонам с моей улицы типа не приписали. Но я среди своих друзей называю этих слонов Зайнулами. Спустя несколько лет все, кого я знаю, называют слонов с моей улицы зайнулами. И мы забыли слово слон для них, потому что мы специализировали этот тип до того, который соотносится с тем классом слонов, которые гуляют по нашей улице.
Как приписываем? Каким образом? Вот в памяти компьютера хранятся записи о классах — как там прописан тип?
В компьютере хранится информация. Она о типах, классах. объектах, каждый раз надо точно понимать, о чем эта информация. Иногда один объект способен хранить информацию обо всех трех объектах сразу. Иногда бывают очень сложные случаи.
Вы как-то все уходите от темы, от проблемы.
Давайте сформулирую вопрос просто: запись класса, в котором объединены объекты одного типа (колеса), отличается от записи класса, в котором объединены объекты с одинаковым атрибутом (красный)? (Не просто мы знаем, а формальная запись.) Существуют ли такие операции с классами, в которых мы должны различать эти вида классов?
К примеру, пересечение классов вида «атрибут» могут дать нам класс вида «тип», а пересечение классов вида «тип», дадут нам просто счетный класс. И наоборот, объединение классов вида «тип», может дать нам новый класс вида «тип» (колеса + руль = запчасти), а объединение классов вида «атрибут» не дадут нам новый класс вида «тип» (красные + зеленые = ?).
Учитывая эту особенность классов не следует ли нам их различать?
Давайте сформулирую вопрос просто: запись класса, в котором объединены объекты одного типа (колеса), отличается от записи класса, в котором объединены объекты с одинаковым атрибутом (красный)? (Не просто мы знаем, а формальная запись.) Существуют ли такие операции с классами, в которых мы должны различать эти вида классов?
К примеру, пересечение классов вида «атрибут» могут дать нам класс вида «тип», а пересечение классов вида «тип», дадут нам просто счетный класс. И наоборот, объединение классов вида «тип», может дать нам новый класс вида «тип» (колеса + руль = запчасти), а объединение классов вида «атрибут» не дадут нам новый класс вида «тип» (красные + зеленые = ?).
Учитывая эту особенность классов не следует ли нам их различать?
записи отличаются, но по сути — это разные способы выделения класса объектов. Путем ли отнесения к классу колес, или путем отнесения к классу красных объектов. Так или иначе, это способы определения класса. В теории множеств классы не имеют видов. Класс — это просто множество. Мы можем описать класс по-разному. Но от этого природа класса объектов не меняется.
Они и отличаются. Именно тем, что одному приписано много атрибутов, а другому один. Ниже вы ставите вопрос: нужно ли это игнорировать или формально учитывать? Ваш ответ, видимо, – формально учитывать.
Суть моего вопроса заключалась в том, какие существуют основания для такого выбора.
Суть моего вопроса заключалась в том, какие существуют основания для такого выбора.
Почему я игнорирую атрибуты в качестве опоры для анализа? По нескольким причинам. Во-первых, атрибутная логика имеет внутренние противоречия. Это описано как у меня в статьях. так и в книге Криса Партриджа. Во-вторых, элементарные атрибуты формируют основу для сложных. И алгебра атрибутов довольно сложна и изощренна. А главное — бессмысленна. Поэтому атрибуты — это способ порадовать себя конструкциями, которые заранее имеют ограниченное применение.
to sophist
Вот у нас два объекта-класса каждому из них приписано по одному атрибуту. Как нам определить можно или нельзя приписать еще один?
Именно именно в это и проблема: должны ли мы как-то помечать/выделять те классы, к которым больше нельзя приписать атрибутов. То есть у нас все классы равны или должны быть (не у нас в голове, а формально зафиксированные) виды классов: «тип», «атрибут», «перечисление»?
Вот у нас два объекта-класса каждому из них приписано по одному атрибуту. Как нам определить можно или нельзя приписать еще один?
Именно именно в это и проблема: должны ли мы как-то помечать/выделять те классы, к которым больше нельзя приписать атрибутов. То есть у нас все классы равны или должны быть (не у нас в голове, а формально зафиксированные) виды классов: «тип», «атрибут», «перечисление»?
А когда у нас может возникнуть ситуация, в которой мы хотим приписать новый атрибут классу, к которому новых атрибутов приписывать нельзя?
Ведь если класс действительно, по своей природе, не может содержать больше одного атрибута, то откуда мы возьмём новый?
А если, всё-таки, новый атрибут нам потребовался, значит, и соответствующий класс вовсе не обязан ограничиваться единственным атрибутом.
Может быть, вы имели в виду прикладной аспект, когда пользователь имеет техническую возможность добавить второй атрибут классу, у которого второго атрибута нет? Но чем такая ситуация отличается от ситуации, когда он же имеет возможность добавить (N+1)-й атрибут классу, у которого их N?
Ведь если класс действительно, по своей природе, не может содержать больше одного атрибута, то откуда мы возьмём новый?
А если, всё-таки, новый атрибут нам потребовался, значит, и соответствующий класс вовсе не обязан ограничиваться единственным атрибутом.
Может быть, вы имели в виду прикладной аспект, когда пользователь имеет техническую возможность добавить второй атрибут классу, у которого второго атрибута нет? Но чем такая ситуация отличается от ситуации, когда он же имеет возможность добавить (N+1)-й атрибут классу, у которого их N?
А когда у нас может возникнуть ситуация, в которой мы хотим приписать новый атрибут классу, к которому новых атрибутов приписывать нельзя?А откуда мы, а лучше сказать, программа, знает, что можно, а что нельзя? Вы при при создании класса решили, что это класс вида «атрибут», а как я узнаю про это, если заменю вас после вашего увольнения )))
Так, давайте сначала.
Мы обсуждаем вопрос, следует ли различать классы, основанные на типе, и классы, основанные на атрибуте, или следует считать вторые просто частными случаями первых.
Если их следует (формально) различать, то, с одной стороны, это различение будет заложено в программу (и она не даст, таким образом, добавить второй атрибут классу, основанному на атрибуте), но, с другой стороны, нам и не потребуется его добавлять – просто потому, что в нашей онтологии он отсутствует.
Если же не делать такого принципиального различия между классами, то программа, действительно, не будет знать, что можно, а что нельзя, но дело-то в том, что в таком случае можно будет всё. Раз класс, основанный на атрибуте, не более чем частный случай класса, основанного на типе, значит, верно не то, что ему _может_ быть приписан лишь единственный атрибут, а только то, что он единственный просто по факту.
Далее, если по факту же второй атрибут для данного класса таки лишний, то, наверное, программе было бы неплохо про это знать. Но точно так же ей было бы неплохо знать и про то, что энный атрибут лишний уже для какого-нибудь другого класса (основанного на типе).
Так какие же основания сделать выбор в пользу различения классов остаются, если принять во внимание вышеизложенное?
Мы обсуждаем вопрос, следует ли различать классы, основанные на типе, и классы, основанные на атрибуте, или следует считать вторые просто частными случаями первых.
Если их следует (формально) различать, то, с одной стороны, это различение будет заложено в программу (и она не даст, таким образом, добавить второй атрибут классу, основанному на атрибуте), но, с другой стороны, нам и не потребуется его добавлять – просто потому, что в нашей онтологии он отсутствует.
Если же не делать такого принципиального различия между классами, то программа, действительно, не будет знать, что можно, а что нельзя, но дело-то в том, что в таком случае можно будет всё. Раз класс, основанный на атрибуте, не более чем частный случай класса, основанного на типе, значит, верно не то, что ему _может_ быть приписан лишь единственный атрибут, а только то, что он единственный просто по факту.
Далее, если по факту же второй атрибут для данного класса таки лишний, то, наверное, программе было бы неплохо про это знать. Но точно так же ей было бы неплохо знать и про то, что энный атрибут лишний уже для какого-нибудь другого класса (основанного на типе).
Так какие же основания сделать выбор в пользу различения классов остаются, если принять во внимание вышеизложенное?
Например, есть класс красных предметов. Мы всегда можем специализировать класс. В случае с классом красных предметов мы можем добавить атрибут оттенок. и тогда класс красных предметов можно будет поделить на подклассы объектов с разными оттенками. А также на те объекты, которые невозможно отнести к каким-то оттенкам, потому что они переливаются всеми оттенками, например.
Поскольку любой класс можно разбить на подмножества, то нет смысла говорить о том, как эти подмножества задаются: перечислением, группой атрибутов, или атрибутом.
Поскольку любой класс можно разбить на подмножества, то нет смысла говорить о том, как эти подмножества задаются: перечислением, группой атрибутов, или атрибутом.
В случае с классом красных предметов мы можем добавить атрибут оттенок. и тогда класс красных предметов можно будет поделитьЕсли класс создан по единству «атрибута» (красный), то да, добавление нового атрибута (оттенок) разбивает его на подклассы. А если класс объединяет объекты некоторого типа (автомобили), то добавление, скажем, такого атрибута как «длина», разбивает его на подклассы? Или мы просто имеем дело с атрибутом всех элементов класса «машины»?
Атрибут «длина» требует моделирование шкалы. Проще рассмотреть упрощенную модель шкалы. Например, автомобили длиной (волны, шучу) от 0 до 1 метра будут считаться «фиолетовыми», от 1 до 10 — «зелеными», а от 10 до 100 — «красными». Таким образом, появится атрибут «цвет», который в данном контексте будет связан с длиной автомобиля. Мы же помним, что цвет как-то связан с длиной волны света? Точно также мы введем «цвет» автомобиля. И тогда мы сможем говорить, что автомобиль «красного цвета», что будет означать. что его длина от 10 до 100 метров. Таким образом, все автомобили будут разбиты на классы, а значение атрибута «цвет» будет указывать на принадлежность автомобиля тому или иному классу.
При создании шкал мы используем тот же метод разнесения объектов по классам, но просто количество классов может быть достаточно большим.
При создании шкал мы используем тот же метод разнесения объектов по классам, но просто количество классов может быть достаточно большим.
Спасибо. Формально получается, что у нас есть только классы вида «атрибут» — добавление нового значения атрибута, разбивает исходный класс на подклассы. Правда есть проблема, на которую указывали слушатели лекции Агроскина: при непрерывном спектре значений атрибута (той же длины) мы имеем неограниченное умножение числа классов.
В RDF проблема решается введением атрибутов классов. Но с позиции логического подхода — это половинчатое решение (отход на позиции ООП).
Но это не решает неформальную, понятийную проблему различения классов вида «атрибут», «тип», «перечисление». Тут надо делать отдельный анализ — не возникают ли проблемы при игнорировании вида класса? все ли операции с классами разного вида однозначны? Я ранее уже отмечал, что пересечение и суммирование классов разных видов могут приводить к разным результатам.
В RDF проблема решается введением атрибутов классов. Но с позиции логического подхода — это половинчатое решение (отход на позиции ООП).
Но это не решает неформальную, понятийную проблему различения классов вида «атрибут», «тип», «перечисление». Тут надо делать отдельный анализ — не возникают ли проблемы при игнорировании вида класса? все ли операции с классами разного вида однозначны? Я ранее уже отмечал, что пересечение и суммирование классов разных видов могут приводить к разным результатам.
Я рекомендую посмотреть учебник Колмогорова по геометрии за 8-ой класс. 
. Возможно, тогда станет ясно, что наше мышление навыворот. Нет континуума в природе. Это наша мысленная конструкция. На самом деле есть только попарное сравнение. Больше ничего. Шкала всегда имеет дискрету. Даже самая точная.
. Возможно, тогда станет ясно, что наше мышление навыворот. Нет континуума в природе. Это наша мысленная конструкция. На самом деле есть только попарное сравнение. Больше ничего. Шкала всегда имеет дискрету. Даже самая точная.Здесь же сугубо техническая (а мировоззренческая проблема) проблема: у нас есть сотни размеров автомобилей и значит каждому размеру мы должны сопоставить свой класс, так? Класс автомобилей длиной 3,50, класс автомобилей длиной 3,55 и т.д. И отдельный класс на каждое значение высоты, ширины, максимальной скорости и пр. Так?
Теперь про пересечение и объединение множеств. Если у нас есть класс красных объектов, и пусть есть класс колес. Пересечение этих классов говорит нам о множестве красных колес. Проблем не возникает. Объединение этих классов дает нам множество красных объектов и колес. Опять проблем не возникает.
Здесь большое поле для анализа (который не исчерпывается двумя вашими примерами).
Скажем, пересечение классов вида «атрибут» может быть не пустым («красные» и «круглые»). А вот пересечение классов вида «тип», должны быть пустыми: «самолет» и «кошка», «колесо» и «дерево». То есть объект может одновременно обладать несколькими атрибутами, но не может принадлежать к разным типам.
Или, например, объединение двух тип-классов всегда подпадает под новый тип-класс: колеса и двигатель = запчасти, самолет и автомобиль = транспорт, колесо и кошка = вещь. А объединение атрибут-классов дает лишь класс вида «перечисление»: красные и круглые, твердые и прозрачные.
Это я к тому, что здесь проблемное поле, которое еще надо вспахивать. Не являются классы вида «тип», «атрибут» и «перечисление» полностью «равноправными».
Скажем, пересечение классов вида «атрибут» может быть не пустым («красные» и «круглые»). А вот пересечение классов вида «тип», должны быть пустыми: «самолет» и «кошка», «колесо» и «дерево». То есть объект может одновременно обладать несколькими атрибутами, но не может принадлежать к разным типам.
Или, например, объединение двух тип-классов всегда подпадает под новый тип-класс: колеса и двигатель = запчасти, самолет и автомобиль = транспорт, колесо и кошка = вещь. А объединение атрибут-классов дает лишь класс вида «перечисление»: красные и круглые, твердые и прозрачные.
Это я к тому, что здесь проблемное поле, которое еще надо вспахивать. Не являются классы вида «тип», «атрибут» и «перечисление» полностью «равноправными».
А вот пересечение классов вида «тип», должны быть пустыми: «самолет» и «кошка», «колесо» и «дерево»
Неверно. Это как раз то, на чем Аристотель погорел. Были машины, были лодки, но появились транспортные средства, которые относились и к машинам и к лодкам одновременно. Позже этим объектам присвоили свой тип: амфибии. Или живые организмы одновременно относящиеся к людям и лошадям — кентавры. Это один из обломов Аристотеля. Выход был в том, чтобы позволить одному объекту относиться к разным типам, но это нарушало всю конструкцию. В современных языках программирования это реализуется множественным наследием. Конечно, это костыль но суть его именно в том, чтобы позволить объекту относиться к разным типам.
Объединение двух множеств: круглые и красные может породить название: шамбала. Отныне шамбала — это круглый и красный объект. Вопрос в том, дадим мы этому классу имя или не дадим.
Да, спасибо. Действительно, некоторые объекты могут относится к разным типам. Хотя разница между тип-классами и атрибут-классами все равно сохраняется, тут есть над чем подумать.
И над классом «шамбала» надо подумать: можно ли такой класс считать тип-классом или это просто класс вида «перечисление»? Тип фиксируется по прототипу, по понятию о типе и может реализовываться во множестве вариантов. А образование класса объединением двух атрибут-классов имеет совершенно другой смысл, другое содержание. Одним механическим именованием тут проблема не решается.
Будем думать.
И над классом «шамбала» надо подумать: можно ли такой класс считать тип-классом или это просто класс вида «перечисление»? Тип фиксируется по прототипу, по понятию о типе и может реализовываться во множестве вариантов. А образование класса объединением двух атрибут-классов имеет совершенно другой смысл, другое содержание. Одним механическим именованием тут проблема не решается.
Будем думать.
Амфибия — это ни автомобиль, ни лодка.
Кентавр — это ни человек, ни лошадь.
И множественное наследование — это не объект, относящийся к разным типам, это объект, экспонирующий различное поведение.
Кентавр — это ни человек, ни лошадь.
И множественное наследование — это не объект, относящийся к разным типам, это объект, экспонирующий различное поведение.
Ага, и шаман — не человек)
В общем случае, шаман — не обязательно человек.
Отнесение объекта к классу всегда зависит от того субъекта, который классифицирует объекты. Вы можете относить или не относить шамана к классу людей, но найдутся те, кто с Вами не согласится и обязательно отнесет. Так же и амфибию: кто-то захочет отнести ее к классу автомобилей, а кто-то нет. Классификация без указания точки зрения не имеет смысла.
С точки зрения предметной области термин тип и термин атрибут — разные вещи. Тип включает в себя не только перечень атрибутов, но и прочие ментальные, осязательные, обонятельные, зрительные образы. Однако, запись этих образов ложится на бумагу в виде атрибутов и доступных значений. Поэтому представление типа — это набор атрибутов. И запись типа, на мой взгляд, может состоять из одного атрибута.
Поэтому представление типа — это набор атрибутов. И запись типа, на мой взгляд, может состоять из одного атрибута.Еще раз здесь поясню: вот и получается, что класс из объектов одного типа формально отличается от класса объектов с совпадающим атрибутом (атрибуты не представляются набором атрибутов). Вопрос: это надо игнорировать или как-то формально учитывать?
класс- это просто множество объектов. Имеет это множество в воображении у субъекта тип или не имеет — влияет только на название класса. Например, класс слонов — это класс. которому соответствует тип, а класс слонов, гуляющих по моей улице — не имеет типа. Но и тот и другой класс слонов — просто класс слонов. Формально они отличаются только типом, который к ним прикреплен. Например, спустя пять лет наблюдений за слонами с моей улицы я дал им имя: Госкопарцы. С этого момента я забыл слово слон и называю их Госкопарцы.
Да, про типы — это важно. В рамках моего подхода различение искусственно. Типы — удобное название для стандартной верхушки системы классов, не более того. Если есть механизм эффективного согласования мнений и интересов сообщества пользователей — систему типов можно расширять теми типами, которые все считают необходимыми. Если механизма поиска консенсуса нет — число типов остаётся малым, никакой беды.
В системе типов ISO 15926 есть как типы, определяемые экстентом, так и типы, определяемые интентом. И даже типы, определяемые атрибутами есть (правда, на уровне классов классов, то есть тип определён как класс классов, определяемых через наличие атрибутов).
В системе типов ISO 15926 есть как типы, определяемые экстентом, так и типы, определяемые интентом. И даже типы, определяемые атрибутами есть (правда, на уровне классов классов, то есть тип определён как класс классов, определяемых через наличие атрибутов).
Меня интересует не возникают ли проблемы при операциях с классами, заданными различными способами. Интуитивно чувствуется (думаю, что можно описать и формально), что класс заданный через атрибут и класс через тип — это разные классы. Ну скажем, для тип-классов возможно указание прототипа, естественна глубокая иерархия классификации, чего нельзя сказать про атрибут-классы. Можно увидеть и разницу в смысле и результате объединения и пересечения разных видов классов.
Практически необходимые операции трудностей не вызывают. Например, берётся экстенсионально или функционально определённый класс (Колесо) и пересекается с атрибутно-определённым (Диаметр 70 см).
Проблемы возникают из-за комбинаторного взрыва — нет языка для параметрического определения классов (Диаметр X см.). Но эта проблема вроде бы из другой оперы. Или это та же проблема?
Проблемы возникают из-за комбинаторного взрыва — нет языка для параметрического определения классов (Диаметр X см.). Но эта проблема вроде бы из другой оперы. Или это та же проблема?
Спасибо. Я вроде понял, о чем я. Проблема не на уровне формальных операций в конкретной выстроенной онтологии, где все уже согласовано с помощью аксиом, а в отношениях между разными видами классов на метауровне: возможно ли какое-либо исчисление для генерации и проверки корректности онтологии на этапе ее построения, то есть создание формализма отношений между классами разных видов.
И проблема параметрического определения классов именно на на этом уровне.
Интерес мой понятен — в событийной онтологии (мы с вами вскользь ее обсуждали) возникает обратная, обсуждаемой, задача — выявление классов объектов по их событийному описанию (по потоку событий). А для этого надо иметь некоторые формальные представления об отношении классов.
И проблема параметрического определения классов именно на на этом уровне.
Интерес мой понятен — в событийной онтологии (мы с вами вскользь ее обсуждали) возникает обратная, обсуждаемой, задача — выявление классов объектов по их событийному описанию (по потоку событий). А для этого надо иметь некоторые формальные представления об отношении классов.
Ну я, как вы понимаете, не работаю с «согласованной онтологией», но и «живое» построение онтологии справочных данных, о котором я упоминал, сильно ограничивает возможности верификации. Правила сочетаемости разных классов при построении классификации конкретного объекта для верификации — описываются как паттерны (data shapes теперь вроде бы их надо называть), с практической точки зрения разумные ограничения и сочетания для конкретной предметной области проблемы не составляют.
Что касается автоматического выявления классов, то я сталкивался только с выявлением классов из инженерного текста на естественном языке, и в общем-то пришёл к выводу о наличии двух широких семейств правил — выявление таксономий из структур существительное+определения и выявление классов свойств. Противоречий между ними вроде бы не обнаружил.
А вот выявление функциональной природы каких-то классов кроме как вручную — не знаю как делать.
Что касается автоматического выявления классов, то я сталкивался только с выявлением классов из инженерного текста на естественном языке, и в общем-то пришёл к выводу о наличии двух широких семейств правил — выявление таксономий из структур существительное+определения и выявление классов свойств. Противоречий между ними вроде бы не обнаружил.
А вот выявление функциональной природы каких-то классов кроме как вручную — не знаю как делать.
Спасибо.
А как решается проблема параметрического определения классов? Ведь действительно, тут мы должны иметь неограниченный рост числа классов?
А как решается проблема параметрического определения классов? Ведь действительно, тут мы должны иметь неограниченный рост числа классов?
Дык я не знаю универсального ответа :-(
Для геометрических характеристик, таких как диаметры, длины, ширины, эксцентриситеты и координаты вообще — модели задаются через отношения со спец-объектами — числами.
Для сущностей типа 4-х болтовое соединение или 10-этажный — через кардинальности отношений.
Но если есть стандартный перечень размеров резьб, например — то только полным перечнем, даже если известна формула или шаг Х, с которым они идут от значения А до значения Б.
Для геометрических характеристик, таких как диаметры, длины, ширины, эксцентриситеты и координаты вообще — модели задаются через отношения со спец-объектами — числами.
Для сущностей типа 4-х болтовое соединение или 10-этажный — через кардинальности отношений.
Но если есть стандартный перечень размеров резьб, например — то только полным перечнем, даже если известна формула или шаг Х, с которым они идут от значения А до значения Б.
А как относится к этой проблеме: мол, иначе нельзя, весь подход без параметрического определения классов развалится? или просто желание сохранить чистоту жанра?
Ведь по сути для пользователя онтологии нет потребности в таком количестве классов — достаточно деления непрерывных величин (тех же геометрических размеров) на несколько диапазонов.
Не говорит ли нам эта проблема о некой ущербности исключительно классового подхода к моделировании предметной области? Может все же классификация по свойствам, не аналогична классификации по типам и функциям?
Ведь по сути для пользователя онтологии нет потребности в таком количестве классов — достаточно деления непрерывных величин (тех же геометрических размеров) на несколько диапазонов.
Не говорит ли нам эта проблема о некой ущербности исключительно классового подхода к моделировании предметной области? Может все же классификация по свойствам, не аналогична классификации по типам и функциям?
Тут вопрос в том, для чего пользователь онтологии её пользует. Я, опять таки, работаю с относительно узким применением — для определения некоего нейтрального формата обмена данными. Да ещё и в относительно узкой области — инженерных данных. И там, похоже, подход «сохранить чистоту» таки проиграл. Прагматические критерии для выбора онтологического подхода сохраняются — shared conceptualization is the king. А вот сохранять строгость концептуализации не удаётся. Но реально пока никто не понимает, насколько IT отрасль продвинется хотя бы от использования shared conceptualization. Поэтому никто не будет воевать за чистоту логического подхода по причине каких-то будущих проблем.
Спасибо. Многое пояснили.
от себя замечу:
1. Я считаю, что классы объектов являются такими же реальными, как объекты.
2. Типы объектов, как нечто, что существует в воображении у субъекта, также являются реальными. И также требуют умения их моделировать.
3. Поскольку объекты существуют в воображении у субъекта, то их реальность такая же как и реальность типов.
4. Свои выводы я пока не намерен привязывать к моделлеру. Поэтому количество классов меня не тревожит. Как не тревожит математика множество континуум.
1. Я считаю, что классы объектов являются такими же реальными, как объекты.
2. Типы объектов, как нечто, что существует в воображении у субъекта, также являются реальными. И также требуют умения их моделировать.
3. Поскольку объекты существуют в воображении у субъекта, то их реальность такая же как и реальность типов.
4. Свои выводы я пока не намерен привязывать к моделлеру. Поэтому количество классов меня не тревожит. Как не тревожит математика множество континуум.
На мой взгляд, проблемными в вашем комментарии являются слова «таким же», «также», «такая же»… Если речь идет просто на разделение существует/не существует, то это малосодержательно (тем более, опустив проблему «для кого существует»). Если все же подразумеваются разные формы существования (и разные реальности), то фразу «так же реальны» надо уточнять. Одинаковым существованием обладают камень и палка — первый можно прикрутить ко второй — получим молоток. А можно ли прикрутить к палке класс? И что из этого получится? Но класс можно объединить с другим классом, получив новый класс. Это другая форма существования, другая реальность.
Является ли множество реальным настолько, насколько является реальным объект этого множества?
Для меня ответ — да, является. Я могу рассматривать объекты, а могу рассматривать группы объектов. И то и другое — реально одинаково.
Для меня ответ — да, является. Я могу рассматривать объекты, а могу рассматривать группы объектов. И то и другое — реально одинаково.
Кто о чем, а я о словах )) Главная фраза в вашем ответе «я могу рассматривать». А я могу и галлюцинацию свою рассматривать — она для меня будет не менее «реальна», чем картина на стене.
Реальность прежде всего фиксируется не по достоверной данности субъекту, а по данности объекта в совместной деятельности, когда несколько человек «могут рассматривать».
Вот в нашем разговоре про колеса и автомобиль у нас не возникло ни малейшего сомнения в том, что если бы мы стояли с вами в гараже, то эти объекты били бы для нас одинаково реальны — просто взяли бы и стали вместе прикручивать колеса. А вот по поводу классов получилась неувязка: вы говорите, что можете рассматривать класс как часть машины, а я не соглашаюсь с вами. Вот вам и разная степень реальности, разные реальности.
И это не сугубо философский вопрос. Я думаю, что при построении моделей/онтологий сложных систем с множеством инкорпорированных в них субъектов следует специально рассматривать разные уровни/формы существования тех или иных объектов. Договор-бумажка, договор-текст, договор-договоренность, договор-файл, договор-учетная единица имеют разный онтологический статус, разное существования. Скажем для секретарши договор-договоренность не существует — вот текст который она набирает существует, а его содержание — нет.
Кстати, наверное, не стоит приравнивать группы объектов и классы.
Реальность прежде всего фиксируется не по достоверной данности субъекту, а по данности объекта в совместной деятельности, когда несколько человек «могут рассматривать».
Вот в нашем разговоре про колеса и автомобиль у нас не возникло ни малейшего сомнения в том, что если бы мы стояли с вами в гараже, то эти объекты били бы для нас одинаково реальны — просто взяли бы и стали вместе прикручивать колеса. А вот по поводу классов получилась неувязка: вы говорите, что можете рассматривать класс как часть машины, а я не соглашаюсь с вами. Вот вам и разная степень реальности, разные реальности.
И это не сугубо философский вопрос. Я думаю, что при построении моделей/онтологий сложных систем с множеством инкорпорированных в них субъектов следует специально рассматривать разные уровни/формы существования тех или иных объектов. Договор-бумажка, договор-текст, договор-договоренность, договор-файл, договор-учетная единица имеют разный онтологический статус, разное существования. Скажем для секретарши договор-договоренность не существует — вот текст который она набирает существует, а его содержание — нет.
Кстати, наверное, не стоит приравнивать группы объектов и классы.
Кстати, наверное, не стоит приравнивать группы объектов и классы.
Почему? Есть упорядоченные группы объектов, есть неупорядоченные. Есть упорядоченные множества объектов, есть неупорядоченные. Чем группа отличается от множества? Какие отличия?
Тем же чем «1» отличается от «одно яблоко».
Группа — это кучка болтов на складской полке, а класс (множество) — это элемент вашей модели склада с болтами. Можно сказать «подай мне вот ту группу», но бессмысленно пытаться унести в руках класс.
Группа — это кучка болтов на складской полке, а класс (множество) — это элемент вашей модели склада с болтами. Можно сказать «подай мне вот ту группу», но бессмысленно пытаться унести в руках класс.
Отлично! мы подошли к очень важному вопросу. Что есть множество? Мой отец (математик), когда я был маленький, давал мне определение множества на примере ботинок, стоящих в шкафчиках. Он показывал мне эти ботинки и говорил: вот это ботинки, посмотри на них как на множество ботинок. Я не понимал этой просьбы много лет, пока он не дал мне книгу Виленкина «рассказы о множествах». Почитайте ее. Определений множества много, но Кантор дал такое: «Множество есть многое, мыслимое нами как единое».
Очень хорошее определение «Множество есть… мыслимое ...». Группа не есть мыслимое — это то, что участвует в совместной деятельности. Мы с вами прикручиваем группу из четырех колес. А мыслим класс/множество из четырех элементов.
Вы пытаетесь прикрутить группу колес, но к группе такой глагол не применим. Есть то, что применимо к группе, например, построить группу в шеренгу. Попробуйте построить в шеренгу объект. Можно лишь говорить о том, что часть глаголов применима к объектам, а часть к группам.
Ну я, конечно, сразу группу прикрутить не могу, а робот может.
Хотя ваш пример лучше: группу можно построить в шеренгу, а класс — нельзя ))) Вот вам и отличие.
Хотя ваш пример лучше: группу можно построить в шеренгу, а класс — нельзя ))) Вот вам и отличие.
что ж, придется задать этот вопрос математикам. Боюсь, быстро получить ответ мне не удастся, но на следующей неделе задам.
Вообще это вопрос про согласование терминологии, а не про то, как правильно))
Для меня естественным кажется противопоставлять группу и класс: первое есть набор индивидов (независимо, создали мы для них класс или нет), второе — объект в нашей модели, фиксирующий в ней эту группу.
Математики тут не помогут. Тем более, у них есть термин «группа» именно как математический, а не то, что можно выстроить по линии )))
Для меня естественным кажется противопоставлять группу и класс: первое есть набор индивидов (независимо, создали мы для них класс или нет), второе — объект в нашей модели, фиксирующий в ней эту группу.
Математики тут не помогут. Тем более, у них есть термин «группа» именно как математический, а не то, что можно выстроить по линии )))
Мне кажется, что именно математик должен сказать, что он имел ввиду, когда вводил термин множество. Если Вы с этим не согласны, то скажите, кто бы мог прояснить этот термин по-вашему?
Спросил, получил ответ. Математики считают термин группа объектов и термин множество объектов — синонимами.
Спасибо. А иначе и быть же не могло. Ведь в математике нет понятия «индивид». А мы вынуждены различать (в том числе и терминологически) идет ли речь о конкретных (со своими серийными номерами) четырех колесах под машиной или о множестве/классе ее колес. Ведь понятно, что конкретная группа из четырех колес существует независимо от моделирования, а класс/множество мы вводим как объект модели. Группу из четырех колес-индивидов, я могу снять с машины и положить в угол — группа останется группой, а вот элементами класс/множества «колеса авто» они быть перестанут.
Группу нельзя снять с машины. Можно снять колеса группы. Ну, или надо переопределить термин «снять» для группы объектов, что автоматом повлечет определение термина «снять» для множества объектов.
Ну, это как сказать, что нельзя покрасить машину, можно покрасить только каждую деталь )) Я ведь точно обозначил, что назвал термином «группа» — не элемент модели (который действительно нельзя снять), а конкретные четыре индивида. То есть речь идет не о модели, а о конкретных предметах. Мы же говорим группа из четырех человек зашла в магазин. А вот класс и элементы класса зайти в магазин не могут.
Хотя опять повторю, что проблема сугубо терминологическая: хотите использовать термины «группа», «множество», «класс» как синонимы, то есть для обозначения выделенного набора объектов модели — хорошо. Для обозначения реальных колес тогда можно говорить «вот эти четыре колеса»: сними «вот эти четыре колеса» и положил их в угол — теперь в углу лежать «вот эти четыре колеса». Завтра можно взять «вот эти четыре колеса» и прикрутить их к машине. И для выполнения этих действий не надо вообще определять что такое «снять» и «прикрутить» — ведь это не элементы модели.
Тут обсуждается не правильность терминологии, а различение элементов модели а реальных вещей.
Хотя опять повторю, что проблема сугубо терминологическая: хотите использовать термины «группа», «множество», «класс» как синонимы, то есть для обозначения выделенного набора объектов модели — хорошо. Для обозначения реальных колес тогда можно говорить «вот эти четыре колеса»: сними «вот эти четыре колеса» и положил их в угол — теперь в углу лежать «вот эти четыре колеса». Завтра можно взять «вот эти четыре колеса» и прикрутить их к машине. И для выполнения этих действий не надо вообще определять что такое «снять» и «прикрутить» — ведь это не элементы модели.
Тут обсуждается не правильность терминологии, а различение элементов модели а реальных вещей.
нельзя покрасить машину, можно покрасить только каждую деталь
Вы путаете несколько уровней модели. Если я говорю, что есть автомобиль, то я его могу покрасить. Если я имею конструкцию автомобиля, то покрасить конструкцию я не могу, но могу покрасить любую деталь этой конструкции. Поэтому можно покрасить и автомобиль и каждую деталь автомобиля. Но надо понимать, что эти покраски никак не связаны друг с другом! Потому что автомобиль — это не конструкция автомобиля и не его детали. Это первое. Я же говорил совсем про другое. Я говорил, что группу колес нельзя снять, потому что не определен термин «снять» для группы объектов. В Вашем случае можно покрасить и автомобиль и детали, но нельзя покрасить группу деталей, если не переопределить термин «покрасить».
Я говорил, что группу колес нельзя снять, потому что не определен термин «снять» для группы объектов.Расскажите это Васе в гараже. ))) Я же несколько раз повторил, что говорю не о модели, а о реальном гараже, реальной машине, реальных колесах и реальном Васе, который возьмет «вот эти четыре колеса» и прикрутит их к машине даже не задумываясь как переопределить термин «прикрутить».
Он может прикрутить колесо. Он может прикрутить 4 колеса. Слово «прикрутить» в этих предложениях значит совершенно разное, хотя и звучит одинаково. В первом случае прикрутить оперирует с объектом, а во втором — с группой объектов. Как только мы определили термин «прикрутить» на группе объектов, то, поскольку термин группа объектов и множество объектов тождественны, мы автоматически определили и термин «прикрутить множество колес».
Пусть будет так. Если уж вы не различаете реальную машину, реального Васю, реальные колеса от их модели. Термины, классы, множества есть только в модели.
Конечно, и у Васи в голове есть модель его действий (правда без классов и пр.). Тогда надо говорить о различии «натуральной» модели действия в голове исполнителя и информационной модели всего действия, создаваемой аналитиком.
Но это отдельная тема.
Конечно, и у Васи в голове есть модель его действий (правда без классов и пр.). Тогда надо говорить о различии «натуральной» модели действия в голове исполнителя и информационной модели всего действия, создаваемой аналитиком.
Но это отдельная тема.
у Васи есть в голове четкая модель: то ли он прикручивает группу колес, то ли он прикручивает колеса. Он точно скажет это, если его спросить об этом. Например, в чем твоя задача, Вася? А Вася отвечает: моя задача крутить колеса весь день и получаю я за это вот столько. Менегер подходит к нему и начинает «лечить» Ты не прикручиваешь колеса! Ты обслуживаешь клиентов! Вася6 «Опа, я попал!» И посылает менегера на все четыре стороны внутренне, конечно. Так что в данном контексте Вася не прикручивает группы колес. Но приходит Петя и его менегер спрашивает: что ты собираешься делать у нас? А Петя ученый, и потому отвечает так, как хочется менегеру: Я собираюсь обслуживать клиентов, прикручивая к их машинам группу колес. Молодец, Петя, вот тебе леденец!
Если вы термин «группа» используете как синоним «класс/множество», таки, конечно, Вася не прикручивает «класс». Это мы давно выяснили. Вася прикручивает «вот эти четыре колеса», лежащие в углу.
Зачем мы толчем воду в ступе? Это же терминологическая проблема — хочется вам использовать слова «группа», «класс», «множество» как синонимы — пожалуйста. Зафиксируйте это и вася. И больше обсуждать нечего.
Зачем мы толчем воду в ступе? Это же терминологическая проблема — хочется вам использовать слова «группа», «класс», «множество» как синонимы — пожалуйста. Зафиксируйте это и вася. И больше обсуждать нечего.
Я хочу сказать, что термин группа и термин множество тождественны. То, что есть термин множество для Васи не имеет ровным счетом никакого значения. Но для меня, когда я моделирую предметную область, имеет огромное значение.
Да, конечно. Это уж кто как формирует свою терминологию.
Я бы для удобства термин «группа» использовал для обозначения нескольких реальных вещей. Сугубо для удобства языка и не введения лишних синонимов — чтобы можно было сказать «для фиксации в модели вот этой группы колес введем особый класс „колеса автомобиля“. Группу колес можно погрузить, перевести, выкинуть на свалку, чего нельзя сделать с классом.
Но опять же, повторю, это сугубо мой вариант. Вы не обязаны его принимать. Пусть для вас группа и класс будут синонимичны. Раз сказали математики, значит это закон )))
Спасибо
Я бы для удобства термин «группа» использовал для обозначения нескольких реальных вещей. Сугубо для удобства языка и не введения лишних синонимов — чтобы можно было сказать «для фиксации в модели вот этой группы колес введем особый класс „колеса автомобиля“. Группу колес можно погрузить, перевести, выкинуть на свалку, чего нельзя сделать с классом.
Но опять же, повторю, это сугубо мой вариант. Вы не обязаны его принимать. Пусть для вас группа и класс будут синонимичны. Раз сказали математики, значит это закон )))
Спасибо
Я не прочитал вашу дискуссию до конца, она многократно разветвилась и, кажется, несколько раз зациклилась :-) Поэтому отвечу тут.
Кроме классов, заданных перечислением и классов, заданных атрибутом, возникает ещё нужда в классах, заданных применением, интентом. Например, это классы функциональных объектов. Колесо — пример такого класса. Шарикоподшипник, надетый на палку в самодельном самокате — классифицируется классом Колесо.
Но проблемы в этом я не вижу. Нет единственной правильной классификации, нет единой таксономии классов. Единственная задача. которую надо решить — это уникальная идентификация классов. Нужны URI.
И, разумеется, нужны правила задания определений. Перечислением, описанием, операциями над множествами.
Если договорённости об идентификации и об определениях достигнуты — можно разрешить создание классов всем желающим.
Это я излагаю подход ISO 15926, разумеется. В его рамках модель мира может быть создана и опубликована по примерно таким правилам.
Кроме классов, заданных перечислением и классов, заданных атрибутом, возникает ещё нужда в классах, заданных применением, интентом. Например, это классы функциональных объектов. Колесо — пример такого класса. Шарикоподшипник, надетый на палку в самодельном самокате — классифицируется классом Колесо.
Но проблемы в этом я не вижу. Нет единственной правильной классификации, нет единой таксономии классов. Единственная задача. которую надо решить — это уникальная идентификация классов. Нужны URI.
И, разумеется, нужны правила задания определений. Перечислением, описанием, операциями над множествами.
Если договорённости об идентификации и об определениях достигнуты — можно разрешить создание классов всем желающим.
Это я излагаю подход ISO 15926, разумеется. В его рамках модель мира может быть создана и опубликована по примерно таким правилам.
Мое последнее видение говорит о том, что нет выбранного метода учета. Все методы равноправны. Нет ни физических ни функциональных объектов, есть просто разные методы учета объектов. Эти методы порождают разные экстенты, которые можно маппить друг на друга. Но говорить, что вот это физический, а вот это функциональный объект — оказалось бессмысленно. Этот вывод был нетривиальным, и для меня самого был неожиданностью.
Опять какая-то путаница.
Про индивиды — всё примерно так. Каждый индивид выделяется и классифицируется в зависимости от viewpoint (можете называть это «метод учёта).
Но классы, которые и используются для того, чтобы эти множественные классификации проводить — они как раз есть, и выражают „чистые“ понятия — физические, функциональные, красные, колесо, и т.д.
Про индивиды — всё примерно так. Каждый индивид выделяется и классифицируется в зависимости от viewpoint (можете называть это «метод учёта).
Но классы, которые и используются для того, чтобы эти множественные классификации проводить — они как раз есть, и выражают „чистые“ понятия — физические, функциональные, красные, колесо, и т.д.
Интересно, а как соотносятся тип-класс «колесо» и функциональный класс «колесо»? Наверное, тип-класс «колесо» это подкласс функционального класса «колесо», так?
В каком смысле? Что такое " тип-класс «колесо» "? Кто его ввёл и как определил? Если как «артефакт, отличающийся тем, что он устанавливается на оси, изготовлен специально для обеспечения перемещения методом качения тех предметов, к которым он присоединён, а также тем, что его диаметр больше ширины» — то да, подкласс.
Да именно, класс «колесо», определенный как принадлежность типу: то, что мы назовем словом «колесо» и при продаже чего будет стоять этикетка с надписью «колесо». И этот тип-класс естественно будет подклассом функционального класса «колесо», дополнительно включающего еще объекты, не относящиеся к типу «колесо», но выполняющие функцию колеса.
Понимаю, что для конкретной онтологии это различение может быть не существенно, но для понимания онтологии верхнего уровня — это принципиально. Помогает проследить генезис формирования тип-классов из функциональных классов. (На философском языке — формирование понятий из устойчивых смыслов.)
Понимаю, что для конкретной онтологии это различение может быть не существенно, но для понимания онтологии верхнего уровня — это принципиально. Помогает проследить генезис формирования тип-классов из функциональных классов. (На философском языке — формирование понятий из устойчивых смыслов.)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Особенности моделирования предметной области с помощью ООП