Frage zur Objektbildung

[KidMoritz (Gast)]

Hallo Gemeinde,

ich habe ein kleines Verstaendnisproblem.
Ich braeuchte einen Gedankenanstoss zur Erstellung der richtigen Klasse 
bzw. deren Objekt.

Es geht um eine runde analoge Anzeige.
Sie besteht meines Erachtens nach aus 2 Teilen.
Dem starren Hintergrund(die Ziffernscheibe) und dem beweglichen Zeiger.
Ich wuerde den Hintergrund mit keiner Klasse beschreiben wollen.
Da es nur ein (totes) Bild ist.
Ist das so richtig gedacht?

Der Zeiger der Anzeige ist das womit mit ich arbeite.
Hierfuer erstelle ich eine Klasse mit ihren Eigenschaften und Methoden.

Oder ist die ganze Anzeige das Objekt und ich muss hier weiter 
unterteilen?


Danke im Voraus.

[Robert L. (lrlr)]

zur frage (die man meiner Meinung nach nicht beantworten kann) trotzdem 
ein Gedanke:

der Hintergrund hat doch genauso bestimmte "properties" (zumindest höhe 
und breite, vielleicht sind die zeiger nicht in der mitte usw., min/max 
winkel usw )

kann man dann ja in einem Objekt speichern

[Karl H. (kbuchegg)]

Wenn dein Hintergrund tatsächlich immer nur ein Bild ist, dann würde ich 
eine Klasse für den Hintergrund tatsächlich für Overkill halten.

Im Moment wäre mein erster Gedanke eine Klasse für das Anzeigeinstrument 
selber zu machen und eventuell eine Klasse für den Zeiger. Ob ich den 
Zeiger als eigene Klasse modelliere, würde ich unter anderem auch davon 
abhängig machen, ob ich diesen Zeiger noch an anderen Stellen brauchen 
kann und wie komplex dieser Zeiger werden wird.

Ein Anzeigeinstrument HAT dann einen Zeiger als interne Strukturierung. 
Genauso wie es eventuell ein Hintergrundobjekt haben könnte oder ein 
Skalenobjekt.

Schnittstelle zum Rest des Universums ist aber das Anzeigeobjekt. 
Darüber läuft die Kommunikation nach aussen und das Anzeigeobjekt 
verteilt dann wiederrum eingehende 'Befehle' an die einzelnen 
Teilobjekte bzw. koordiniert sie.
Von daher kann man später dem Anzeigeobjekt dann später immer noch eine 
feinere Klassenstruktur als Hilfsobjekte zur Verfügung stellen ohne dass 
sich im Rest des Universums viel ändert.

[KidMoritz (Gast)]

Sorry, dass ich mich erst nach reichlich verstrichener Zeit bedanke.

Danke fuer die Formulierungen, wie es betrachtet werden kann.
Sicher ist es auch eine Sache der Uebung und der Erfahrung, wie man die 
Dinge sieht und sie programmiertechnisch umsetzt.

>Im Moment wäre mein erster Gedanke eine Klasse für das Anzeigeinstrument
>selber zu machen und eventuell eine Klasse für den Zeiger.

Ok, das Object Anzeigeinstrument mit seinen Eigenschaften,
 wie: mal abgesehen von den geometrischen Eigenschaften und das der 
Hintergrund kein bild sei
- skaleneinteilung : min / max, Schrittweite,

wuerde ich die Klasse so beschreiben wollen


>Ob ich den Zeiger als eigene Klasse modelliere, würde ich unter anderem >auch 
davon abhängig machen, ob ich diesen Zeiger noch an anderen Stellen >brauchen kann 
und wie komplex dieser Zeiger werden wird.

Wie komplex kann denn ein Zeiger sein?
Mir faellt da jetzt nur ein: min/max-Stellung des Zeigers, Schrittweite
und Methoden, wie:
- inkrementieren/dekrementieren

Was heisst an anderer Stelle?
Wenn ich 2 Anzeigen modellieren wollte?


Wenn ich den Zeiger bewegen moechte, sollte ich ihn dann an die 
Schrittweite des Anzeigeobjektes "binden"?
was ich damit meine ist, dass ich dem Zeiger quasi den Winkel oder die 
XY-Position an dem der Anzeigewert 50 steht uebergebe?
Kann dies mit Vererbung realisiert werden?
Oder reicht es den Zeiger ohne "DatenBindung" zur Anzeige drehen zu 
lassen?


