Устранение множественного наследования

То, что у вас есть, является примером роли — это обычная ловушка для моделирования роли по наследству, но роли могут меняться, и изменение структуры наследования объекта (даже в языках, где это возможно, например Python) не рекомендуется. Дети растут и становятся взрослыми, а некоторые взрослые также будут родителями детей-студентов, а также самими взрослыми учащимися — тогда они могут отказаться от одной роли, но должны сохранить другую (их ребенок меняет школу, а он нет, или наоборот). .

Просто есть класс Person с обязательными полями и необязательными, причем последние, представляющие роли, могут меняться. «Запрашивать список» (совершенно независимо от наследования или иным образом) можно либо путем создания списка «на лету» (проходя по всем объектам, чтобы проверить соответствие каждого из них требованиям), либо поддерживая списки, соответствующие возможным требованиям (или сочетание двух стратегий как для частых, так и для специальных запросов). Здесь может помочь какая-то база данных (и большинство БД работают намного лучше без наследования;-).

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

Мне также приходит в голову, что Python поддерживает утиный ввод, что вызывает вопрос: "Почему это так?" важно, чтобы все классы имели общий базовый класс?»

Очень простое решение: используйте композицию, а не наследование. Вместо того, чтобы наследовать Student от Contact и Billing, сделайте Contact полем/атрибутом Person и наследуйте от него. Сделайте Billing полем Student. Сделайте Parent полем ссылки на самого себя для Person.

Не похоже, что вам действительно нужно множественное наследование. На самом деле вам никогда не нужно множественное наследование. Это просто вопрос о том, упрощает ли множественное наследование вещи (что я не мог здесь видеть).

Я бы создал класс Person со всем кодом, которым поделились бы взрослый и ученик. Затем у вас может быть класс Adult со всем, что только нужно взрослому, и класс Child с кодом только, который нужен ребенку.

Звучит так, как будто это можно сделать очень красиво и гибко с компонентной архитектурой, такой как zope.components. Компоненты — это своего рода сверхгибкие шаблоны композиции.

В этом случае я, вероятно, в конечном итоге сделаю что-то, когда вы загружаете данные, чтобы также установить для них интерфейсы маркеров в зависимости от некоторой информации, например, если возраст> = 18, вы устанавливаете интерфейс IAdult и т. д. Затем вы можете получить информацию для взрослых с помощью делает

adultschema = IAdultSchema(person)

или что-то вроде того. (Редактировать: на самом деле я бы, вероятно, использовал

queryAdapters(person, ISchema)

чтобы получить все схемы за один раз. :)

Компонентная архитектура может быть излишней, но как только вы привыкнете к такому мышлению, многие проблемы станут тривиальными. :)

Посмотрите отличный доклад Брэндона на PyCon: http://www.youtube.com/watch?v=UF77e2TeeQo И мой вступительный пост в блоге: http://regebro.wordpress.com/2007/11/16/a-python-component-architecture/

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

классы: Person, BillingInfo, StudentInfo.

Все люди являются экземплярами класса Person...

class Person:
    # Will have contact fields all people have - or you could split these off into an
    # object.
    parent        # Will be set to None for adults or else point to their parent's
                  # Person object.
    billing_info  # Set to None for non-adults, else to their BillingInfo object.
    student_info  # Set to None for non-student parents, else to their StudentInfo
                  # object. 

Проверка полей позволит вам создавать списки по своему желанию.

Одним из решений является создание базового класса/интерфейса Info, от которого наследуются классы ContactInfo, StudentInfo и BillingInfo. Имейте какой-то объект Person, который содержит список объектов Info, а затем вы можете заполнить список объектов Info с помощью ContactInfo, StudentInfo и т. д.

В псевдокоде вы могли бы сделать что-то вроде этого:

Class Student
    Inherits WhateverBase

    Private m_StudentType as EnumStudentTypes 'an enum containing: Adult, Child
    Private m_Billing as Billing
    Private m_Contact as Contact
    Private m_Parent as Parent

    Public Sub Constructor(studentType, billing, contact, parent)
        ...logic to make sure we have the right combination depending on studentType.
        ...throw an exception if we try to assign a a parent to an adult, etc.
        ...maybe you could have seperate constructors, one for each studenttype.             
    End Sub


    Public Property StudentType as EnumStudentTypes
        Get
             Return m_StudentType
        End Get
    End Sub

    Public Property Parent 
        Get 
           ...code to make sure we're using a studentType that has a parent,
           ...and throws an exception if not. Otherwise it returns m_Parent
        End Get
    End Sub


    [more properties]
End Class Student

Затем вы можете создать класс с именем StudentManager:

Public Class StudentManager
    Public Function GetAdults(studentCollection(Of Students)) as StudentCollection(Of Students)
        Dim ResultCollection(Of Students)

        ...Loop through studentCollection, adding all students where Student.StudentType=Adult  

        Return ResultCollection
    End Function


    [Other Functions]
End Class

Public Enum StudentType
    Adult=0
    Child=1  
End Enum