Как работает ООП?

Прочитал комментарий одного человека, что множественное наследование вредно и его надо избегать. Что следует думать по этому поводу и что применять в таких случаях, когда хочется его задействовать?

0

0

Имел в виду ту, которая прилагается к

Взято из работы Овчаренко А.И. Как создать свою экспертную систему , Высшая школа, М:2002

0

supmener, Учитывая то огромное количество болезней и еще более огромное количество признаков этих болезней, это как раз тот случай, когда вся информация должна хранится в мощной базе данных (БД). И не исключаю, что поиск болезней нужно осуществлять с помощью мощной СУБД.
А питон можно использовать для отработки модели алгоритма работы такой программы на СУБД, взяв для начала, при отладки такого алгоритма, небольшой объем данных из небольшого количества болезней, но имеющих сходные признаки.
По ходу будет видно, может результаты получаемые с помощью СУБД, потом обрабатывать с помощью питона, для решения задачи с использованием искусственного интеллекта (ИИ).

Добавлено через 2 минуты

Сообщение от supmener Как создать свою экспертную систему

Это как раз область ИИ.

Добавлено через 4 минуты
Если же при использовании питона не будет хватать производительности, то после отработанной на питоне модели, переписать задачу на С/C++, может на С# . Я в линейке Си не спец.

1

Кстати, в ряде случаев табличным диагностическим данным присваивают значимость (весомость) в виде баллов и применяют формулу Байеса.

Добавлено через 4 минуты

Сообщение от Viktorrus Учитывая то огромное количество болезней и еще более огромное количество признаков этих болезней

Делая специализированные программы, можно избежать учета огромного количества болезней. Отталкиваясь от симптомов, которые описал на первой странице темы, например.

0

Сообщение от dondublon Быстрее - просто ноль.

Тут вы не правы. Скорость работы все равно пропорциональна количеству признаков, в т. ч. O(K). Глупо с этим спорить.

Сообщение от dondublon + Накладные расходы на создание множества + расходы на хеширование + перебор.

Они не так критичны. Тогда как индусский код в виде стены if-elif - мрак еще тот.

Сообщение от dondublon Решение с функциями не содержит проблемы "расшириить тип" в принципе.

Отнюдь. Оно плохо во всех смыслах. Как вы будете изменять API своего мед. сервиса, когда вашим API пользуются десятки тысяч клиентов, которые категорически отказываются обновляться до новой версии?
Допустим, один клиент попросит добавить признак болезни: например, тремор, другой - категорически отказывается его таковым признавать. Деплоить еще две версии API? Не забываем также про обеспечение работы старых версий.

Сообщение от dondublon Я могу точно также спросить, как хранить и поддерживать ваши множества.

Поддерживаются элементарно. Не сложнее добавления новой константы в список (множество).

Сообщение от dondublon А если ваши енумы заменить на строки - будет ещё бОльшая гибкость.

Элементарно заменяются. Enum - перечисления. В них значения констант могут быть любого типа, какого пожелаете.

Сообщение от dondublon Вопрос вам. Что будет, если какой-нибудь признак перестанет быть нужным? Просто удалить? А в объектах останется этот мусор с его значениями?

Как вы будете чистить, например, 10 ТБ накопленных данных от лишнего признака (в т. ч. мусора)? У 10 триллионов объектов будет 10 триллионов признаков, которые нужно удалить.
Тогда как, если делать через сводную таблицу - достаточно удалить 1 значение: признак - все! Больше никаких изменений в программе делать не нужно*. (*При условии адекватного проектирования системы.)

0

Кроме симптомов, есть такое понятие - синдром. Может быть, как синонимом симптома, так и обозначать название одновременного наличия нескольких симптомов. Может быть самостоятельным диагнозом в одних случаях, так и указывать на какую - то болезнь.
Примеры ниже.

Симптом Боткина.
Синоним: холецисто-коронарный синдром.
Боткина с. – кардиалгия, наблюдаемая при холецистите. Проявляется колющей, схваткообразной болью в области сердца, левой лопатки и левого плеча, иррадиирующей из верхней половины живота. Часто предшествует желчной колике или сопровождает ее. Могут быть изменения на ЭКГ.

Холецистит – общее название группы заболеваний, которые приводят к развитию воспалительных процессов в желчном пузыре (medicina.ru)

