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

@supmener · Регистрация: 26.06.2013

Студворк — интернет-сервис помощи студентам

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

@Arsegg · 09.02.2021, 13:36

Сообщение от dondublon

Enum тут не надо. Просто как функции или проперти.

Как не надо? Возьмем простуду и понос. Что тут общего?

Python
1
2
3
@property
def hasCouph():
    pass

Python
1
2
3
@property
def hasDiarrhea():
    pass

И т. д.
Выглядит кринжово... 100500 симптомов в одном классе, в лучшем случае 3-5 штук понадобятся...

Мой вариант:

Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
In [1]: from enum import auto, Enum
 
In [2]: class Symptom(Enum):
    ...:     COUGH = auto()
    ...:     DIARRHEA = auto()
    ...:     TEMPERATURE = auto()
    ...:     ...
    ...:
 
In [3]: class Illness(object):
    ...:     def __init__(self, *args):
    ...:         self._symptoms = set(args)
    ...:
    ...:     @property
    ...:     def symptoms(self):
    ...:         return self._symptoms
    ...:
 
In [4]: flue = Illness(Symptom.COUGH, Symptom.TEMPERATURE)
 
In [5]: diarrhea = Illness(Symptom.DIARRHEA, Symptom.TEMPERATURE)
 
In [6]: print(flue.symptoms)
{<Symptom.COUGH: 1>, <Symptom.TEMPERATURE: 3>}
 
In [7]: print(diarrhea.symptoms)
{<Symptom.DIARRHEA: 2>, <Symptom.TEMPERATURE: 3>}

@dondublon · 09.02.2021, 13:52

Сообщение от supmener

А как потом разделять кашель на подвиды?

Через Enum, но это не относится к классам и наследованию.

Добавлено через 1 минуту
Arsegg, я понял вашу мысль, но это абсолютно непрактично.

Со свойствами\пропертями выглядит отлично, это стандартный подход. Легко делать выборки, легко ложится на ORM (чтобы засунуть в БД).

@Arsegg · 09.02.2021, 13:59

Сообщение от supmener

А как потом разделять кашель на подвиды?

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

P. S. Я бы опять сделал enum CoughType и хранил в качестве значения для ключа Symptom.Cough в словаре.
/upd

Сообщение от dondublon

но это абсолютно непрактично.

В чем именно? Я, к сожалению, не уловил вашу мысль... Буду рад, если представите свое решение на обозрение!

@supmener · 09.02.2021, 14:00 **[ТС]**

А как мне таскать рядом с англоязычным названием болезни или симптома русское название, чтобы оно было поблизости и видно было, что это одно и тоже, чтобы не ошибся?

Если название класса, то возможно можно использовать __doc__
А как быть с остальным?

@Arsegg · 09.02.2021, 14:02

Не по теме:

Сообщение от supmener

А как мне таскать рядом с англоязычным названием болезни или симптома русское название, чтобы оно было поблизости и видно было, что это одно и тоже, чтобы не ошибся?

Ты принципиально отказываешься читать соответствующую литературу и документацию или как?

@Welemir1 · 09.02.2021, 14:05

Не по теме:

Arsegg, сразу видно что ты не родной питонист,а пришел из другого ЯП, столько енамов мы еще не видели)))

@supmener · 09.02.2021, 14:08 **[ТС]**

Сообщение от Arsegg

Ты принципиально отказываешься читать соответствующую литературу и документацию или как?

Не могли бы Вы подсказать ключевые слова или идею?

@Arsegg · 09.02.2021, 14:11

Не по теме:

Сообщение от Welemir1

сразу видно что ты не родной питонист,а пришел из другого ЯП, столько енамов мы еще не видели)))

Ява, родненькая)))

Не по теме:

Сообщение от supmener

Не могли бы Вы подсказать ключевые слова или идею?

Что подсказать? Правила форума п. п. 4.4:

На каждый вопрос создавайте по одной теме - это помогает избежать путаницы в ответах и облегчает поиск.

@supmener · 09.02.2021, 14:14 **[ТС]**

Так примеры кода в этой теме могут учитывать этот нюанс, если это не сложно программисту, который дает совет. Так как нужное решение возможно может совсем получиться другим с учетом этой особенности.

