Java in AP Teil 2 Fachrichtung DP

[Gast]

Moin zusammen,
wir bekommen in der Umschulung gerade wegen OOP im Eildurchlauf(14 Tage) Java eingeprügelt, mitkommen tut keiner mehr.
Wieder mal kein richtiger Einstieg, wir sollten direkt ein Spiel und PW-Generator programieren.
Dazu PAP, Sequenzdiagramme, die sitzen.
Auf Rückfragen ala wie viel davon überhaupt in der AP 2 dran kommt und in welchem Umfang gibt es null Rückmeldung.
Hat jemand schon die AP 2 für DP hinter sich und kann mir ungefähr sagen, was aus Java überhaupt dran kam?

[ZwennL]

Zwar stehe ich noch vor dem Beginn meiner Umschulung, aber in einem Gespräch bei einem Bildungsträger wurde mir gesagt, es wird nicht auf eine spezifische Programmiersprache geprüft, sondern auf die grundlegenden Konzepte und in Pseudocode. Die Konzepte sind in den imperativen Programmiersprachen immer gleich. Imperativ bedeutet soviel wie "Ein Programm wird nach der Reihenfolge seiner Ausführung aufgeschrieben". Also von oben nach unten. Ausprägungen der imperativen Programmierung sind die strukturierte Programmierung und objektorientierte Programmierung.

Die strukturierte Programmierung wurde eingeführt, um den Auswüchsen des Spaghetticodes Herr zu werden. Zu Beginn der Programmierung waren die Programme noch sehr klein. Sollten bestimmte Programmteile nicht oder erneut ausgeführt werden, wurde reger Gebrauch des Sprungbefehles GoTo gemacht. Dieser ist in der strukturierten Programmierung ein absolutes NoGo! Jeder Algorithmus lässt sich  abbilden aus:

• Sequenz (Befehle, die nacheinander abgearbeitet werden)
• Selektion (Entscheidung, mit welchem Codeteil fortgefahren wird, also If Else)
• Iteration (Schleifen, um einen definierten Codeblock beliebig oft erneut auszuführen, den Schleifenkörper)

Ein weiteres Kozept aus der strukturierten Programmierung ist die Vermeidung doppelten Codes. Gibt es also Programmteile, die aus unterschiedlichen Stellen des Quellcodes verwendet werden müssen, werden diese in Unterprogramme/ Subroutinen ausgelagert. Namen dafür sind Prozedur, Funktion, Methode (in Java gebräuchlich). Der Unterschied zwischen Prozedur und Funktion wurde mal so definiert, dass eine Prozedur keinen Rückgabewert hat, während eine Funktion ein Ergebnis an die aufrufende Methode (Stelle im Programm von wo die Subroutine gestartet wurde) zurückgibt. Wie gesagt, in Java nennt man beides einfach Methode, für die angegeben wird, welchen Datentyp das Ergebnis hat oder ob es keinen Rückgabewert gibt (void == Leer).

Alles aus der strukturierten Programmierung findet sich auch in der objektorientierten Programmierung wieder. Eine Klasse ist immer strukturiert aufgebaut. Objektorientierung wurde entwickelt, um den immer größeren Codeumfang von Softwareprojekten erneut in den Griff zu bekommen. Durch die Unterteilung von Programmteilen in unabhängige Teile, die über definierte Schnittstellen miteinander komunizieren können, ist es möglich die Softwareentwickler an Lösungen zu Teilproblemen arbeiten zu lassen, ohne dass sie wissen müssen, wie der Rest der Software aufgebaut ist.

Die grundlegende Idee ist, Klassen zu definieren. Eine Klasse ist wie eine Schablone zu verstehen, von der zur Laufzeit Objekte instanziiert werden. Jede Klasse soll nur genau eine Aufgabe haben. Sie definiert ein Objekt des realen Lebens, wie es so schön abstrakt heißt. Ein Objekt des realen Lebens kann alles sein, was sich programmatisch als ausreichender Ausschnitt der Realität beschreiben lässt. Das können gegenständliche Dinge sein, wie ein Auto, ein Gegner in einem Spiel, ein Haus, usw. Es können aber auch abstraktere Dinge sein, wie ein Bankkonto, das Wetter, der Verkehr, usw.

