Design Pattern Bezeichnung

hustbaer

Es ist ein weitverbreitetes Muster (Muster nicht im Sinn "Design Pattern" jetzt). Ob man es auch als Design-Pattern bezeichnen kann weiss ich nicht, bin mir aber garnicht sicher dass es die Anforderungen *nicht* erfüllt. Müsste ich nu wirklich drüber nachdenken. Und vorher erstmal noch die Anforderungen nachschlagen

----

Oft heissen solche "Y-Klassen" dann XxxImpl, wobei Xxx der Interface-Name ist - z.B. IDispatchImpl.
Oft sind die Dinger dann auch templates, oder definieren eigene virtuelle Funktionen um mit der Subklasse zu kommunizieren.

Einen Namen dafür kann ich dir aber leider nicht nennen.

DocJunioR

Das ist nicht wirklich ein Design Pattern, aber ich glaub, du meinst den Vorgang des Generalisierens.

hustbaer

http://en.wikipedia.org/wiki/Mixin

Bashar

Nein, das passt nicht.

Zeus

MasterBlaster schrieb:

Habe ein Interface X;

Ok!

MasterBlaster schrieb:

Klasse A, B und C implementieren das interface X.

Ok!

MasterBlaster schrieb:

In den implementieren Methoden aus dem Interface wird in jeder klasse der gleiche Code verwendet, also erzeuge ich eine Abstracte Klasse Y.

Dann brauchst du keine 3 Klassse, ausser die Implementierung sind unterschiedlich, oder?
Ist Klasse Y identisch mit X, also gleiche methoden?

MasterBlaster schrieb:

Nun implementiert die Klasse Y das Interface X, und die Klassen A,B,C erben von der klasse Y.

Langsam hört sich es nach Chaos an.

MasterBlaster schrieb:

So nun frag ich mich ob es für dieses Klassenstruktur Muster einen Name /Pattern gibt... und wie es heist;)

Für dies nicht, aber ein ähnliches ist Bridge, vielleicht lies dazu mal etwas.

hustbaer

Bashar schrieb:

Nein, das passt nicht.

Doch, das kommt ziemlich gut hin.

Bashar

Mixins sind Klassen, von denen man ableitet, um seiner Klasse bestimmte Funktionalität hinzuzufügen. Dazu braucht man Mehrfachvererbung. In dem Spezialfall, dass eine Klasse mal nur von einem Mixin erbt, aber sonst keine Basisklasse hat, sähe die Struktur in der Tat so aus wie hier. Es wurde hier aber aus einem anderen Grund geerbt, nämlich um gemeinsame Funktionalität in eine Basisklasse auszulagern.

Bashar schrieb:

Mixins sind Klassen, von denen man ableitet, um seiner Klasse bestimmte Funktionalität hinzuzufügen. Dazu braucht man Mehrfachvererbung. In dem Spezialfall, dass eine Klasse mal nur von einem Mixin erbt, aber sonst keine Basisklasse hat, sähe die Struktur in der Tat so aus wie hier. Es wurde hier aber aus einem anderen Grund geerbt, nämlich um gemeinsame Funktionalität in eine Basisklasse auszulagern.

Reden wir hier von Mixins wie bei Ruby?

Bashar

Keine Ahnung, ich kenne Ruby nicht. Auf der Diskussionsseite in Wikipedia steht was davon, dass man die nichtvorhandene Mehrfachvererbung durch Module kompensieren kann, was auch immer das ist. In Java zieht man Aspekte heran. Ändert alles nichts an meiner grundsätzlichen Aussage.

Zeus

Bashar schrieb:

Mixins sind Klassen, von denen man ableitet, um seiner Klasse bestimmte Funktionalität hinzuzufügen. Dazu braucht man Mehrfachvererbung. In dem Spezialfall, dass eine Klasse mal nur von einem Mixin erbt, aber sonst keine Basisklasse hat, sähe die Struktur in der Tat so aus wie hier. Es wurde hier aber aus einem anderen Grund geerbt, nämlich um gemeinsame Funktionalität in eine Basisklasse auszulagern.

Nun ich seh das vollig anders. Mixin ist ein Konzept für Komposition und Mehrfachvererbung braucht man nicht, siehe D, hat Mixin-Support aber keine Mehrfachvererbung, Ruby includiert Module, Scala parametiersert Klassen. 3 verschiedene Sprache die Mixin vollig anders realisiert haben.

Bashar

Hm, bist du nun der Meinung, das was der OP beschrieben hat ist ein Mixin? Ansonsten hab ich keine Lust, über die Realisierung von Mixins in verschiedenen Sprachen zu diskutieren.

Zeus

Wenn seine Klasse Y ein Adapter/Wrapper ist, dann ja, sonst nach seine Beschreibung eher nicht.

Eine Mixin-Struktur würde nach meine Vorstellung so aussehen:

interface Ability1
{
    void execute();
}

interface Ability2
{
    void doit();
}

class Ability1Impl implements Ability1
{
    public void execute() {
    }
}

class Ability2Impl implements Ability2
{
    public void doit() {
    }
}

public class Mixin implements Ability1, Ability2  {
    public void execute() {
        a1.execute();
    }

    public void doit() {
        a2.doit();
    }

    Ability1 a1 = new Ability1Impl();
    Ability2 a2 = new Ability2Impl();

}

Haben wir die gleiche Vorstellung?

Bashar

Also wenn dann sind die Abilities (bzw. eigentlich die AbilityImpls) die Mixins. Du *simulierst* hier Mixins durch durch Delegation, das *sind* dann IMHO keine Mixins mehr.
Der OP hat aber eine völlig andere Situation beschrieben.

volkard

Zeus schrieb:

Eine Mixin-Struktur würde nach meine Vorstellung so aussehen:

ich glaube, du meinst mixture und nicht mixin.