Klassendesign

Quiche Lorraine

Ich nutze ab und zu Vererbungen. Die meisten sind in der Form Schnittstelle -> Implementierungen. Was aus meiner Sicht ok ist.

Jedoch habe ich einen Spezialfall. Die Schnittstelle namens TS ist sehr groß geworden und bestand aus Schnittstellen-Funktionsdefinitionen, Funktionen und Variablen. Also habe ich die Funktionen und Variablen in eine eigene Klasse namens TS_Base gepackt und TS von TS_Base abgeleitet.

Dadurch entstehen Beziehungen der Form:

Leica -> TS -> TS_Base
Geomax -> TS -> TS_Base
Topcon -> TS -> TS_Base

Und das gefällt mir nicht ganz, ich weis aber nicht wie ich das trennen kann. Denn z.B. die Variablen aus TS_Base werden auch in Leica benutzt.

Mal ein kleiner Auszug:

// Pseudocode 

class TS_Base
{
  public enum GuideLightMode
  {
  }
  
  public enum PrismSearchMode
  {
  }
  
  public enum Capabilities
  {
  }
  
  protected ISensor mSensor;
  protected IDriver mDriver;
  protected ISsiMeasurement mMeasureInterface;
  
  
  protected bool SensorLoaded();  
  protected void UpdateInterfaceInstances();  
  protected Result LoadDriverAndSensor(string AssemblyPath);  
  protected Result ReadMeasurementFromObservation(ref Measurement M, IObservationContainer Obs);  
  protected Result ReadMeasurementFromObservation(ref AngleMeasurement M, IObservationContainer Obs);
}
  
abstract class TS : TS_Base
{
  public abstract Result OpenConnection(OpenMode Mode, string InitCmd, PortString Port);
  
  public abstract Result CloseConnection();
  
  public virtual Result VideoStart();
}

Hat jemand einen Tipp wie ich hier das Trennen kann? Gerade der Name TS_Base gefällt mir hier nicht.

_ro_ro

@Quiche-Lorraine

Wenn schon Vererbung dann richtig. Also trenne Dich von Klassenvariablen denn die werden nicht vererbt. Vererbt werden Eigenschaften der Instanz.

mfg

Quiche Lorraine

@_ro_ro sagte in Klassendesign:

Wenn schon Vererbung dann richtig. Also trenne Dich von Klassenvariablen denn die werden nicht vererbt.

Nö

using System;

namespace ConsoleApp1
{
    class Program
    {
        class TS_Base
        {
            public int mFoo = 1;
        }

        abstract class TS : TS_Base
        {
            public abstract void PrintVar();
        }

        class Leica : TS
        {
            public override void PrintVar()
            {
                Console.Write("Foo = " + mFoo);
            }
        }

        static void Main(string[] args)
        {
            Leica l = new Leica();

            l.PrintVar();
        }
    }
}

_ro_ro

@Quiche-Lorraine

ansonsten: Der Sinn einer Subklasse kann entweder darin bestehen, die Basisklasse zu erweitern oder die Basisklasse zu spezialisieren. Oder Beides. Wobei die Basisklasse diejenigen Methoden bereitstellt die in jeder Subklasse gebraucht werden.

mfg

SeppJ

Wenn man viele Daten hat, ist das oft ein Fall für eine Klasse, deren einzige Aufgabe es ist, diese Daten zu halten. Keinerlei Nutzcode, außer eventuell um den Zugriff zu unterstützen. Jedenfalls nichts, was nach außen als nutzbarer Code sichtbar ist.

Dazu eine andere Klasse mit dem eigentlichen Anwendungscode, die dann die Datenklasse nutzt. Nutzen im Sinne von ein Attribut oder Parameter zu haben, nicht Vererbung. Die Klasse mit dem Code hält keinerlei eigene Daten, außer eventuell zur internen Verwaltung, jedenfalls nichts das nach außen sichtbar ist.

_ro_ro

@Quiche-Lorraine

der Sinn der Klasse TS erschließt sich mir nicht. Wo doch Deine Anwendungsklassen direkt von TS_Base erben könnten.

Mfg

DocShoe

Ohne den Code zu sehen kann man da wenig sagen und nur verallgemeinern.

In deinem Quelltextauszug gibt's zB ISensor mSensor, IDriver mDriver, SensorLoaded und LoadDriverAndSensor. Kannst du das nicht insofern trennen, dass es zwei Loader-Klassen (für Driver und Sensor) gibt, die diese Aufgaben erledigen. Generell könntest du Funktionen, die ihre Aufgabe durch das public Interface von TS_Base erledigen können, außerhalb implementieren.

Quiche Lorraine

Sorry, für die späte Rückmeldung.

Habe das Problem lösen können, in dem ich Code aufräumte und nach seinen Aufgaben verteilte.

Ein Teil war reine Debug-Funktionen bezüglich dem verwendeten SDK, andere waren grundlegende Definitionen fürs Messen. Und übrig blieb eine grundlegende Klasse zum Ansteuern eines Tachymeters mit dem verwendeten SDK.

So gefällt mir die Struktur nun besser.