TitanFighter
Авг. 11, 2015 20:33:25
Приветствую.
Делаю первые шаги в ООП, почитывая Лутца, и он против дублирования кода, ибо потом поддерживать его сложно.
Понимаю пока принцип, что в базовый класс запихивается все общее для дочерних и через дочерние классы идет расширение базового. Но я не знаю, как поступить, когда есть атрибут, который должен быть только в некоторых дочерних классах, вместо всех (в случае примера ниже, в 2х дочерних классах, вместо 3х).
К примеру, в Соц.Сетях и Сотрудниках должен быть атрибут «Должность», которого не должно быть в классе Знакомства, соответственно, как я понимаю, этому атрибуту в Базовом классе не место.
Class Базовый:
- Имя
- Фамилия
- пол
- город
- и другие атрибуты, которые будут общими для 3х дочерних классов.
Class Знакомства (Базовый):
- Семейное положение
- личный сайт
- интересы и тд.
Class Соц.Сеть (Базовый):
- Моб.тел
- скайп
- образование
Class Сотрудники (Базовый):
- Языки
- Место работы
Где в этом случае правильно расположить атрибут «Должность», чтоб на него ссылались нужные мне 2 дочерних класса (Соц.Сети и Сотрудники), вместо всех 3х? Как правильно такая проблема решается на уровне ООП?
Спасибо.
Shaman
Авг. 11, 2015 20:46:44
Например, добавить класс-наследник базового “Работник”, от которого будет наследоваться должность и прочие атрибуты для “Соц.Сеть” и “Сотрудник”. К слову, этот класс может и быть этим самым “Сотрудник”ом.
TitanFighter
Авг. 11, 2015 22:42:48
Правильно ли я вас понял, что вы предлагаете сделать вот так:
1ый вариант
class Работник (Базовый):
- должность
- и прочие атрибуты
2ой вариант:
не создавать отдельный класс, а просто запихнуть “должность” и “прочие атрибуты” в класс Сотрудники
В итоге и в первом и во втором варианте интерпретатор гуляя по дереву классов сам найдет “Должность” и “прочие атрибуты” либо в классе Работник (для 1го варианта) либо в классе Сотрудники (для 2го варианта).
?
Еще одна причина, почему я задал данный вопрос: дочерних классов планируется на самом деле 5+ и в сумме будет примерно 20 атрибутов, которые должны будут входить в разные классы (не во все сразу, так что определить их в суперклассе неполучится). Как я понимаю, их можно согласно 2ому варианту впихнуть в какой то существующий класс, но в дальнейшем при обсулживании может возникнуть вопрос “почему эти 20 атрибутов запихнули (условно) в Соц.Сети, а не в Сотрудники?”. По этому и прошу поделиться опытом знающих, как разруливать такую неопределенность, когда не можешь отдать предпочтение, в какой класс засунуть тот или иной атрибут, который будет использоваться несколькими классами.
Shaman
Авг. 11, 2015 23:22:57
TitanFighter
Правильно ли я вас понял, что вы предлагаете сделать вот так:
2ой вариант:
не создавать отдельный класс, а просто запихнуть “должность” и “прочие атрибуты” в класс Сотрудники
Я мало знаю о содержимом Сотрудников и предположил возможность наследования Соцсетей (о которых тоже мало знаю) от него. Как поступить лучше Вам виднее.
Первый вариант предполагал такую иерархию:
Базовый
Работник
Сотрудники
Соцсети
Знакомства
Касаемо организации структуры взаимосвязей жестких рамок нет, всё определяется потребностями и здравым смыслом. В некоторых случаях можно даже допустить наличие у объектов рудиментов. Во многих случаях часть атрибутов на самом деле не входит в класс объекта, а принадлежат другому классу, экземпляром которого владеет объект. Иногда применяется множественное наследование, но это очень спорная методика.
py.user.next
Авг. 12, 2015 04:37:10
TitanFighter
Понимаю пока принцип, что в базовый класс запихивается все общее для дочерних и через дочерние классы идет расширение базового.
>>> class SMordoj:
... morda = 1
...
>>> class SKopitami:
... kopita = 4
...
>>> class SRogami:
... roga = 2
...
>>> class SGorbom:
... gorb = 1
...
>>> class Kopitnoe(SMordoj, SKopitami):
... pass
...
>>> class Rogatoe(SMordoj, SRogami):
... pass
...
>>> class Kozel(Kopitnoe, Rogatoe):
... pass
...
>>> class Verblud(Kopitnoe, SGorbom):
... pass
...
>>> v = Verblud()
>>> v.morda, v.kopita, v.gorb
(1, 4, 1)
>>>
>>> k = Kozel()
>>> k.morda, k.kopita, k.roga
(1, 4, 2)
>>>
Этот принцип описан у Страуструпа (правда, на фигурах). Смысл ООП в том, чтобы сократить количество кода при написании программ.