@Arsegg · 09.02.2021, 14:19

Не по теме:

Сообщение от supmener

Так как нужное решение возможно может совсем получиться другим с учетом этой особенности.

За сим откланиваюсь и тред покидаю...

@dondublon · 09.02.2021, 14:20

Сообщение от Arsegg

В чем именно? Я, к сожалению, не уловил вашу мысль... Буду рад, если представите свое решение на обозрение!

Так я ж сказал, функциями\пропертями. И даже объяснил, почему.
1.

Сообщение от dondublon

Легко делать выборки,

Поробуйте с вашим подходом сделать выборку, из кучи больных с типом кашля == my_cough_type (некое условное обозначение).

Python
1
2
for person in array:
   if my_cough_type in person.symptoms:

Это чё такое, ваще? Во-первых, медленно, во-вторых, немасштабируемо. И, кстати, не защищено от ошибки с двумя добавленными типами кашлей.

2.

Сообщение от dondublon

легко ложится на ORM (чтобы засунуть в БД).

Ну попробуйте засунуть это в БД. Теоретически, конечно, возможно. С дополнительной таблицей для связей many-to-many. Оно того стоит? Вот честно?

С функциями - всё получается отлично. Таблица больных просматривается на ура - причём под капотом может быть любой вид. Хоть питоновские объекты в памяти, хоть pandas dataframe, хоть джанга со своей БД.

@Arsegg · 09.02.2021, 15:05

Сообщение от dondublon

Поробуйте с вашим подходом сделать выборку

Python
1
2
3
4
5
In [1]: {Symptom.COUGH, Symptom.TEMPERATURE} <= flue.symptoms
Out[1]: True
 
In [2]: {Symptom.DIARRHEA, Symptom.TEMPERATURE} <= diarrhea.symptoms
Out[2]: True

Сообщение от dondublon

Во-первых, медленно

O(K), где K - количество признаков. Куда быстрее?

Сообщение от dondublon

во-вторых, немасштабируемо

Пока ТС не приведет полную спецификацию - это будет "игрой в бисер". Каждое новое условие будет противоречить предыдущему. Я привел самое разумное (и при этом простое) решение для классов болезнь и их признаков. Про тип кашля в изначальном условии не было и речи.

Сообщение от dondublon

Ну попробуйте засунуть это в БД.

Здесь я не эксперт. Но полагаю, что сериализовать множество констант - не такая сложная задача, начиная от битовой маски, заканчивая сводной таблицей.

Сообщение от dondublon

С функциями - всё получается отлично.

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

P. S. Мне кажется, писать сильно связный код - плохая затея, имхо...

@Viktorrus · 09.02.2021, 15:06

Сообщение от Arsegg

наследованию нужно предпочитать композицию

Наследование, это механизм
предок -> потомок. При этом потомок наследует все свойства предка и добавляет еще свои, которых нет у предка. То есть мы имеем схему расширения количества свойств.
Композиция, это совсем другое, это механизм целое <- часть. При этом часть имеет только ограниченное количество свойств от целого. И только объединение всех свойств частей создает целое. То есть мы имеем схему сужения количества свойств от целого к части.
Поэтому эти механизмы не взаимозаменяемы. Каждый используется в разных случаях реального мышления.
Например у Лутца есть раздел посвященный композиции и там рассматривается пример "Пиццерия". У Пиццерии есть части, официант, клиент, печь, повар. И у каждого свои свойства, но каждый является неотъемлемой частью Пиццерии. И никакого наследования там действительно нет.
Заменять наследование композицией, это значит не понимать процесс мышления человека. Ведь сами понятия "наследование" и "композиция" берут свое начало от того, какими понятиями оперирует человек при мышлении.
Там где реально существует наследование, нужно применять наследование, а там где мы имеем дело с композицией, применять композицию.

@Arsegg · 09.02.2021, 15:17

Сообщение от Viktorrus

Заменять наследование композицией

Предпочитать != заменять.

В основном, наследование применяют не к месту (особенно множественное наследование). Данный случай (класс болезнь и ее признаки) - яркий тому пример.

@Welemir1 · 09.02.2021, 15:24

