Implementierungskonflikte zwischen Protokollen

8

Ich bin über ein Problem gestolpert, und ich kann nicht herausfinden, wie ich es lösen werde.

Nehmen wir an, wir haben eine Basisklasse (die möglicherweise von FrameworkA kommt) mit einer Eigenschaft namens subject :

%Vor%

Und wir haben ein Protokoll (das möglicherweise von FrameworkB kommt), mit einer anderen Eigenschaft, aber mit demselben Namen:

%Vor%

Diese beiden Eigenschaften repräsentieren völlig unterschiedliche Dinge.

Wie kann ich eine Klasse erstellen, die von MyClass erbt und MyProtocol implementiert? Und wie kann ich diese Eigenschaften verwenden?

%Vor%

Ich denke, dass C # eine Art Deklaration erlaubt, aber ich bin mir nicht 100% sicher ...

    
BPCorp 30.04.2015, 11:57
quelle

2 Antworten

1

Ok, lassen Sie uns für einen Moment das Problem aus der Sicht des Codes betrachten, der diese Klassen verwendet und lassen Sie uns ignorieren, wie sie implementiert werden.

Fakt 1

Wenn secondClass : SecondClass erweitert MyClass , dann erwarte ich Folgendes schreiben zu können:

%Vor%

Fakt 2

Wenn secondClass mit MyProtocol übereinstimmt, dann erwarte ich, dass ich

schreiben kann %Vor%

Wenn wir einen anderen Weg für secondClass schaffen, um MyClass.subject und MyProtocol.subject freizulegen, brechen wir das objektorientierte Paradigma.

Infakt

  1. Wenn Sie eine Klasse erweitern, übernehmen Sie implizit alle nicht-privaten Eigenschaften und Methoden. Sie können sie (und das ist eine gute Sache) nicht umbenennen.
  2. Wenn Sie einem Protokoll entsprechen, geben Sie alle nicht deklarierten Eigenschaften und Methoden genau so an, wie sie im Protokoll
  3. beschrieben sind

Wenn SecondClass die 2 Eigenschaften wie in Ihrem Pseudocode umbenannt hätte, wären wir nicht in der Lage, so etwas zu schreiben.

%Vor%

Eine mögliche (Teil-) Lösung

Sie sollten den is-a Ansatz zugunsten des has-a vermeiden.

%Vor%

Jetzt seit

  1. SecondClass ist nicht a MyClass und
  2. SecondClass ist nicht a MyProtocol

Die Eigenschaft subject hat keine Verwechslungsgefahr.

Hoffe, das hilft.

    
Luca Angeletti 30.04.2015, 13:50
quelle
3

Wenn Sie die Kontrolle über diese Basisklasse und / oder das Protokoll haben, können Sie den Eigenschaften eindeutige Namen geben und das Problem lösen.

Wenn Sie das nicht können, stellt sich die Frage, ob SecondClass diese beiden sich widersprechenden Verantwortlichkeiten wirklich selbst erfüllen muss. Was ist MyProtocol ? Irgendein Delegiertenprotokoll? Sie könnten stattdessen SecondClass vend ein separates Objekt verwenden, das diesem Protokoll entspricht, wodurch die widersprüchlichen Doppelrollen eliminiert werden.

Unter dem Strich, anstatt einen einzelnen Objektversuch zu haben, dienen zwei gegensätzliche Zwecke, teilen Sie die Verantwortlichkeiten in einzelne Objekte auf, die einen solchen Konflikt lösen.

    
Rob 30.04.2015 13:39
quelle