oo -> kapselung

[Destiny1985]

So, hab mich jetzt mal auf die objekorientierung gestürzt. das erste, was ich mir genau angeschaut habe ist das Prinzip der Kapselung. An sich ganz gut zu verstehen. Ich will jetzt ein Programm von mir, was komplett nichts vom OO-Stil hat, Schritt für Schritt "umbauen". Zuerst kommt jetzt also der Schritt, es hinsichtlich der Kapselung zu überarbeiten.

Allerdings ist noch eine Frage offen. Ich habe also Programm, was ich umbauen möchte, mein Programm ausgewählt, das Prüfziffern berechnet. Als Eingaben habe ich da

1. Menüwahl (Eine oder mehrere Prüfziffern berechnen)
2. Eingabe der einzelnen Prüfziffer / des Prüfzifferraumes (von - bis)

Ich muss also für alles eine eigene Klasse mit get und set Methoden aufbauen ? ... also eine Klasse für Menüwahl, eine Einzel-Eingabe und eine für einen Zahlenraum ( muss ich bei dem Zahlenraum wiederrum 2 Klassen haben, weil sind ja 2 zahlen - von und bis).

Habe ich das so korrekt verstanden oder bin ich auf dem holzweg :>

(wenn ihr wollt poste ich mal den code des aktuellen programmes ?)


mfg

 

[AlArenal]

Ich denke mit dem Klassen-Design ist es mitunter ähnlich wie mit der Normaisierung von Datenbanken: Man muss ein gesundes Mittelmaß finden. Wenn man es übertreibt, verbrät man ohne Ende Ressourcen und hat viel mehr Aufwand mit dem Kram später ordentlich zu coden, als nötig.

Ich z.B. lege nicht mehr für absolut jeden Kram Sub-Packages an. Manchmal ist weniger echt mehr, man muss ja auch mal fertig werden...

 

[Destiny1985]

Ja, aber widerspricht das dann nicht der Objektorientierung ? ganz oder gar nicht, oder ?

was meint der rest dazu, wie sollte ich das als oo-anfänger händeln

 

[Destiny1985]

Also wenn ich mal so drüber nachdenke...eigentlich ist es doch unsinn für eine Menüwahl ein Objekt zu erstellen oder ? ich meine, ist ja nur die Wahl 1 oder 2...muss man so strikt sein und auch das abkapseln ?

 

[Wildcard]

nein

 

[AlArenal]

@Destiny:

Ein Programm ist ein Hilfsmittel um definierte Aufgaben wahrzunehmen. Damit verdiene ich meine Brötchen. Klar habe ich gewisse Ansprüche an das Design, aber mein Chef wird mir was husten wenn ich für jede neue Anwendung erst ne Doktorarbeit schreibe um das Design zu entwickeln und dann erst loslege. Wenn ich Programme schreiben würde um möglichst dolle Implementierung des OO-Gedankens hinzubekommen, hättest du vielleicht Recht.

In der Praxis muss man Kompromisse eingehen. Klar, ich will auch das mein Kram vernünftig strukturiert ist und nen logischen AUfbau hat, erweiterbar ist, etc. Ich kann aber nur in dem Maße Design Patterns umsetzen, wie ich sie beherrsche und ich setze sie auch nur in dem Maße ein, wie sie mir im konkreten Fall sinnvoll erscheinen. Oft weiß man gar nicht wo genau eine Anwendung sich mal hinentwickelt. Da fallen einem unterwegs noch die dollsten Sachen ein und plötzlich hätte man es doch besser anders gemacht.

Ich bin auch eher kopflastig und grübel und überlege. Ich versuche mich aber dahingehend in den Griff zu bekommen, dass ich zunächst erstmal grob die zu erstellende Anwendung analysiere und dann einzelne Kernkomponenten als Prototypen entwickle. Da es sich hier um GUI-Anwendungen handelt klicke ich mir also erstmal flott einen zusammen (View), dann kümmere ich mich ums Datenmodell (Model) und um dessen Funktion zu testen implementiere ich Funktionalität (Controller).

Von der Herangehensweise ist das deutlich weniger abstrakt als erst alles auf dem Reißbrett zu entwickeln (was ich in Teilen natürlich dennoch tue). Das hat auch den Vorteil, das man selbst viel früher einen Eindruck von der ANwendung bekommt und andere natürlich auch. Und je eher von einem selbst und von außen Feedback kommt, desto einfacher ist es noch Änderungen vorzunehmen. Viele Zusammenhänge und Ideen entwickeln sich auch erst, wenn man was zum Spielen hat. Und Cheffe und Kunden sind immer froh, wenn sie möglichst früh was zum Sehen und Anfassen haben. Leute sind meist ziemlich haptisch...

Dafür ist es sogar hinderlich von Anfang an alles "perfekt" zu machen. In Real Life ist alles ein Kompromiss.

 

[Destiny1985]

Habe hier jetzt mal ein kleines Programm zusammengebastelt, könnt ihr da mal einen Blick drauf werfen und bzgl Kapselung was dazu sagen -> ist das ok so ?