Nun kommt man schnell drauf, dass es Klassen geben kann, von denen die instanziierung mehrerer Objekte zur Laufzeit keinen Sinn macht. Solche Klassen werden in Java mit dem Modifikator static versehen. Von solchen Klassen wird kein Objekt instanziiert, es wird direkt mit ihnen gearbeitet, da sie fest definiert sind, ohne dass es Variationen geben kann. Die gesamte Math Bibliothek in Java ist ein Beispiel für die Verwendung von static. Mathematische Funktionen sind fest definiert. Ein Sinus z.B. wird immer gleich berechnet.

Klassen, von denen Objekte gebildet werden sollen, bilden hingegen die Grundlage für verschiedene Ausprägungen ihrer Definition. Nehmen wir wieder ein Auto. Wie bekannt, gibt es sehr viele unterschiedliche Autos auf der Welt. Brauchen wir welche für unser Programm, beschreiben wir in der Klasse die Grundeigenschaften (Klassenattribute) und die grundlegenden Möglichkeiten, wie ein Auto sich verhalten kann (Methoden).

Ein Auto hat z.B. eine Frabe. Diese gehört zur Zustandsbeschreibung und ist deshalb ein Attribut (auch Eigenschaft genannt). Eine Methode eines Autos wäre z.B. Hupen.

Soweit zum Grundgedanken von OOP. Dazu gehört aber noch einiges mehr. Die Wiederverwendbarkeit von Code spielt eine große Rolle. Deshalb würde man nicht direkt eine Klasse Auto entwickeln, sondern eine Art Stammbaum aufbauen, der eine Evolution beschreibt. Das läuft also auf die Vererbung hinaus. Von oben nach unten bilden die Verebungsstufen eine Spezialisierung, von unten nach oben eine Generalisierung.

Als erstes könnte man z.B. eine Klasse Fahrzeug entwickeln. Diese enthält nur Eigenschaften und Methoden, die jedes Fahrzeug hat. Die bereits genannte Farbe z.B. oder als Methode Lenken. Von so einer Klasse könnten nun grundlegende Fahrzeugtypen abgeleitet werden. Z.B. Kutsche, Auto, Flugzeug, Schiff, Fahrrad, usw. Alle diese Fahrzeugtypen haben eine Farbe und können Lenken. Also können sie alle von der Klasse Fahrzeug erben.

Der Grundgedanke von Vererbung ist die Wiederverwendung von Code, bzw. die Vermeidung mehrfach geschriebenen Codes. Jede Klasse sollte getestet werden, ob sie genau so funktioniert, wie erwartet. Das bedeutet, erbt eine neu zu entwickelnde Klasse von einer bestehenden, kann der Entwickler davon ausgehen, dass der geerbte Code bereits genau so funktioniert, wie er soll. Er baut "nur noch" die weitere Spezifizierung seiner eigenen Klasse dazu.

Jede selbst geschriebene Klasse in Java erbt übrigens automatisch von der Basisklasse Object. Deshalb hat z.B. jede Klasse in Java die Methode toString(). In unserem Beispiel erbt die Klasse Fahrzeug direkt von Object, ohne dass dies extra angegeben werden muss. Alle weiteren Klassen in der Vererbungshierarchie erben Object, weil Object bereits Bestandteil von Fahrzeug ist.

Eigenschaften und Methoden stehen in der Erbfolge also jeder Klasse automatisch zur Verfügung, ohne dass der Quellcode direkt in der Vererbungsstufe zu sehen ist. Deshalb ist die Dokumentation von Klassen sehr wichtig. Ich habe z.B. die Definition von Object verlinkt. Ohne diese Dokumentation könnte niemand einfach nachsehen, was Object zur Verfügung stellt. Klar, man kann in den Quellcode gucken. Aber das wäre doch sehr mühselig, denn es gibt tausende von Klassen mit noch mehr Eigenschaften und Methoden. Zur Verwendung soll ja gerade das Wissen um die Schnittstellendefiniton zur Verfügung stehen. Ansonsten agieren Klassen komplett transparent als Blackbox. Wir wissen in der Regel nicht, wie sie intern aufgebaut sind und das ist auch nicht notwendig.