Из Википедии:
Холецисти́т (от др.-греч. χολή «жёлчь» + κύστις «пузырь»)[3]) — воспаление желчного пузыря — одно из наиболее частых осложнений жёлчнокаменной болезни. Основные принципы развития воспалительного процесса в стенке желчного пузыря: наличие микрофлоры в просвете пузыря и нарушения оттока желчи.
Ведущим фактором развития острого холецистита является нарушение оттока желчи из желчного пузыря, что возникает при окклюзии камнем шейки желчного пузыря или пузырного протока. Второстепенное значение в развитии острого воспаления имеет нарушение кровоснабжения стенки желчного пузыря при атеросклерозе висцеральных ветвей брюшной аорты и повреждающее действие панкреатического сока на слизистую оболочку желчного пузыря при рефлюксе секрета поджелудочной железы в желчные протоки.
Классификация
Холецистит делится на 2 типа:
Острый (калькулезный). Клинико-морфологическая классификация острого холецистита:
Катаральный холецистит. Его симптомы — интенсивные постоянные боли в правом подреберье и эпигастральной области с иррадиацией в поясничную область, правую лопатку, надплечье, правую половину шеи.
Флегмонозный холецистит имеет более выраженную клиническую симптоматику. Боли значительно интенсивнее, чем при катаральной форме воспаления. Боли усиливаются при дыхании, кашле, перемене положения тела. Чаще возникает тошнота и многократная рвота, ухудшается общее состояние больного, температура тела достигает фебрильной, тахикардия возрастает до 110—120 в минуту. Живот несколько вздут за счет пареза кишечника; при дыхании правая половина передней брюшной стенки отстает от левой, защитно напряжена в правом подреберье при пальпации; кишечные шумы ослаблены.
Гангренозный холецистит характеризуется бурным клиническим течением, обычно является продолжением флегмонозной стадии воспаления, когда защитные силы организма не в состоянии справиться с вирулентной микробной флорой.
Хронический

Синдромы при холецистите.
Синдром Bard — Pic.
Синдром Pic, синдром Courvoisier — Terrier, syndromus pancreaticobiliaris.
Бара — Пика с. – симптомокомплекс, развивающийся при сдавлении желчных протоков увеличенной поджелудочной железой: обычные симптомы опухоли поджелудочной железы —
увеличение печени и желчного пузыря, который обычно хорошо прощупывается; хроническая прогрессирующая обструктивная (подпеченочная) желтуха, ахолия; в поздних стадиях кахексия.
Синдром Fitz—Hugh.
Синонимы: подреберный синдром Стояно (Stajano), гонококковый перитонит верхней половины брюшной полости, синдром Фитца - Хью – Куртиса (Curtis).
Фитца - Хью с. – может симулировать острый холецистит: боль в верхней половине живота справа, тошнота, рвота, жар, лихорадка, потливость, головная боль. Появляется у молодых женщин при гонококковом воспалении тазовых органов.
Синдром Mirizzi, morbus Mirizzi, stenosis ductus hepatici.
Мирицци с. – обозначение клинической картины закупорки общего желчного протока различной этиологии (спазм, воспаление, опухоль, камни): неопределенная боль в правом подреберье и эпигастрии, тошнота, желтуха, гипербилирубинемия; часто прощупывается увеличенный болезненный желчный пузырь; нередко — картина острого живота.
Синдром Osler.
Ослера с. – перемежающая желтуха с лихорадкой и ознобом у больных желчнокаменной болезнью.
Синдром Villard.
Синоним: триада Вилляра.
Вилляра с. – характерно для холедохолитиаза: колика в правой подреберной области, жар, желтуха.
Синдром Walter - Bohmann.
Вальтера—Бомана с. – развивается после холецистэктомии или холецистодуоденостомии характеризуется тахикардией, гипотермией, одышкой, бледностью кожных покровов. Может наступить смертельный исход.
Из книги Андросова Н.С. - Симптомы и синдромы в хирургии

0

Сообщение от supmener Может быть, как синонимом симптома, так и обозначать название одновременного наличия нескольких симптомов.

Ты сам ответил на свой вопрос. Именованное множество симптомов есть синдром.

0

Сообщение от Arsegg Тут вы не правы. Скорость работы все равно пропорциональна количеству признаков, в т. ч. O(K). Глупо с этим спорить.

Под "количеством признаков" можно понимать разные вещи. Если кол-во запрошеных признаков - N, а среднее, которое у объекта - К, то с функциями будет O(N), с множествами - O(N)*O(K). Глупо с этим спорить.

