Kapselung

[Lion.King]

Hallo,

ich wollte fragen, ob mein Programm die strengste mögliche Kapselung besitzt, oder ob man es noch verbessern kann. Auch würde ich gerne wissen, ob mögliche Fehler im Code zu finden sind, weil mein Programm nicht kompiliert.

public class Computer {
    public String prozessor;
    public int kerne;
    public double taktfrequenz;
    public Computer(String prozessor, int kerne, double taktfrequenz){
        this.prozessor = prozessor; this.kerne = kerne; this.taktfrequenz = taktfrequenz;
    }
    public String getProzessor(){
        return prozessor;
    }
    public void setTaktfrequenz(double taktfr){
        if(istValideTaktfrequenz(taktfr)){
            taktfrequenz= taktfr;
        }
    }
    private boolean istValideTaktfrequenz(double taktfrequenz){
        return 0 < taktfrequenz && taktfrequenz < 10;
    }
}
public class Main {
    public static void main(String args[]) {
      Computer c = new Computer("Core i7", 12, 4.7);
      System.out.println(c.kerne);
      System.out.println(c.getProzessor());
      c.setTaktfrequenz(4.95);
    }
}

 

[yfons123]

dein fehler ist dass du 2 public klassen in einer datei hast .. später durch eine IDE wird dir das gezeigt.. im moment => lösch einfach public vor deinem class Computer

du hast ein wenig wenig.. um das ausufernd zu erklären

aber wenn du dir mal nen computer anschaust und den aufschraubst dann siehst du deinen prozessor und ein gehäuse .. das sind verschiedene dinge aber du hast jetzt alles in einen gebacken was "nicht gut ist"

zb könntest du sowas machen

class Prozessor{
    private String name;
    private int kerne;
    public Prozessor(String name){
        this.name = name;
    }
    public String getName(){
        return name;
    }
    // kerne implementierung
}

und dein computer hat dann

public class Computer {
    private Prozessor prozessor;
    // usw ...
    public Computer(string prozessorName, int kerne){
        prozessor = new Prozessor(prozessorName, kerne) // funktioniert nicht weil ich zufaul war dir das auch zu tippen
// usw...
    }
}

was ist jetzt der witz an der sache, deinem computer interessiert es nicht wie der prozessor aufgebaut ist es ist nur wichtig dass er einen hat,die verwaltung des prozessors überlässt du auch der prozessor klasse .. dem computer ist das wurscht

jetzt könntest du deinen computer um ein gehäuse erweitern .. also eine gehäuse klasse und dein computer besitzt das auch noch ... und so geht es dahin mit der erweiterung

PS: Kapselung ist nach uncle bob ( bekannter erfahrener programmierer der seit anfang an dabei ist ) nicht das höchste der gefühle bei OOP ... ja @KonradN ich habe ihn mir angeschaut sogar mehrmals

 

[temi]

ob mein Programm die strengste mögliche Kapselung besitzt

Nein. Die Instanzvariablen deiner Klasse sind öffentlich. Für strengste mögliche Kapselung muss die Klasse soviel wie möglich ihrer Interna verbergen und nur was für die Benutzung der Klasse unbedingt notwendig ist öffentlich machen.

Was passiert eigentlich, wenn man dem Konstruktor eine Taktfrequenz von 20 übergibt?

 

[KonradN]

PS: Kapselung ist nach uncle bob ( bekannter erfahrener programmierer der seit anfang an dabei ist ) nicht das höchste der gefühle bei OOP ... ja @KonradN ich habe ihn mir angeschaut sogar mehrmals

Niemand hat behauptet, dass Kapselung "das Höchste der Gefühle" sei. Aber es ist ein wichtiges Feature der Sprache und selbstverständlich sollte man das lernen und beherrschen. Daher wundert es mich etwas, dass Du sowas als wichtig erachtest, denn das bekommt in dem Zusammenhang schon fast den Klang von "Das braucht man nicht" oder so.

Und wenn ich mir Deinen Code ansehe, dann würden mir auch andere Dinge einfallen, die ich (und auch Uncle Bob) für wichtig erachten. Z.b. Separation of Concerns. Aber das müssen wir nicht ausführen.

Ansonsten sehe ich mehrere Probleme (von denen einige bereits angesprochen wurden:

a) ggf. 2 public Methoden in einer Klasse - jede public Methode muss in einer Klasse sein, die genau so heißt wie die Klasse (+".java" natürlich). Ich würde da kein public wegnehmen sondern wirklich in zwei Dateien aufteilen. Oder die main Methode für die Tests in Computer verschieben.

b) Kapselung bedeutet, dass der interne Zustand und die Implementierung nicht sichtbar sind nach außen und von Außen nicht beeinflusst werden kann. Daher müssen die Instanzvariablen private sein und nicht public.

c) Wenn es Vorgaben bezüglich der Belegung gibt, so müssen die generell erfüllt sein. Hier wäre also auch der Konstruktor so zu schrieben, dass dieser auch die Prüfung vornimmt. z.B. durch Nutzung des Setters in diesem (Was Folgeprobleme nach sich ziehen kann, aber das auszuführen würde den Post sprengen. In Kurzform: man muss die Inheritance etwas einschränken und z.B. dafür sorgen, dass gewisse Methoden nicht überschrieben werden können).

d) Wenn etwas nicht ok ist, dann ist es unüblich, dass man einfach etwas nicht macht und sonst normal weiter geht. Es ist üblich, dass man dann auch klar sagt: "Hey, deine Eingabe war falsch!". Hier wäre die Frage nur, ob dieses Thema (Werfen von Exceptions) schon behandelt wurde. Das wird spätestens dann wichtig, wenn durch eine default Belegung ein ungültiger Wert gespeichert wurde. Defaultwert der Instanzvariable ist 0.0. Wenn der Setter vom Konstruktor verwendet würde und da ein ungültiger Wert angegeben worden wäre, dann wäre die taktfrequenz weiter 0.0 weil nicht gesetzt und man hätte ein ungültigen Wert in einer Instanzvariable.

 

[Lion.King]

Ich danke Euch alle für Eure Hilfe und Eure Tipps.

 

[mihe7]

PS: Kapselung ist nach uncle bob ( bekannter erfahrener programmierer der seit anfang an dabei ist ) nicht das höchste der gefühle bei OOP ... ja @KonradN ich habe ihn mir angeschaut sogar mehrmals

Oh, aufpassen: der Frage, die der Onkel nachgeht war, was OOP ausmacht bzw. der Vorteil von OOP ist. Und dazu führt er aus, dass es nicht die Kapselung ist, weil man z. B. auch in C Kapselung kennt.

Das hat nichts damit zu tun, dass das Geheimnisprinzip ein wichtiges Konzept in der Softwareentwicklung ist - und zwar unabhängig von der Sprache oder dem Paradigma.