2017-05-10 5 views
4

Ich benutze Motor Unity, wo Basisklasse für fast alle Skripte von MonoBehaviour abgeleitet werden müssen. Ich habe meine eigene Wrapper-Klasse erstellt, die von MonoBehaviour namens CMonoBehaviour abgeleitet ist und einige meiner Hilfsfunktionen enthält, die ich fast überall verwende. Aber jetzt habe ich das Problem, dass ich SOOMETIME nicht von MonoBehavuour, sondern von ThirtPartyLibraryWrapperClass (Klasse, die ebenfalls von MonoBehaviour abgeleitet ist, sondern auch eine zusätzliche Funktionalität implementieren möchte - genau wie mein Wrapper). Hier ist ein Beispiel, was ich archivieren möchte.Share-Eigenschaften ohne Vererbung

edit: Ich habe vergessen zu erwähnen, dass ThirtPartyLibraryWrapperClass in dll gepackt wird, was bedeutet, dass ich es in irgendeiner Weise

// This is what I have 
public class CMonoBehavour : MonoBehaviour 
{ 
    public int SomeHelperProperty1 { get; private set; } 
    public int SomeHelperProperty2 { get; private set; } 
    public int SomeHelperProperty3 { get; private set; } 
    public int SomeHelperProperty4 { get; private set; } 
} 

public class ThirtPartyLibraryWrapperClass : MonoBehaviour 
{ 
    public int SomeHelperProperty5 { get; private set; } 
    public int SomeHelperProperty6 { get; private set; } 
} 

// My problem : 

public class ExampleUseage1 : CMonoBehavour 
{ 
    // here I have to copypaste content of ThirtPartyLibraryWrapperClass because I cust cannot derive from two classes 
} 

public class ExampleUseage2 : ThirtPartyLibraryWrapperClass 
{ 
    // here I have to copypaste content of CMonoBehavour because I cust cannot derive from two classes 
} 

Antwort

3

Sie möchten wahrscheinlich Ihre Architektur überdenken. Es scheint, dass Sie übermäßig abhängig von der Vererbung sind, um Funktionalität bereitzustellen.

Es gibt eine Reihe von Möglichkeiten, um Ihren Ansatz zu restrukturieren, wie zum Beispiel:

  • Verwendung Erweiterungsmethoden Funktionalität bereitzustellen (Interface-Erweiterungsmethoden sind eine gute Idee)
  • Verwendung Zusammensetzung
  • Verwendung Schnittstellen + composition => Sie können die Komposition in neu implementierte Eigenschaften umbrechen, die die Aufrufe an das interne Objekt übergeben.

Verbund/Wrapper-Lösung:

public class CMonoBehavour : MonoBehaviour 
    { 
     public int SomeHelperProperty1 { get; private set; } 
     public int SomeHelperProperty2 { get; private set; } 
     public int SomeHelperProperty3 { get; private set; } 
     public int SomeHelperProperty4 { get; private set; } 
    } 

    public class ThirtPartyLibraryWrapperClass : MonoBehaviour 
    { 
     public int SomeHelperProperty5 { get; private set; } 
     public int SomeHelperProperty6 { get; private set; } 
    } 

    //COMPOSITE SOLUTION 

    public class CompositeMonoBehaviour : CMonoBehaviour 
    { 
     private ThirtPartyLibraryWrapperClass _thirdParty; 

     public int SomeHelperProperty5 { get{ return _thirdParty.SomeHelperProperty5; } } 
     public int SomeHelperProperty6 { get{ return _thirdParty.SomeHelperProperty6; } } 
    } 

    public class ExampleUseage1 : CompositeMonoBehaviour 
    { 
      //you have all your properties, great news! 
    } 

    public class ExampleUseage2 : CompositeMonoBehaviour 
    { 
     //you have all your properties, great news! 
    } 

Beachten Sie, dass die Einheit eine Einheit-Komponenten-System im Kern ist es Gameobject Design. Über tun Vererbung:

  • schlechtes Design im Allgemeinen
  • den Rahmen zu kämpfen, die eine Übung in Sinnlosigkeit ist
+0

Ja, ich habe Angst, dass es keinen anderen Weg gibt – MrIncognito

1

ändern kippe Sie können teilweise Vererbung tun und mit anderen teilen nur die Eigenschaften, die Sie benötigen. Etwas wie das:

public class CMonoBehavour : MonoBehaviour 
{ 
    public int SomeHelperProperty1 { get; private set; } 
    public int SomeHelperProperty2 { get; private set; } 
    public int SomeHelperProperty3 { get; private set; } 
    public int SomeHelperProperty4 { get; private set; } 
} 

public class ThirtPartyLibraryWrapperClass : CMonoBehavour 
{ 
    public int SomeHelperProperty5 { get; private set; } 
    public int SomeHelperProperty6 { get; private set; } 
} 


//The first class have 4 properties 
public class ExampleUseage1 : CMonoBehavour 
{ 

} 
    //The first class have 6 properties 
public class ExampleUseage2 : ThirtPartyLibraryWrapperClass 
{ 

} 
+0

Ja, aber das Problem ist, dass ThirtPartyLibraryWrapperClass in dll verpackt ist und ich kann es nicht ändern ... – MrIncognito

+0

ist CMonoBehavour deins? –

+0

Ja, aber wird zwischen mehreren Projekten geteilt (also kann er nicht von ThirtPartyLibraryWrapperClass erben) – MrIncognito

-1

Schnittstelle Magie

CMonoBehavour (uh, CMonoBehaviour, weil es ein i in "Behaviour") sollte in diesem Fall eine Schnittstelle sein.

public interface CMonoBehaviour 
{ 
    int SomeHelperProperty1 { get; } 
    int SomeHelperProperty2 { get; } 
    int SomeHelperProperty3 { get; } 
    int SomeHelperProperty4 { get; } 
} 

Beachten Sie, dass, während es keine set definiert, ist es vollkommen legal für das Interface-Implementierer einen eigenen Satz zu implementieren. Die Schnittstelle ist nur eine Auflistung aller öffentlichen Eigenschaften und Methoden.

z:

public class Something : MonoBehaviour,CMonoBehaviour 
{ 
    private int a; 
    public int SomeHelperProperty1 { 
     get { 
      return a; 
     } 

     private set { 
      a = value; 
     } 
    } 
    ... 
} 

Obwohl jetzt seine Schnittstelle, vielleicht sollten wir es umbenennen, dass, um anzuzeigen: IMonoBehaviour oder möglicherweise IBehaviourExtensions oder IBehaviourAdditions oder IBaseBehaviour.Benennen Sie es "MonoBehaviour" ist nicht wirklich hilfreich oder bezeichnend für was diese Klasse/Schnittstelle ist oder tut.

Verwandte Themen