Сообщение от Arsegg Они не так критичны. Тогда как индусский код в виде стены if-elif - мрак еще тот.

Где вы увидели if-elif?

Сообщение от Arsegg Отнюдь. Оно плохо во всех смыслах. Как вы будете изменять API своего мед. сервиса, когда вашим API пользуются десятки тысяч клиентов, которые категорически отказываются обновляться до новой версии? Допустим, один клиент попросит добавить признак болезни: например, тремор, другой - категорически отказывается его таковым признавать. Деплоить еще две версии API? Не забываем также про обеспечение работы старых версий.

Ещё раз - это баланс между гибкостью и структурированностью. Изменение API - это нормально, решения есть, в зависимости от обстоятельств.
С функциями - это общепрнятный стадартный подход, посмотрите, что делают джанго и SqlAlchemy. Ваше решение - это самопал, из-за желания сделать слишком гибко.
Насчёт разногласия между клиентами - ну сорри, они разрешаются также, как и со множествами. Либо добавляем, либо нет.

Сообщение от Arsegg Поддерживаются элементарно. Не сложнее добавления новой константы в список (множество).

Ну так и с функциями - добавление нового значения добавляется элементарно.

Сообщение от Arsegg Элементарно заменяются. Enum - перечисления. В них значения констант могут быть любого типа, какого пожелаете.

Я в курсе. Это была реплика об излишней гибкости. Как вы собираетесь хранить ваши данные? Пиклить?

Сообщение от Arsegg Как вы будете чистить, например, 10 ТБ накопленных данных от лишнего признака (в т. ч. мусора)? У 10 триллионов объектов будет 10 триллионов признаков, которые нужно удалить.

Вот тут вы как раз обнажили слабое место вашего подхода (одно из). Нет 10 триллионов признаков. Есть один признак, который нужно удалить. И, чтобы его удалить из 10 триллионов объектов, вам надо будет все их обойти и поменять множества.
В случае таблицы - просто удаляем колонку. БД это делает быстро. Джанго может это корректно обработать.

Сообщение от Arsegg Тогда как, если делать через сводную таблицу - достаточно удалить 1 значение: признак - все! Больше никаких изменений в программе делать не нужно*. (*При условии адекватного проектирования системы.)

Если делать через сводную таблицу, потребуется проход. Один, полный. Не смертельно, но тем не менее. И у сводная таблица даёт дополнительную сложность, как было сказано выше. Её имеет смысл использовать, если у нас на самом деле связь many-to-many.

0

Сообщение от dondublon Если кол-во запрошеных признаков - N, а среднее, которое у объекта - К, ..., с множествами - O(N)*O(K)

Тут вы опять не правы. Поиск в хеш-таблице выполняется за O(1) => поиск N запрошенных признаков за O(N). Никаким O(N * K) здесь даже близко не пахнет. Поиск в множестве не зависит от количества элементов в нем - только от выбора хеш-функции и насколько равномерно она распределяет ключи.
Proof: 1 и 2.

Сообщение от dondublon Вот тут вы как раз обнажили слабое место вашего подхода (одно из). Нет 10 триллионов признаков. Есть один признак, который нужно удалить. И, чтобы его удалить из 10 триллионов объектов, вам надо будет все их обойти и поменять множества.

Никакие множества признаков у объектов типа болезнь менять не нужно. Индекс будет просто указывать на несуществующий признак, в т. ч. null (NULL/None). Либо просто помечаем, как удаленный (признак).

Сообщение от dondublon В случае таблицы - просто удаляем колонку. БД это делает быстро. Джанго может это корректно обработать.

БД-то конечно обработает. А код клиентов кто будет править? Когда, вдруг, программа кидает NPE (или AttributeError, в случае Python) - в случае мед. систем - это критический недочет, т. к. в случае ошибок от этого зависит здоровье людей.

Сообщение от dondublon И у сводная таблица даёт дополнительную сложность, как было сказано выше.

При этом полностью обоснованную и полностью подходящую под условия задачи.

Сообщение от dondublon Её имеет смысл использовать, если у нас на самом деле связь many-to-many.

Она самая.

1

Сообщение от Arsegg Тут вы опять не правы. Поиск в хеш-таблице выполняется за O(1) => поиск N запрошенных признаков за O(N). Никаким O(N * K) здесь даже близко не пахнет. Поиск в множестве не зависит от количества элементов в нем - только от выбора хеш-функции и насколько равномерно она распределяет ключи.