Не по теме:

Сообщение от dondublon

С дополнительной таблицей для связей many-to-many.

MongoDB! хеххехе, шутю, просто инетересная беседа у вас, учитывая что ТС сам не понимает чего ваяет и не имеет представления об архитектуре.

Arsegg, а пример с Енамами мне понравился, имеет место быть, просто мы пока не знаем точного тз

а без тз -результат хз

@Viktorrus · 09.02.2021, 15:45

Сообщение от Arsegg

Данный случай (класс болезнь и его признаки) - яркий тому пример.

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

@supmener · 09.02.2021, 15:51 **[ТС]**

Сообщение от dondublon

Сообщение от dondublon
легко ложится на ORM (чтобы засунуть в БД).
Ну попробуйте засунуть это в БД. Теоретически, конечно, возможно. С дополнительной таблицей для связей many-to-many. Оно того стоит? Вот честно?

Что-то не понял, хорошо это или плохо, Вы на свой комментарий отвечаете, как бы уже опровергая его полезность?

Сейчас кое-что важное поищу в медицинской книге.

@dondublon · 09.02.2021, 16:05

Сообщение от Arsegg

O(K), где K - количество признаков. Куда быстрее?

Быстрее - просто ноль.

Python
1
2
3
4
def cough()
   return self.cough
 
if obj.cough == my_cough and obj.temp == my_temp ...

Сообщение от Arsegg

In [1]: {Symptom.COUGH, Symptom.TEMPERATURE} <= flue.symptoms

+ Накладные расходы на создание множества + расходы на хеширование + перебор. Хоть быстрый, а всё-таки.

Сообщение от Arsegg

Пока ТС не приведет полную спецификацию - это будет "игрой в бисер". Каждое новое условие будет противоречить предыдущему.

Да бросьте. Задача ТС вполне типична, и не стоит считать, что тут что-то отличается от типичной, пока это не оговорено явно.

Сообщение от Arsegg

Я привел самое разумное (и при этом простое) решение для классов болезнь и их признаков. Про тип кашля в изначальном условии не было и речи.

Ну это вам так показалось, что оно "самое разумное". На самом деле - кривое.
Решение с функциями не содержит проблемы "расшириить тип" в принципе.

Сообщение от Arsegg

Здесь я не эксперт. Но полагаю, что сериализовать множество констант - не такая сложная задача, начиная от битовой маски, заканчивая сводной таблицей.

Во-во. Дополнительные сущности, сложность.
Дело даже не в реляционной БД. Решение с функциями ложится на любую таблицу в принципе. Например, уже упомянутый pandas dataframe, или табличная модель в смысле Qt. Со множествами - нет.

Сообщение от Arsegg

Для этих функций требуется хранить состояние. И их количество будет расти согласно количеству признаков. Как поддерживать это "чудо инженерной мысли"?

Ну так множество тоже требуется хранить, как без этого. Конечно, их количество будет расти, 1:1, это нормально. Не понял вопрос, "как поддерживать". Как обычно. Я могу точно также спросить, как хранить и поддерживать ваши множества.

Сообщение от Arsegg

Что если какой-нибудь признак перестанет быть нужным, просто удалить? А как же обратная совместимость?

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

@Viktorrus · 09.02.2021, 16:06

Сообщение от Welemir1

просто мы пока не знаем точного тз

ТЗ, как я понимаю, здесь достаточно простое. По признакам определить болезнь. Вот только алгоритм, уточняющий это ТЗ, здесь будет довольно сложный.
Хотя Вы видимо правы, в ТЗ нужно бы указать как врач должен взаимодействовать с программой. Какие данные вводить на входе, какие данные вводить дополнительно при получении промежуточных результатов (как я описал выше). Все это понадобится при разработке алгоритма.
Вообще разработка алгоритма для любой серьезной задачи всегда происходит в тесном взаимодействии с заказчиком, по ходу разработки алгоритма, а часто и программы, для уточнения некоторых моментов, упущенных в ТЗ.

@supmener · 09.02.2021, 16:16 **[ТС]**

Кстати ссылка на интересный код по теме, на Лиспе, есть в этом посте MICRO LISP. Экспертная система

