Ruby Vererbung vs Mixins

Question

In Ruby, da Sie mehrere Mixins einschließen können, aber nur eine Klasse erweitern, scheint es wie Mixins gegenüber Vererbung bevorzugt werden.

Meine Frage: Wenn Sie Code schreiben, der erweitert/enthalten werden muss, um nützlich zu sein, warum sollten Sie es jemals zu einer Klasse machen? Oder anders gesagt, warum sollten Sie es nicht immer zu einem Modul machen?

Ich kann nur einen Grund denken, warum Sie eine Klasse wollen, und das ist, wenn Sie die Klasse instanziieren müssen. Im Fall von ActiveRecord :: Base wird es jedoch nie direkt instanziiert. Also sollte es nicht stattdessen ein Modul gewesen sein?

Answer 1

ich nur lesen zu diesem Thema in The Well-Grounded Rubyist (großes Buch, übrigens). Der Autor hat einen besseren Job zu erklären, als würde ich so werde ich ihn zitieren:

---

Keine einzige Regel oder Formel immer in der richtigen Konstruktion führt. Aber es ist sinnvoll, einen paar Überlegungen im Auge zu behalten, wenn Sie machen Klasse-versus-Modul Entscheidungen:

• Module haben keine Instanzen. Daraus folgt, dass Entitäten oder Dinge sind in der Regel am besten in Klassen modelliert, und Eigenschaften oder Eigenschaften von Entitäten oder Dinge sind am besten in Modulen eingekapselt. Entsprechend, wie in Abschnitt 4.1.1 angemerkt, sind die Klassen Namen Substantive, während Modulnamen oft Adjektive sind (Stack versus Stacklike).

• Eine Klasse kann nur eine Superklasse haben, aber sie kann beliebig viele Module mischen. Wenn Sie Vererbung verwenden, geben Sie der Erstellung einer sinnvollen Oberklasse/Unterklasse Beziehung Priorität. Verwenden Sie nicht die einzige Oberklassenbeziehung einer Klasse zu , um die Klasse mit etwas auszurüsten, das sich als eine von mehreren Merkmalsgruppen herausstellen könnte.

diese Regeln in einem Beispiel zusammenfassend, hier ist das, was Sie nicht tun sollten:

module Vehicle 
... 
class SelfPropelling 
... 
class Truck < SelfPropelling 
    include Vehicle 
... 

Vielmehr sollten Sie dies tun:

module SelfPropelling 
... 
class Vehicle 
    include SelfPropelling 
... 
class Truck < Vehicle 
... 

Die zweite Version Modelle die Entitäten und Eigenschaften viel sauberer. Truck stammt vom Fahrzeug ab (was sinnvoll ist), während SelfPropelling eine Eigenschaft von Fahrzeugen ist (zumindest alle, die uns in diesem Modell der Welt interessieren) - eine Eigenschaft, die an Lastwagen weitergegeben wird, weil Truck ein Nachkomme ist oder spezialisierte Form des Fahrzeugs.

Answer 2

Im Moment denke ich über das template Entwurfsmuster nach. Es würde sich mit einem Modul nicht richtig anfühlen.

Answer 3

Mein Take: Module dienen zum Teilen von Verhalten, während Klassen zum Modellieren von Beziehungen zwischen Objekten dienen. Sie könnten technisch alles nur zu einer Instanz von Object machen und in beliebigen Modulen mischen, um die gewünschten Verhaltensweisen zu erhalten, aber das wäre ein schlechtes, willkürliches und eher unlesbares Design.

Answer 4

Die Antwort auf Ihre Frage ist weitgehend kontextuelle. Bei der Auswertung der Pubb-Beobachtung wird die Wahl in erster Linie von der betrachteten Domäne bestimmt.

Und ja, Active enthalten sein sollte und nicht durch eine Unterklasse erweitert. Ein anderer ORM - datamapper - genau das erreicht!

Answer 5

Ich mag die Antwort von Andy Gaskell sehr - wollte nur hinzufügen, dass ja, ActiveRecord sollte keine Vererbung verwenden, sondern ein Modul hinzufügen, um das Verhalten (meist Persistenz) zu einem Modell/Klasse hinzuzufügen. ActiveRecord verwendet einfach das falsche Paradigma.

Aus dem gleichen Grund mag ich MongoId über MongoMapper sehr, weil es dem Entwickler die Möglichkeit gibt, Vererbung als eine Möglichkeit zu verwenden, um etwas Sinnvolles in der Problemdomäne zu modellieren.

Es ist traurig, dass so ziemlich niemand in der Rails-Gemeinschaft "Ruby-Vererbung" so verwendet, wie es verwendet werden soll - um Klassenhierarchien zu definieren, nicht nur um Verhalten hinzuzufügen.

Answer 6

Ich denke Mixins eine gute Idee, aber es gibt ein weiteres Problem hier, dass niemand erwähnt hat: Namespace-Kollisionen. Betrachte:

module A 
    HELLO = "hi" 
    def sayhi 
    puts HELLO 
    end 
end 

module B 
    HELLO = "you stink" 
    def sayhi 
    puts HELLO 
    end 
end 

class C 
    include A 
    include B 
end 

c = C.new 
c.sayhi 

Welcher gewinnt? In Ruby stellt sich heraus, dass es sich um das Letztere handelt, module B, weil Sie es nach module A aufgenommen haben. Jetzt ist es einfach, dieses Problem zu vermeiden: Stellen Sie sicher, dass alle Konstanten und Methoden von module A und module B sich in unwahrscheinlichen Namespaces befinden. Das Problem ist, dass der Compiler Sie nicht vor Kollisionen warnt.

Ich argumentiere, dass dieses Verhalten nicht zu großen Teams von Programmierern skalieren-- Sie sollten nicht davon ausgehen, dass die Person class C über jeden Namen im Geltungsbereich bekannt ist. Mit Ruby können Sie sogar eine Konstante oder Methode eines anderen Typs überschreiben. Ich bin mir nicht sicher, dass jemals als korrektes Verhalten betrachtet werden könnte.