Если бы поиск был за нулевое время, он был бы не поиск, а просто взятие по индексу. Конечно, это не перебор, но хеш, сравнение, а ещё бывают коллизии. В общем, на 10 триллионах будет чувствительно. Куда медленнее, чем просто взять значение (конечно, если оно уже есть в памяти).

Сообщение от Arsegg P. S. Полагаю, вы Data-Scientist? Я просто не могу понять, как можно на такой простой задаче настолько не сойтись в мнениях...

Нет. По табличкам работал в нефтянке, много циферок. Реально много, и они должны были работать быстро.

Сообщение от Arsegg БД-то конечно обработает. А код клиентов кто будет править

Вы сами предложили один из вариантов:

Сообщение от Arsegg . Индекс будет просто указывать на несуществующий признак, в т. ч. null (NULL/None). Либо просто помечаем, как удаленный (признак).

Сообщение от Arsegg Когда, вдруг, программа кидает NPE (или AttributeError, в случае Python) - в случае мед. систем - это критический недочет, т. к. в случае ошибок от этого зависит здоровье людей.

Хендлится элементарно. А вот что хендлить со множеством - даже не сразу поймёшь. Если есть что-то в множестве, и внизапно оказалось, что оно не имеет значения. К примеру, оно будет не равно другому множеству, без этого элемента - хотя. по смыслу, должно. Чрезмерная гибкость.

В общем, я устал спорить. Проектируйте, как считаете нужным.

1

0

Сообщение от dondublon Если бы поиск был за нулевое время, он был бы не поиск, а просто взятие по индексу.

При идеальной хеш-функции (вики) поиск в хеш-таблице работает, как раз, за "взятие индекса", т. к. коллизий нет => следовательно происходит однозначное отображение ключей в индексы.

Сообщение от dondublon А вот что хендлить со множеством - даже не сразу поймёшь.

Я не исключал дальнейшей нормализации базы данных. Ее можно запустить в фоне, отдельным потоком - на работоспособность системы она не повлияет. Когда она завершится - AsyncTask'а вернет значение.

Сообщение от dondublon В общем, я устал спорить.

Аналогично. С другой стороны в споре рождается истина.

0

Сообщение от Arsegg , т. к. коллизий нет => следовательно происходит однозначное отображение ключей в индексы.

Вообще-то разрешение коллизий - это главное, чем занимается структура данных на хеш-таблицах. Иначе не стоило бы огород городить.

0

Сообщение от dondublon Вообще-то разрешение коллизий - это главное, чем занимается структура данных на хеш-таблицах.

Хеш-таблица коллизиями не занимается - разрешением коллизий занимается программист:
1) Подбором правильной хеш-функции;
2) Открытой адресацией (последовательный, линейный и квадратичный поиски);
3) С помощью связного списка;
4) С помощью красно-черного дерева (или любым другим сбалансированным деревом поиска);
5) Двойного хеширования.
Почитать можно тут: Разрешение коллизий.

P. S. Конкретно для данной задачи подходит нахождение идеальной хеш-функции (без коллизий), т. к. набор ключей (перечисление признаков) - заранее известная величина. То, как она находится - это совершенно другая история, достойная отдельной статьи.

0

Сообщение от Arsegg Хеш-таблица коллизиями не занимается - разрешением коллизий занимается программист: 1) Подбором правильной хеш-функции;

Когда вы создаёте питоновский словарь или множество, вы сами его програмимруете? И да, я сказал не "хеш-таблица занимается", а "структура данных на хеш-таблицах".

0

Сообщение от dondublon Когда вы создаёте питоновский словарь или множество, вы сами его програмимруете? И да, я сказал не "хеш-таблица занимается", а "структура данных на хеш-таблицах".

Разрешением коллизий занялся автор, кто написал set'ы. Он их разрешил открытой адресацией и random-probing. Proof: 1 и 2:

After LINEAR_PROBES steps, we then use open addressing with the upper bits from the hash value. This helps break-up long chains of collisions.

P. S. Тут уже дело ваше, как программиста: пользоваться или нет данной реализацией или воспользоваться другой (написать свою).

0

А когда класс наследует другой класс, который наследует ранее описанный класс. Это не является вредным множественным наследованием?

0

Нет

1

А как называется такой вид наследования?

0

Наследование

1