>Ein Anzeigeinstrument HAT dann einen Zeiger als interne Strukturierung.

Wie das gemeint kann ich mir vorstellen.
Wie ist das programmiertechnisch zu sehen?
Basisklasse->angeleitete Klasse?


Danke im Voraus

[Karl H. (kbuchegg)]

KidMoritz schrieb:

> Ok, das Object Anzeigeinstrument mit seinen Eigenschaften,
>  wie: mal abgesehen von den geometrischen Eigenschaften und das der
> Hintergrund kein bild sei
> - skaleneinteilung : min / max, Schrittweite,

Beschriftung, Strichlänge, wird jeder 5.te oder 10.te Strich länge 
gemacht, ist die Skala linear oder in einem Kreisbogen angeordnet, etc. 
etc.


> davon abhängig machen, ob ich diesen Zeiger noch an anderen Stellen >brauchen 
kann
> und wie komplex dieser Zeiger werden wird.
>
> Wie komplex kann denn ein Zeiger sein?
> Mir faellt da jetzt nur ein: min/max-Stellung des Zeigers, Schrittweite
> und Methoden, wie:
> - inkrementieren/dekrementieren

Wie wird seine Anzeige realisiert?
Ist das eine Bitmap, die um einen Punkt gedreht wird, oder eine einfache 
Linie. Vielleicht wird der auch als Polygonzug modelliert oder denk an 
eine Kirchtumuhr, bei der der Zeiger verschnörkelt ist.

> Was heisst an anderer Stelle?
> Wenn ich 2 Anzeigen modellieren wollte?

Na, wenn ich zb einen Zeiger brauche, der auf einer Anzeige ähnlich der 
Datums/Uhrzeit-Einstellung im iPhone nicht zu einem Drehinstrument 
gehört.

> Wenn ich den Zeiger bewegen moechte, sollte ich ihn dann an die
> Schrittweite des Anzeigeobjektes "binden"?

Kommt drauf an. Von extern (also ausserhalb der Klasse) bewegt sowieso 
keiner direkt den Zeiger, sondern das Objekt Auto gibt dem Objekt Tacho 
den Auftrag 'Anzeige der Fahrgschwindigkeit von 50 km/h'. Wie der Tacho 
das dann mit dem Zeiger realisiert, ist das Problem vom Tacho (also den 
Anzeigeinstrument) und nicht das Problem des Autos. Und wenn der Tacho 
festlegt (zb durch eine Konfigurationsvariable), dass er seinen Zeiger 
nur auf ganzzahlige Vielfache von 5 km/h stellen will, dann macht das 
das Anzeigeinstrument eben so.

> was ich damit meine ist, dass ich dem Zeiger quasi den Winkel oder die
> XY-Position an dem der Anzeigewert 50 steht uebergebe?

Ich würde das so machen, dass sich der Zeiger selbst darstellen kann. 
Und zwar mit seinem Referenzpunkt (gemeinhin als Drehpunkt bekannt) an 
einer bestimmten Position und von dort ausgehend in einem bestimmten 
Winkel. (Ich würde dafür eine 2D-Transformationsmatrix nehmen, aber das 
ist eine andere Geschichte)

Das Anzeigeinstrument hat dann die Aufgabe, den anzuzeigenden Wert 
mithilfe seines Skalenobjekts in interne Werte zu überführen und an 
seine mitwirkenden Einzelteile die entsprechenden Werte zu verteilen.

>>Ein Anzeigeinstrument HAT dann einen Zeiger als interne Strukturierung.
>
> Wie das gemeint kann ich mir vorstellen.
> Wie ist das programmiertechnisch zu sehen?
> Basisklasse->angeleitete Klasse?


Als Daumenregel

Wenn du umgangssprachlich sagst "IST EIN", dann ist das ein Hinweis für 
Vererbung.
Wenn du umgangssprachlich sagst "HAT EIN", dann ist das ein Hinweis für 
eine Member-Inklusion.

Also:
Ein Pkw IST EIN Auto, ein Lkw IST EIN Auto

   class Auto
   {
   };

   class Pkw : public Auto
   {
   }

   class Lkw : public Auto
   {
   }

Ein Auto HAT EINEN Motor

   class Auto
   {

     Motor motor_;
   };

   class Pkw : public Auto
   {
   }

   class Lkw : public Auto
   {
   }

Über den Weg der Vererbung erben damit Pkw und Lkw automatisch, dass sie 
einen Motor haben.

Ganz falsch hingegen wäre

   class Auto : public Motor
   {
   }