Zur Objektorientierung gehören noch eine Reihe weiterer Konzepte und Grundlagen (Unvollständig):

• Datenkapselung (Konzept: Auch infomation hiding, z.B. über Getter und Setter Methoden, aber auch, wo eine Variable für andere Codeteile sichtbar ist)
• Polymorphie (Konzept: Vielgestaltigkeit)
• Konstruktoren (Grundlage: Vorschrift zur Instanziierung eines Objektes, also Übergabe aller benötigten Parameter)
• Garbage Collection (Grundlage: Speicherverwaltung passiert automatisch, deshalb keine Destruktoren und Echtzeitprogrammierung in Java)
• Interfaces (Konzept: [Sprachspezifisch] Keine Mehrfachvererbung in Java)
• Generics (Konzept, fortgeschritten: Unabhängigkeit von Datentypen)
• Ausnahmebehandlung (Konzept: Die Behandlung von Exceptions/ Fehlern zur Laufzeit)
• Multithreading (Konzept, fortgeschritten: Parallele Ausführung von Code in mehreren Threads)
• UML (Entwurfswerkzeug: Am gängigsten und recht einfach sind Klassendiagramme)
• Modifikatoren (Grundlage: Wie eine Klasse, Eigenschaft oder Methode zu interpretieren ist. Z.B. private, final, ...)

All diese Dinge lassen sich in 14 Tagen unmöglich lernen. Vieles davon wird mit Sicherheit auch nicht oder nicht tiefgreifend geprüft (sowas wie Generics eher gar nicht). Ohne irgend welches Vorwissen halte ich es für nicht möglich ein Spiel oder einen PW Generator in dieser Zeit zu entwickeln. Geschweige denn beides. (Welchen Umfang sollen die beiden Projekte denn haben?) Allerdings solltet ihr strukturierte Programmierung bereits können. Damit lässt sich einiges Erschlagen, wenn ihr es "einfach" in Klassen verpackt.

Für spezielle Fragen zu Java empfehle ich folgendes Forum: https://www.java-forum.org/

 

Bearbeitet 13. März 2023 von ZwennL

[Whiz-zarD]

vor einer Stunde schrieb ZwennL:

Zur Objektorientierung gehören noch eine Reihe weiterer Konzepte und Grundlagen (Unvollständig):

• Datenkapselung (Konzept: Auch infomation hiding, z.B. über Getter und Setter Methoden, aber auch, wo eine Variable für andere Codeteile sichtbar ist)
• Polymorphie (Konzept: Vielgestaltigkeit)
• Konstruktoren (Grundlage: Vorschrift zur Instanziierung eines Objektes, also Übergabe aller benötigten Parameter)
• Garbage Collection (Grundlage: Speicherverwaltung passiert automatisch, deshalb keine Destruktoren und Echtzeitprogrammierung in Java)
• Interfaces (Konzept: [Sprachspezifisch] Keine Mehrfachvererbung in Java)
• Generics (Konzept, fortgeschritten: Unabhängigkeit von Datentypen)
• Ausnahmebehandlung (Konzept: Die Behandlung von Exceptions/ Fehlern zur Laufzeit)
• Multithreading (Konzept, fortgeschritten: Parallele Ausführung von Code in mehreren Threads)
• UML (Entwurfswerkzeug: Am gängigsten und recht einfach sind Klassendiagramme)
• Modifikatoren (Grundlage: Wie eine Klasse, Eigenschaft oder Methode zu interpretieren ist. Z.B. private, final, ...)

Das ist falsch. All diese Themen (außer Konstruktoren) haben nichts mit Objektorientierung zu tun.

