MVC, Interfaces und abstrakte Klassen

[sobo]

Hallo,

ich schlage mich gerade mit pattern herum und es tun sich ein paar Fragen auf.
Konkret beim MVC:
Bei einigen Beispielen im Web (und auch in Moock's essential AS2) werden die Model-, View-, und Controller-Klassen jeweils von abstrakte Klassen abgeleitet. Diese abstrakten Klassen implementieren jeweils wieder ein Interface.
Der Sinn eines Interfaces liegt doch darin, dass Klassen, die dieses Interface implementieren gezwungen werden, die entsprechenden Funktionen zu beinhalten. Durch eine abstrakte Klasse "zwischen" Interface und der von der abstraken Klasse abgeleiteten Klasse geht doch diese Sicherheit verloren? Ich bin ja nicht gezwungen, die entsprechenden Methoden der Mutterklasse zu überschreiben?
Wo liegt da der Sinn?

Zweite Frage:
Ist es besser (performanter?), die View beim Model als Event-Listener zu registrieren, oder wie in AS2 die update-Methode direkt vom Model aus aufzurufen?

Danke und Gruß,
sobo

[sebastian]

Hi,
also in der Tat hast du in AS das Problem, dass es keine richtig
abstrakten Klassen und Methoden gibt. In AS3 schreibt man dann
meistens einen Runtime Fehler rein um das Überschreiben zu
erzwingen.

Aber konkret zu MVC bei Moocks AS2 Buch: Ist vom Grundprinzip zwar
sicher ganz okay, aber auch nicht das Musterbeispiel schlechthin. Schau
dir vielleicht noch ein paar andere an.

Und es ist in jedem Fall besser, wenn die Views sich beim Model anmelden.
Alleine schon weil das Model die Views nicht zu kennen hat und du deine
Applikation problemlos um Views erweitern kannst ohne ans Model ran
zu müssen.

gruß

[sobo]

Alles klar, vielen Dank!
sobo

[Janoscharlipp]

Was ich seit kurzem als "Ersatz" für abstrakte Klassen verwende ist eine Hirarchie von Interfaces:
Angenommen, ich hab ein Interface IInterface mit einigen Methoden, von denen einige schon in einer abstrakten Klasse implementiert werden können, dann teile ich das Interface auf in IInterfaceBase (mit den Methoden für die "abstrakte" Klasse und IInterface mit dem Rest.
Die Vererbungsstruktur sieht dann letzten Endes so aus:

PHP-Code:

interface IInterface extends IInterfaceBase
class MyAbstractClass implements IInterfaceBase
class MyConcreteClass extends MyAbstractClass implements IInterface 


Damit kann ich Methoden in MyAbstractClass vorgeben, soweit sinnvoll, ohne dass ich Runtimeexceptions für leere Methoden einführen muss, da ich diese einfach in das Interface IInterface schreiben kann.
Einziger Nachteil ist, wenn ich in den implementierten Methoden in der "abstrakten" Klasse Methoden aus IInterface aufrufen möchte, dann muss ich this nach IInterface upcasten.

[Omega Psi]

So verfahre ich auch.

[sobo]

Ok, danke für den input!

[able]

Zitat von Janoscharlipp

Einziger Nachteil ist, wenn ich in den implementierten Methoden in der "abstrakten" Klasse Methoden aus IInterface aufrufen möchte, dann muss ich this nach IInterface upcasten.

was ist damit gemeint?
wie kann sowas aussehen?

[Omega Psi]

Man möchte so wenig konkret wie möglich arbeiten. Das heisst, in Janosch's Beispiel möchte man weitestgehend nach IInterfaceBase typisieren. Jede Methode, die in IInterfaceBase definiert ist, ist über diese Typisierung aufrufbar. Aber jede andere Methode, die nicht über durch den Typ IInterface definiert ist, kann nur durch einen Typecast(/Upcast im Kontext), aufgerufen werden.

package net.icodeapps.example.types {
  public interface IInterfaceBase {
    function get guid():String;
  }
}

package net.icodeapps.example.types {
  public interface IInterface extends IInterfaceBase {
    function get name():String;
  }
}

package net.icodeapps.example.types {
  public interface MyAbstractClass implements IInterfaceBase {
    private const _guid:String = Method.random().toString();
    public function get guid():String {
      return _guid;
    }
    public function get name():String {
      throw new IllegalOperationError('Invalid call.');
    }
  }
}

package net.icodeapps.example.types {
  public interface MyConcreteClass extends MyAbstractClass implements IInterface {
    override public function get name():String {
      return guid + "::OmegaPsi";
    }
  }
}

var i1:IInterfaceBase = new MyConcreteClass();
trace(i1.guid);
// trace(i1.name); // TypeError - die Methode ist nicht definiert für IInterface
const i2:IInterface = i1 as IInterface;
if (i2) {
  trace(i2.name);
}