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

@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. Экспертная система

Новые блоги и статьи Все статьи Все блоги /
Генератор паролей (вариант №4) Maks 01.11.2026 После публикации 3-го варианта генератора паролей, разослал его своим коллегам (с целью оценки), в итоге были получены следующие рекомендации: 1. Вернуть возможность использования знаков \| 1 l I;. . .	Генератор паролей (вариант №3) Maks 30.10.2026 Финальная версия генератора паролей 1С. Доработка решения в этот раз коснулась только визуальной части, а именно, добавлен реквизит ДопПараметры (тип Булево), который скрывает/ отображает реквизиты:. . .	Магическое мышление и магия, современная наука не отличима от магии (говорит ИИ Джемени) zorxor 30.10.2026 Джемени, расскажи, пожалуйста, что такое магическое мышление, что такое магия, почему современная наука чем-то напоминает магию? Фраза «Любая достаточно развитая технология неотличима от магии». . .	За какое время ИИ может подобрать пароль по хешу (рассказывает Джемени ИИ) zorxor 30.10.2026 Расскажи, Джемени, если известен хэш МД5, например, за сколько ИИ сможет подобрать соответствующий пароль? Искусственный интеллект (ИИ) может подобрать простой или средний по сложности пароль по. . .
Кто убил Suno? Почему наше солнышко погасло? (диалог с ИИ Джемени) zorxor 30.10.2026 Как убивали Suno. Хронология. «Убийство» музыкальной нейросети Suno — это затяжной процесс, в котором технологический хайп стартапа разбился о жесткую реальность судебных исков от гигантов. . .	Генератор паролей (вариант №2) Maks 30.10.2026 Обновленная версия ранее созданной обработки. Добавлены следующие реквизиты типа Булево: - Буквы; - Цифры; - Символы. Изменена логика команды "Сгенерировать" и процедуры "ПриОткрытии":. . .	Генератор паролей (вариант №1) Maks 29.10.2026 Реализация из решения ниже выполнена исключительно по моей инициативе, дабы облегчить себе работу в создании паролей для администрируемых мною сервисов и пользователей. Самым главным критерием для. . .	Установка ChatGPT (Codex) на Windows без использования Microsoft Store Fabien159 28.10.2026 Здравствуйте всем читающим! Опишу процесс установки ChatGPT (Codex) на Windows, если по каким-то причинам у вас не получается устанавить его через Microsoft Store. И так: 1. Скачиваем с. . .

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

	Как работает ООП? 08.02.2021, 20:41. Показов 4991. Ответов 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