Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
OOPwas heißt objektorientiertes Programmieren (fragt ein absoluter Anfänger)
Moin ans Forum
Ich bin ein absoluter Anfänger bei Java und komme schon mit dem Begriff "Objektorientierte Programmierung" nicht klar.
Habe mir vor einiger Zeit das Buch Java für Dummies gekauft und lese nun die Einleitungskapitel zum 4ten Mal und habe das mit der oop immer noch nicht begriffen. In dem Buch gibt es unter anderem das Beispiel wo gefragt wird wieviele Personen passen in den Aufzug.
public class Aufzug {
public static void main(String args[ ]) {
int gewichtJePerson;
int maxTragkraftAufzug;
int anzahlPersonen;
gewichtJePerson = 75;
maxTragkraftAufzug = 700;
anzahlPersonen = maxTragkraftAufzug / gewichtJePerson;
System.out.print ("Es passen ");
System.out.print (anzahlPersonen);
System.out.println (" Personen in den Aufzug.");
}
}
Hier fangen meine Schwierigkeiten an.
Ich habe bisher verstanden:
die Person und der Aufzug sind Objekte
das Gewicht der Person und die Tragkraft des Aufzugs sind Eigenschaften und was nun ist das Ergebnis?
Die Berechnung ergibt 9 Personen. Sind diese 9 Personen wieder ein Objekt? Oder eine Eigenschaft? Oder etwas anderes?
Hallo ein Objekt Person gibt es in deinem Bespiel nicht.
Aufzug ist hier das Objekt.
Ein „int“ ist nur ein primitiver Datentyp und kein Objekt.
Zb. „int gewichtJePerson“ ist hier nur eine lokale Variable kein Objekt., keine Eigenschaft.
https://de.wikipedia.org/wiki/Objektorientierte_Programmierung hat gesagt.:
"Die objektorientierte Programmierung (kurz OOP) ist ein auf dem Konzept der Objektorientierung basierendes Programmierparadigma. Die Grundidee besteht darin, die Architektur einer Software an den Grundstrukturen desjenigen Bereichs der Wirklichkeit auszurichten, der die gegebene Anwendung betrifft.
https://de.wikipedia.org/wiki/Objektorientierung hat gesagt.:
Unter Objektorientierung (kurz OO) versteht man in der Entwicklung von Software eine Sichtweise auf komplexe Systeme, bei der ein System durch das Zusammenspiel kooperierender Objekte beschrieben wird. Der Begriff Objekt ist dabei unscharf gefasst; wichtig an einem Objekt ist nur, dass ihm bestimmte Attribute (Eigenschaften) und Methoden zugeordnet sind und dass es in der Lage ist, von anderen Objekten Nachrichten zu empfangen beziehungsweise an diese zu senden.
Das Problem bei dem Ansatz ist, dass man da dann direkt einige Konzepte genannt bekommt, die Dir erst einmal nichts sagen. Daher möchte ich das einmal mit ein paar Worten möglichst einfach beschreiben:
Bei der objektorientierten Programmierung wird versucht, eine Software so zu entwickeln, wie es in der wirklichen Welt bei Geräten gemacht wird:
- Du hast Pläne und mit Hilfe dieser Pläne erstellst Du reale Dinge. Das wäre dann: Du hast einen Plan, wie man einen BMW 325i herstellt und damit kannst Du dann entsprechend ganz viele BMW325i herstellen.
- Jedes Ding hat dabei ein Verhalten. Du kannst also bei dem BMW 325i die Gangschaltung nutzen, die Bremse betätigen, Gas geben, ....
- Es gibt spezielle Schnittstellen. Du hast also z,B, die Schnittstelle: Auto mit Gangschaltung. Wenn Du mit einem "Auto mit Gangschaltung" umgehen kannst, dann kannst Du jedes "Auto mit Gangschaltung" fahren. Egal ob es ein BMW 325i oder ein Fiat Panda ist.
- Es gibt eine Vererbungshirarchie - Ein BMW315i ist ein PKW. Ein Hund ist ein Säugetier ist ein Tier ....
Das alles gibt einem dann die Möglichkeit, komplexe Dinge aus Einzelteilen zusammen zu bauen. Das ist dann ähnlich wie LEGO: Du hast Bausteine und aus diesen baust Du zusammen, was Du brauchst. Für den BMW 325i nimmst Du dann einen Motor. Der muss ggf. gewisse Anforderungen erfüllen. Der Motor wird mit Schrauben befestigt. Die müssen dann auch gewisse Anforderungen erfüllen. Klar: Plastikschrauben werden einen 300 KW Motor kaum halten können. Aber durch Normierungen ist es relativ einfach. Das sind dann Schrauben M10x45 mit gewissen Anforderungen an die Stabilität. Aber es ist egal, woher die Schrauben kommen oder woraus die hergestellt wurden. Können Stahlschrauben sein oder Titanschrauben oder ... (Hauptsache die Stabilität ist gegeben).
Und wenn man sich das Beispiel anschaut, dann sieht man, dass man da keine wirkliche Objektorientierung sieht. Es gibt eine Klasse Person, aber das war es. Es gibt also einen Plan. Das war es aber auch schon. Der Plan ist aber nichts anderes als eine Art Liste mit Dingen, die zu tun sind.
Es werden paar Werte festgelegt
Es wird etwas berechnet
Es wird etwas ausgegeben.
Objektorientiert wäre das dann mehr wie in der realen Welt:
Du suchst Dir erst einmal Personen, die 75kg wiegen
Dann nimmst Du Dir einen Aufzug mit Tragkraft 700kg
Du packst nach und nach immer mehr Personen in den Aufzug um so zu ermitteln, wie viele Personen in den Aufzug passen ohne dass es einen Alarm bezüglich zu großer Last gibt.
Das ist hier natürlich Overkill. Es geht um eine einfache Berechnung. Aber evtl. hilft diese Sichtweise etwas, um das Vorgehen zu verstehen. Und da kann man dann auch einiges mehr schauen. So müssen es keine Personen sein. Alles was man braucht ist etwas, das ein Gewicht hat. Eine Person hat ein Gewicht. Aber es ist deutlich: Ich kann das auch austesten ohne Personen. Statt 75kg schwere Personen kann ich auch Sandsäcke verwenden, die 75kg wiegen. Oder Stahlgewichte. Oder was auch immer - so lange es 75kg wiegt und in notwendiger Menge in den Aufzug passt.
Und man braucht auch keinen Aufzug. Man braucht einfach etwas, das wiegt und das mir sagen kann, wann 700kg überschritten sind. Es kann also auch einfach eine Waage sein....
Das einfach mal etwas zur Erläuterung der objektorientierten Programmierung.
Objekte sind, stark vereinfacht, wie Sätze in einem Text. Das Auto ist rot.
das Objekt ist das Auto (Substativ), dieses hat eine Eigenschaft (ist) und der Wert der Eigenschaft ist rot. Jetzt könnte man die Eigenschaft noch Farbe nennen, da Eigenschaft1, Eigenschaft2 usw. wäre schon blöd. Das Auto hat die Farbe rot.
Ist erst mal ähnlich aber trotzdem ganz anders. Objekte sind hier Auto und Farbe. Also das Auto hat eine Eigenschaft die wieder ein Objekt ist. Farbe hat dann wieder eine Eigenschaft, nennen wir sie Wert = rot.
Zusatz OOP: Klassen dienen zum Herstellen von Zusammenhängen zwischen Objekten einer Klasse und die sie betreffenden Methoden. S.a. diesen Twitter Thread, Java & OOP
Vielleicht hilft auch ein Vergleichsbeispiel. Angenommen, wir wollten Personendaten verwalten und dazu Vornamen, Nachnamen und Alter erfassen. Wenn man es prozedural, also NICHT objektorientiert lösen würde, könnte man z.B. mit Arrays arbeiten. Das würde dann so aussehen:
C:
String[] firstNames;
String[] lastNames;
int[] ages;
int cntPersons;
void putNewPerson(String firstName, String lastName, int age, int index){
firstnames[index] = firstName;
lastNames[index] = lastName;
ages[index] = age;
}
int main(String[] args, int argcnt){
//...
}
Grundsätzlich kann man das schon so machen,* aber du mußt z.B. sehr darauf achten, alle Arrays synchron zu halten. Auch wenn du an zwei verschiedenen Stellen mit verschiedenen Personen arbeitest, mußt du aufpassen. Nehmen wir mal an du hast zwei Threads, die mit unterschiedlichen Personenindizes arbeiten. Ein Thread löscht jetzt eine Person und schrumpft die Arrays entsprechend, der andere Thread will aus den Daten lesen. Katastrophe, weil der andere Thread zwar einen Index hat, dieser aber nun auf andere Personendaten zeige würde als vorher.
Oder stell dir vor, du willst größere Änderungen einfügen. Du willst z.B. auch noch das Geschlecht der Person erfassen. Dann ziehst du ein neues Array auf, mußt dann aber überall in deinem Programm das entsprechend berücksichtigen.
Das geht zwar alles auch in C, z.B. mit Strukturen, aber so richtig toll ist das auch damit noch nicht.
In einer objektorientierten Sprache würde man sich dagegen eine Klasse Person schreiben:
Java:
public class Person{
private String firstName;
private String lastName;
private int age;
//Setter und Getter für firstName, lastName und age...
}
int main(String[] args){
List<Person> persons;
//...
}
Was ist daran jetzt anders?
Nun, du kommst zunächst einmal an die Attribute einer Person nicht mehr direkt ran, sondern nur noch über die Zugriffsmethoden. Und warum ist das so toll?
Du kannst nun z.B. verhindern, daß der Name einer Person einfach geändert werden kann, indem du schlicht keine Zugriffsmethode zum ändern des Namens anbietest. Stattdessen erzwingst du die Vergabe eines Namens beim Erstellen eines neuen Person-Objekts im Konstruktor. Merke, in Deutschland ist (oder war es zumindest bis vor dem Transblödsinn) nicht möglich, seinen Namen einfach zu ändern, außer vielleicht mit psychologischem Nachweis daß dein Name dich psychisch beeinträchtigt oder so.
Du kannst auch z.B. verhindern, daß age negativ wird, indem du in der Settermethode eine Prüfung vorsiehst, du kannst auf den Setter aber auch komplett verzichten und stattdessen age immer mit 0 initialisieren und nur eine Methode incrementAge() anbieten. Bei meinem C-Beispiel oben könnte man auf den Gedanken kommen, das Alter der Person durch irgendeine obskure Rechnung zu ermitteln, die in einem von 1000 Fällen irgendeinen Blödsinn errechnet, sowas kannst du hier direkt verhindern.
Darum ist Kapselung – Wesensmerkmal in der Objektorientierung – so gut und wichtig. Du baust im Prinzip eine Blackbox, die ein definiertes Verhalten nach außen hin hat, wie dieses Verhalten aber zustande kommt ist Teil der Innereien die dich nicht zu interessieren brauchen und an die du von außen eben auch nicht rankommst. Wir erweitern jetzt die Klasse Person um das Geschlecht, und lassen uns die Anrede ausgeben:
Java:
public Enum Gender{
MALE,
FEMALE
}
public class Person{
String firstName;
String lastName;
int age;
Gender gender;
public Person (String firstName, String lastName, Gender gender){
this.firstName = firstName;
this.lastName = lastName;
this.gender = gender;
age = 0;
}
public String getFormOfAddress(){
if(gender == FEMALE){return "Frau " + lastName;}
if(gender == MALE){return "Herr " + lastName;}
}
}
Und nun willst du das Programm nicht nur in Deutschland, sondern auch in Russland verwenden. Nun ist es so, daß Russen drei Namen haben: Zusätzlich zu Vor- und Nachnamen haben die Russen noch den sogenannten Vatersnamen, das ist der Name des Vaters mit Endung auf -itsch bei Männern und der Endung -owa oder -owna bei Frauen. Also beispielsweise Alexander Tscherenkowitsch Wassili, oder als weibliche Form Alexandra Tscherenkowa Wassili. Oder Iwan Petrowitsch Tscherkow, und Iwana Petrowna Tscherkow.
Wenn du das in dein Programm einbauen willst wie oben, viel Spaß. Bei Klassen ist das aber relativ einfach: Du kannst die Innereien ja nach Belieben umbauen, aber dein bereits bestehender Code kann auf den gleichen Methoden arbeiten wie vorher auch, da muß dann nichts geändert werden.
Java:
//Der Name wird nun ein eigenes Objekt
public abstract class Name{
public String getFormOfAddress();
}
public class GermanName extends Name{
String firstName;
String lastName;
public String getFormOfAddress(){return lastName;}
}
public class RussianName extends Name{
String firstName;
String fathersName;
String lastName;
public String getFormOfAddress(){return firstName + " " + fathersName;}
}
//Den Namen nun nur noch in die Klasse Person einbauen:
public class Person{
Name name;
int age;
Gender gender;
public String getFormOfAddress(){
if(gender == FEMALE){return "Herr " + name.getFormOfAddress();}
if(gender == MALE){return "Frau " + name.getFormOfAddress();}
}
}
Und das wars. Wenn dein Programm schon ein paar hunderttausend Codezeilen lang ist, ist das eine vergleichsweise winzige Änderung. Egal wo du die Methode getFormOfAddress() nun benutzt hast, du kannst sie genauso gut weiterverwenden und mußt nix ändern, mußt kein zusätzliches Array irgendwo unterbringen und berücksichtigen, keine Sonderfälle beachten, und Russen und Deutsche in deinem Programm mußt du nicht gesondert berücksichtigen. In C wäre das ein Albtraum, hier ist das kein Problem, und du kannst ohne weiteres noch weitere Eigenheiten anderer Kulturen unterbringen, z.B. Juden mit ihren ewig langen Geschlechtsregistern (Sein Name war David, Sohn des Abel, der wiederum war der dritte Sohn Isaaks, ...).
PS: So richtig habe ich Objektorientierung auch erst verstanden, als ich mich mit Entwurfsmustern beschäftigt habe. Vorher habe ich Klassen nur als sowas wie selbstgestrickte Datentypen betrachtet, aber das ist es nicht. Ich empfehle dir, dich etwas mit Java vertraut zu machen (das Buch Java von Kopf bis Fuß ist da sehr hilfreich) und dich dann mit Entwurfsmustern zu beschäftigen. (Auch da ein Tipp: Entwurfsmuster von Kopf bis Fuß.)
Ich habe bisher verstanden:
die Person und der Aufzug sind Objekte
das Gewicht der Person und die Tragkraft des Aufzugs sind Eigenschaften und was nun ist das Ergebnis?
Die Berechnung ergibt 9 Personen. Sind diese 9 Personen wieder ein Objekt? Oder eine Eigenschaft? Oder etwas anderes?
Was genau ein Objekt und was eine Eigenschaft in deinem konkreten Fall sein sollte, hängt von deinem jeweiligen Problem. Bei einer Personenkartei wie in meinem Beispiel oben ergibt offensichtlich Sinn, eine Person mit einer Klasse genauer zu beschreiben und ihr ein Verhalten zu geben. Bei der Beladung von Passagierflugzeugen geht man von einem durchschnittlichen Gewicht von 80kg je Fluggast aus, da kann 'Person' ruhig ein einfacher Zähler sein, als Eigenschaft von einem Objekt vom Typ Aeroplane.
huhu, tröste dich, ich kenne viele, die nach 5 Jahren das Konzept der OO-Programmierung immer noch nicht verstanden haben... Und es ist auch noch nicht der Weisheit letzter Schluss.
Gezeigtes Beispiel hat NICHTS mit objektorientierter Programmierung zu tun. Du hast einfach lokale Variablen, primitive Operatoren bzw. Arithmetikbefehle und Zuweisungen. Das sind ALLES Bestandteile des imperativen/prozeduralen Programmierparadigmas.
Erst durch Abstrahierung in Objekte mit Eigenschaften und Operationen auf diesen entsteht ein objektorientierter Ansatz.
Aber das soll dich hier nicht weiter verwirren, denn es gibt viele gute Bücher, die das erklären... Und eine Lehrbuchdefinition, was OO is, wird dir keiner abverlangen.
ich bin überwältigt über eure so umfangreichen Erklärungen. Vielen Dank! Muss mir das jetzt alles mal in Ruhe ansehen.
Wie mir scheint sind hier im Forum nur super ProgrammierExperten unterwegs. Ihr habt bei den Erklärungen sehr viele Fachbegriffe verwendet mit denn ich als absoluter Anfänger nicht umzugehen weis. Ich glaube das wird noch lange bei mir dauern bis ich das oop verstanden habe. Aber es dämmert bereits ganz leicht.
Nochmals Danke.
Im Kern geht es um das (häufige(re)) Wiederverwenden von Code. Weiters, dass Änderungen / Erweiterungen /Löschungen / ... (an zentraler Stelle) leicht(er) vorzunehmen sind (Recherche nach SOLID-Prinzipien und diversen Entwurfsmustern)
ich bin überwältigt über eure so umfangreichen Erklärungen. Vielen Dank! Muss mir das jetzt alles mal in Ruhe ansehen.
Wie mir scheint sind hier im Forum nur super ProgrammierExperten unterwegs. Ihr habt bei den Erklärungen sehr viele Fachbegriffe verwendet mit denn ich als absoluter Anfänger nicht umzugehen weis. Ich glaube das wird noch lange bei mir dauern bis ich das oop verstanden habe. Aber es dämmert bereits ganz leicht.
Nochmals Danke.
Also, wenn ich das Schild im Fahrstuhl lesen möchte, auf dem steht wie viele Personen mitfahren dürfen, muss ich normalerweise nicht das Durchschnittsgewicht eingeben. So einen Fahrstuhl habe ich noch nicht gesehen. Das Durchschnittsgewicht kann höchsten der Wartungsmechaniker verändern. Von daher würde ich sagen die Lösung ist nicht so gut: getElevatorDescription muss eine Methode ohne Parameter sein.
Zusatz: den Compiler (Interpreter / Transpiler /... ) interessiert nur die formelle Korrektheit der Software.
Ob auf menschlicher Seite irgendwelche Prinzipien / Empfehlungen / Verhaltensweisen /... (nicht) verwendet wurden ist da egal. Und ob die via Klassen konstruierten Objekte mit realen Objekten (inkl. Handlungsoptionen) übereinstimmen genauso.
Zusatz: den Compiler (Interpreter / Transpiler /... ) interessiert nur die formelle Korrektheit der Software.
Ob auf menschlicher Seite irgendwelche Prinzipien / Empfehlungen / Verhaltensweisen /... (nicht) verwendet wurden ist da egal. Und ob die via Klassen konstruierten Objekte mit realen Objekten (inkl. Handlungsoptionen) übereinstimmen genauso.
Der Wert ist fest ein codiert. In China könnte das Durchschnittsgewicht anders sein (z B 70 kg) als wie bei uns (80 kg).
Aber ehrlich, die Dinger werden ohnehin so gebaut, dass normalerweise nicht mehr Personen als zugelassen hineinpassen. Und (btw.) die Wartung ist schweineteuer.