Новые блоги и статьи Все статьи Все блоги /
Krabik для WoW 3.3.5a, многоязычный AmbA 02.07.2026 Допилил бота, думаю что окончательно. Изменения: - добавлена многоязычность - добавлено снятие скриншотов - добавлено поддержание бафов хождения по воде (для жреца, дк и шамана) - и так, по. . .	Алиса нашла кучу ошибок компиляции и запуска в проекте, который без проблем компилировался и запускался))) anaschu 30.06.2026 Я пока посмеюся, но завтра проверю. А вообще интерсно. Дал алисе файл, в котором точно нет ошибок компиляции и запуска, и попросил их найти. Нашла кучу))) Критические ошибки, мешающие компиляции и. . .	сукцессия 16. Общий обзор, в основном что бы другие ии поняли anaschu 29.06.2026 # Передаточный документ: модель микоризной сукцессии (для нового чата) Этот документ предназначен для того, чтобы новый чат Claude мог продолжить работу без необходимости заново разбираться в. . .	сукцессия 15 неявная схема anaschu 29.06.2026 Алиса Калибровка параметров симбиотической модели: технический обзор Содержание: Введение Постановка проблемы Технические аспекты реализации Процесс внедрения изменений
сукцессия 14. Обновленная схема модели anaschu 28.06.2026 ГЛОБАЛЬНАЯ ОПИСАТЕЛЬНАЯ СПЕЦИФИКАЦИЯ ЭКОСИСТЕМНОЙ МОДЕЛИ «SOIL CHEMISTRY & MYCORRHIZA 2. 0» https:/ / ibb. co/ NnkGpfMd Представленная интегрированная схема описывает непрерывную нелинейную. . .	сукцессия 13. Питон модель трехзонного мицелия, пока что в основном арбускулярного anaschu 28.06.2026 ## Разработка агентной модели микоризной сукцессии: от выявления артефактов к созданию комплексной системы ### Аннотация Представлено исследование по разработке агентной модели микоризной. . .	сукцессия 12. краткий список проверок модели перед запуском. anaschu 27.06.2026 Скрытые отказы в моделях систем динамики (SD-models) экологических систем: два случая из практики Контекст Разбирался прототип модели систем динамики (SD-модели) микоризной сукцессии: пять. . .	Сукцессия 11. Проверка орудий перед войной: разработка через тестирование anaschu 27.06.2026 Как не дать модели соврать самой себе: проверки для симуляции микоризной сукцессии Введение Когда вы строите математическую модель живой системы — грибов, растений, почвы — главная опасность. . .

@supmener 87 / 95 / 15 Регистрация: 26.06.2013 Сообщений: 4,755

	Как работает ООП? 08.02.2021, 20:41. Показов 4720. Ответов 77 Метки нет (Все метки) Прочитал комментарий одного человека, что множественное наследование вредно и его надо избегать. Что следует думать по этому поводу и что применять в таких случаях, когда хочется его задействовать? 0

@supmener 87 / 95 / 15 Регистрация: 26.06.2013 Сообщений: 4,755
	09.02.2021, 14:00 [ТС]
	А как мне таскать рядом с англоязычным названием болезни или симптома русское название, чтобы оно было поблизости и видно было, что это одно и тоже, чтобы не ошибся? Если название класса, то возможно можно использовать __doc__ А как быть с остальным? 0

@Welemir1
	09.02.2021, 14:05
	Не по теме: Arsegg, сразу видно что ты не родной питонист,а пришел из другого ЯП, столько енамов мы еще не видели))) 0

@supmener 87 / 95 / 15 Регистрация: 26.06.2013 Сообщений: 4,755
	09.02.2021, 14:14 [ТС]
	Так примеры кода в этой теме могут учитывать этот нюанс, если это не сложно программисту, который дает совет. Так как нужное решение возможно может совсем получиться другим с учетом этой особенности. 0

@supmener 87 / 95 / 15 Регистрация: 26.06.2013 Сообщений: 4,755
	09.02.2021, 16:16 [ТС]
	Кстати ссылка на интересный код по теме, на Лиспе, есть в этом посте MICRO LISP. Экспертная система 0