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

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

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

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

It doesn't sound like you really need multiple inheritance. In fact, you don't ever really need multiple inheritance. It's just a question of whether multiple inheritance simplifies things (which I couldn't see as being the case here).

I would create a Person class that has all the code that the adult and student would share. Then, you can have an Adult class that has all of the things that only the adult needs and a Child class that has the code only the child needs.

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

В этом случае я, вероятно, что-нибудь сделаю, когда вы загрузите данные, чтобы также установить для них интерфейсы маркеров в зависимости от некоторой информации, например, если age> = 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/

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

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

классов: 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. 

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

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

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