Aber was hat dieser Wall of text nun mit dem Thread-Thema zu tun?

 

[ZwennL]

vor 6 Minuten schrieb Whiz-zarD:

Das ist falsch. All diese Themen (außer Konstruktoren) haben nichts mit Objektorientierung zu tun.

Aber was hat dieser Wall of text nun mit dem Thread-Thema zu tun?

Dann habe ich bisher wohl alles falsch verstanden. Man braucht all das nicht und es gibt ganze Bücher, die diese Themen behandeln, weil den Autoren langweilig war. Statt mich zu fragen, was das alles mit dem Thema des Threads zu tun hat, vermisse ich Deinen Ansatz dem TO zu helfen.

Meiner war, ihm aufzuzeigen, was es im Groben alles gibt. Wie ich geschrieben habe, weiß ich bisher nix über den Anspruch der Prüfungen der IHK, weshalb ich mich an Hochschulinhalten zur Objektorientierung orientiert habe. Was ich aufgezählt habe sind nunmal Grundlagen, um die ein Entwickler vermutlich wissen sollte. Außer der Anspruch der Ausbildung ist, in einem Framework ein paar fertige Teile aus Bibliotheken zusammenzudengeln. Ich hätte natürlich auch einfach schreiben können, er soll lieber Python und R lernen, da diese Sprachen für DP relevanter sind.

Um konstruktiv zu bleiben, führe doch mal bitte aus, was Du unter Objektorientierung verstehst. Was gehört dazu und warum nicht die Themen, die ich aufgeführt habe, außer Konstruktoren?

[Brapchu]

vor 35 Minuten schrieb Whiz-zarD:

All diese Themen (außer Konstruktoren) haben nichts mit Objektorientierung zu tun.

Sicher?

Komisch.. Polymorphie ist eines DER Paradigmen auf denen die OOP beruht.

Ebenso Datenkapselung.

[hellerKopf]

Jetz kann man sich streiten, auf wen man sich beruft. Alan Kay ist einer der ersten, die OOP als Bezeichnung verwendeten.

Der kam noch ohne Polyphormie aus.

Aber was nützt das dem Fragesteller?
Für den TE ist wichtig, was die IHK gerne hören will.
Und da ist der lange Artikel oben weitgehend hilfreich.

[dalli]

Ich weiss nicht ob ich es falsch verstehe aber es geht um Fachrichtung DPA? Dann würde ich davon ausgehen das es Hauptsächlich um Vererbung geht. Die meisten DPA'ler werden in Python schreiben, daher denke ich das die auf diesen Nivau maximal abfragen. Die Grundlagen der OOP sollten für DPA'ler ausreichend sein. Wissen tu ich es aber nicht.

[hellerKopf]

Python ist auch zur Polymorphie fähig.

class India():
    def capital(self):
        print("New Delhi is the capital of India.")

class USA():

    def capital(self):
        print("Washington, D.C. is the capital of USA.")

obj_ind = India()
obj_usa = USA()
for country in (obj_ind, obj_usa):
    country.capital()
 

Also warum sollte es nicht gefragt werden.

Lieber vorbereitet sein, als sich hinterher ärgern.

 

[Gast]

Moin Zusammen,

schon mal Danke für die Antworten, hatte leider keine Zeit, mal wieder rein zu schauen.
Als DP bin ich auf dem Stand, ich werde überwiegend mit Python arbeiten, auch bei meinem zukünftigen Arbeitgeber wird das angewendet.
Das Thema OOP nur mit Java  in der Umschulung scheint sich erst einmal erledigt zu haben, der Dozent wurde gekündigt, Unterricht zu dem Thema ist gestrichen.
OOP in Python liegt mir bereits, mich und auch meine Mitschüler hat eben irritiert, das es plötzlich hieß, für die AP 2 wird diesen zwingend benötigt, was nicht damit zusammen passt, das die IHK sagt, es muss eine (nicht definiert) Programmiersprache gelehrt werden. Das rrundlegende Konzepte abgefragt werden, ist mir klar, diese wurde auch vermittelt.