import java.io.*;

public class StudentenTest {

  public static void main(String[] args) {
  
    int nummer = 0;
  
    Student studi1 = new Student();
    
    BufferedReader studiname = new BufferedReader (new InputStreamReader(System.in));
    String name = "";
    System.out.print("Name des Studenten: ");
    
    try
    {
      name = studiname.readLine();
    }
    catch (IOException e)
    {
      System.out.println("\nSchwerer Ausnahmefehler*");
    }
    
    BufferedReader z = new BufferedReader (new InputStreamReader(System.in));
    String num = "";
    System.out.print("\nMatrikelnummer des Studenten: ");

    try
    {
      num = z.readLine();
      nummer = Integer.parseInt(num);
    }
    catch (IOException e)
    {
      System.out.println("\nSchwerer Ausnahmefehler*");
    }
    catch (NumberFormatException e2)
    {
      System.out.println("Sie haben keine Zahl eingegeben!");
    }
    
    studi1.setName(name);
    studi1.setNummer(nummer);
    
    String testName = studi1.getName();
    int testNummer = studi1.getNummer();

    System.out.println("\n" + testName);
    System.out.println(testNummer);
    
    System.out.println("\n.........\n");
    
    System.out.println(studi1.toString());
  }
}

public class Student {

  private String name;
  private int nummer;
  
  public String getName() {
    return this.name;
  }
  
  public void setName(String name) {
    this.name = name;
  }
  
  public int getNummer() {
    return nummer;
  }
  
  public void setNummer(int n) {
    int alteNummer = nummer;
    nummer = n;
    if(!validateNummer()) {
      nummer = alteNummer;
      System.out.println("Ungueltige Nummer");
    }
  }
  
  public boolean validateNummer() {
    return
      (nummer >= 10000 && nummer <= 99999 && nummer % 2 != 0);
  }
  
  public String toString() {
    return name + " (" + nummer + ")";
  }
}

 

[Wildcard]

Nicht OOP erkennt man sofort an einer langen main() methode.
In der main wird in aller Regel nur ein Objekt der Klasse erzeugt.
Die Klasse braucht dann bei dir eine Methode die von Tastatur einliest und einen String zurückgibt, eine Methode
für die ausgabe, eine für das Anlegen eines neues Studenten...

 

[Destiny1985]

Eieiei, das muss ich mir nochmal anschauen...

OO ist doof zu lernen Vor allem wenn man so lange brauch wie ich, um das mal zu rallen...

 

[Wildcard]

Vieleicht hilft's dir mehr in Pseudocode zu denken:
Was will ich machen?
Einen StudentenTest erzeugen.
Was macht mein StudentenTest?
- Student anlegen
- Daten einlesen
- auf Konsole ausgeben
( - auf Wunsch wiederholen)
Damit hast du Gedanklich alles zu sinnvollen Einheiten zusammengefasst und somit die Methoden einer Klasse bestimmt.

 

[Destiny1985]

Hmm ein guter Tipp, danke !

 

[KSG9|sebastian]

An deiner Stelle würde ich sowas wie ein kleines Adressbuch machen:


Ein Adressbuch speichert Personen und zugehörige Daten.
Eine Person hat einen Vornamen, Nachname, eMail und eine Adresse.
Eine Adresse hat eine Strasse, Hausnummer, Plz und nen Ort.

Dazu kannst du dir wiederum eine Klasse schreiben die sämtliche ein/ausgaben macht.

Noch ein kleiner Kommentar zu einem Code:

Wenn du etwas von der Konsole einlesen willst, dann brauchst du nicht jedesmal ne neue Instanz von nem BufferedReader erzeugen, es reicht einmal!

BufferedReader rd = new BufferedReader(new InputStreamReader(System.in));
System.out.println("Name");
String name = rd.readLine();
System.out.println("KA");
String ka = rd.readLine();

try-catch u.s.w. musst du noch einfügen..

 

[mic_checker]

    System.out.println(studi1.toString());

Das toString kannst du dir sparen, das wird automatisch aufgerufen:

System.out.println(studi1);

Ich denke Wildcard und KSG9|plak haben den Rest gut genug erklärt.

 

[Destiny1985]

japp aber das toString ist in diesem Falle ein angepasstes...

 

[Roar]

japp aber das toString ist in diesem Falle ein angepasstes...

japp aber es wird trotzdem aufgerufen

 

[mic_checker]

Destiny: Deine Klasse erbt automatisch von Object die Methode toString(). Wenn du diese überschreibst wird bei:

System.out.println(studi1);

Die aus deiner Klasse aufgerufen, da erst überprüft wird ob eine Methode toString() in deiner Klasse existiert.
Insofern deine Klasse eine Subklasse einer andern ist, geht der Compiler afaik in der Vererbungshierarchie weiter nach oben und schaut ob eine von den Superklassen toString() überschrieben hat.

Zuguter letzt, wenn er "nichts" gefunden hat, ruft er toString() aus Object auf.

Die Resultate sind die gleichen, ob du nun mit toString() oder ohne aufrufst, wollt das nur mal sagen ....