Grundlegende Frage zu einer Klassenstruktur

Erstmal Hallo

Ich bin mir nicht ganz sicher ob ich im richtigen Forum bin, ich hoffe ihr helft mir trotzdem - die Antwort wisst ihr bestimmt :). Es geht um den prinzipiellen Aufbau einer Klasse. Als Maschinenbaustudent hatte ich zwar schon einges zu programmieren, auch "komplexere" sachen, hat auch immer so recht und schlecht funktioniert, aber beim Programmierstil würde es wahrscheinlich jedem der davon Ahnung hat die Zehennägel aufrollen - deswegen möcht ich mein nächstes Projekt mal vernünftiger angehen.

Also... Prinzipiell muss ich ein tech. System beschreiben, welches durch eine gewisse Anzahl von Parametern (angenommen ca. 30) definiert ist, beschreiben. Die Parameter haben gemeinsame Eigenschaften (z.B. aktiv/nicht aktiv, Lage, usw...) jedoch unterscheidet sich jeder in der Art wie sein Wert (z.b. eine Temperatur) berechnet wird. Wie sieht dafür eine schöne Lösung in OOP aus? Erstelle ich eine Klasse "CParameter" mit den entsprechenden Attributen (eben z.b. aktiv/nich aktiv, Lage, usw... ) und entsprechend vielen Memberfunktionen z.b. "BerechneParamter1", "BerechneParamter2", "BerechneParamterX"? D.h. wenn ich ein Objekt "Paramter_1" der Klasse "Paramter" erstelle müsste ich dann bei der Berechnung darauf achten die richtige Memberfunktion "BerechneParamter1" auszuwählen, usw. für alle Weiteren. Wie gesagt - ich bin in OOP nicht grad der fitteste, daher bin ich mir sicher dass man das eigentlich anders / schöner Lösen können müsste. Beispielseweise eine Klasse "Parameter" als Basisklasse und für jeden einzelnen Parameter eine abgeleitete Klasse. Oder gleich für jeden einzelnen Paramter eine eigene Klasse, was mir auch ein bisschen übertrieben vorkommt.

Ja, und hier würdet ihr ins Spiel kommen. Wahrscheinlich greifen sich bei der Frage einige hier am Kopf - sorry - aber, ich möcht mich in OOP einarbeiten, une wenn dann schon richtig, mit "richtigem" Programmierstil - so guts halt geht für nen Ingenieur Also, vielen Dank euch.

elise

irgendwie klingt dein vorhaben sehr prozedural, was nicht falsch ist.

prüfe ersteinmal, ob sich hier der prozedurale ansatz nicht einfach anbietet, es geht m.W. um berechnungen.
gleich vorneweg: methoden, die "berechneparameter1, berechneparameter2.." heißen, zeigen sofort, dass die planung schiefgelaufen ist.

falls du dich wirklich für oop entscheidest:
ein objektorientiertes design muss anders gedacht werden.
du identifizierst objekte, die mit anderen in kommunikation stehen.
du klassifizierst sie, indem du die KLEINSTE gemeinsamkeit beschreibst.
regel: alles notwendige, aber nichts darüber hinaus.
die objekte kommunizieren miteinander, sie senden und/oder empfangen nachrichten.
jedes objekt hat eine lebenszeit, einen ort, wo es liegt, eine identität, und kommuniziert.
ziel ist, möglichst wenig abhängigkeiten zwischen den objekten zu haben.

nochmal zurück: was ist ein "parameter", und wenn wirklich ein objekt, lohnt es sich, ihn zu klassifizieren?
sind nicht ganz andere dinge in deinem programm die eigentlich wichtigen objekte, die senden und empfangen, aufgaben erledigen, delegieren, ...
welche schnittstellen findest du?

natürlich könntest du es wie viele machen, und statische klassen produzieren, heißt: prozedural zu denken, und die prozeduren in eine passende statische klasse packen, um sie von überall verwenden zu können. beispielsweise werden mathematische funktionen gerne als statisch angenommen. aber wenn es nur bei diesen bleibt, stellt sich die frage, warum nicht gleich prozedural.

also prüfe dein projekt, was bietet sich hier an.
wenn die entscheidung für den objektorientierten ansatz fällt, fange an, zu malen. welche objekte wurden identifiziert. wer redet mit wem. usw...

Danke Elise für die Antwort...

Vielleicht ist meine Aufgabe einfach prozedual sinnvoller zu lösen als mit OOP, oder vielleicht bin ich einfach nur zu doof für OOP

Naja, wie auch immer... ich versteh den Grundgedanken der OOP und dieser erscheint mir auch sehr sinnvoll. Das klassische Einführungsbeispiel ist doch die Klasse "Fahrzeug". Da hat man dann Attribute wie "Farbe", "Anzahl der Räder" usw, und Methoden wie "beschleunigen", "bremsen". Jetzt kann man damit wunderbar objekte der Klasse Fahrzeug erstellen wie "Auto", "LKW",. Aboslut Idiotensicher und selbst für mich problemlos nachzuvollziehen. Aber wie ich bei meiner Aufgabe auf eine sinnvolle objektorientere Programmstruktur komme blicke ich absolut nicht.

Der Kern meines Programms soll nunmal die Berechnung der Paramter sein, danach kommt dann zwar noch einiges dazu wie visualiserungen usw... aber das ist dann nur mehr draufgabe.

Mir ist mein vorhaben auch etwas komisch vorgekommen, daher die Frage hier im Forum. Aber wenn ich eben angenommen diese ca. 30 verschiedenen Paramter habe die alle mit einer unterschiedlichen, recht komplexen, mathematischen formel berechnet werden, dann brauche ich doch für jeden Parameter auch eine eigene "Berechnungsmethode" eben wie "berechneParameter1" bis "berechneParamter30". Was noch dazu kommt ist dass die einzelnen Parameter voneinander abhängig sind. Das heißt für die Berechnung von Parameter5 brauche ich z.b. Parameter3, Parameter17 und Parameter8.

Naja, ich mach mir noch ein paar gedanken, und wenn ich auf keinen grünen Zweig komm werd ichs einfach auf die klassische "quick and dirty" methode machen.

Grüße