denn ein Auto IST KEIN Motor, also ist Motor auch keine Basisklasse für 
Auto. Aber: jedes Auto hat zb ein Lenkrad oder Sitze oder Türen oder 
Spiegel. Autotüren zb HABEN wiederrum einen Türöffner (sie SIND aber 
kein Türöffner) und oft auch ein Fenster. So ein Fenster HAT wiederrum 
einen Fensterheber. Eine simple Kurbel IST zb so ein Fensterheber, aber 
auch ein elektrischer Fensterheber IST EIN Fensterheber.

[KidMoritz (Gast)]

Danke fuer die Formulierungen.
Das musste ich erst einmal verarbeiten.
Vor allem die Daumenregel hat meine Sicht gut erweitert. DANKE :)

>Ich würde das so machen, dass sich der Zeiger selbst darstellen kann.
>Und zwar mit seinem Referenzpunkt (gemeinhin als Drehpunkt bekannt) an
>einer bestimmten Position und von dort ausgehend in einem bestimmten
>Winkel.
Das macht fuer mich einiges leichter, auch fuer die Sicht-und 
Herangehensweise in  Zukunft.
Ich haette mich da wahrscheinlich im Labyrinth der Komplizierung 
verirrt.

Ist Sichtweise und Aufbau hier korrekt?: HAT-Regel

class Messgeraet
{
    Anzeige _anzeige;
}

class Anzeige
{
    Zeiger _zeiger;
}

class Zeiger
{
    
}

[Karl H. (kbuchegg)]

KidMoritz schrieb:

> Ich haette mich da wahrscheinlich im Labyrinth der Komplizierung
> verirrt.

Das passiert allen am Anfang.
Es dauert einfach seine Zeit bis man die Objektorientierung 
verinnerlicht hat.

> Ist Sichtweise und Aufbau hier korrekt?: HAT-Regel

Mal sehen.
Dein Klassenapparat sagt mir:

* Ein Messgerät hat eine Anzeige (oder: kann eine Anzeige haben)
  Macht für mich Sinn. Denn zu einem Messgerät gehört ja noch mehr
  als nur die Anzeige (Messaufnehmer, Verstärker, Gehäuse, Strippen, ...
  Auf der anderen Seite ist ein Messgerät keine Anzeige, denn es gibt
  ja auch welche, die keine Anzeige haben, weil sie ihre Messwerte
  per TCP/IP oder UART rausgeben. Oder denken wir an die
  Einschubkarten in einen PC. Die haben selbst keine Anzeige.
  Daher kann "Ein Messgerät IST EINE Anzeige" nicht richtig sein.
  Ergo: In der Beziehung sieht dein Aufbau korrekt aus.

* Eine Anzeige hat einen Zeiger
  Auch das macht Sinn. Denn zu einer Anzeige gehört ja noch mehr
  als nur der Zeiger.
  Vielleicht hat eine Anzeige auch gar keinen Zeiger (zb 7-Segment),
  aber lass uns jetzt nicht spitzfindig werden. Wenn das zu
  berücksichtigen wäre, dann kann man da immer noch eine Klasse
  dazwischen schieben (AnalogAnzeige bzw. DigitalAnzeige).
  Dann gibt es eben Anzeigen und davon abgeleitet analoge Anzeigen
  und digitale Anzeigen. Analoge Anzeigen haben einen Zeiger,
  digitale nicht.

Dein Klassenaufbau macht für mich also in Summe Sinn. Das sieht logisch 
aus und entspricht so meiner Vorstellung davon, wie sich die Welt der 
Messgeräte aufbaut.

(PS: ein guter Klassenaufbau zeichnet sich oft auch dadurch aus, dass er 
auch im Nachhinein noch gut zu ändern geht. Wie zb hier: Wenn digitale 
Anzeigen ein Thema werden, dann geht das ganz einfach. Und das ist immer 
ein gutes Zeichen)

[KidMoritz (Gast)]

Na, das hat ja schon einmal gut geklappt.
Schoen ware es wenn man solche verstaendlichen Erklaerungen in Buechern 
finden wuerde.
Um ein Buch zur Ojektorientierung werde ich dennoch nicht rummkommen.

Solch Daumeregeln sind wahre Schaetze, wenn man sie kennt.
Gibt es evtl noch weitere in deiner Schatzkiste?
Auch wenn sie mir im Moment noch keinen Bezug zu ProgammierThemen geben?

Danke und Gruss