Welche Rechte hat man da reserviert? Der Copyright-Vermerk - besser im Deutschen das Urheberrecht, das ist was grundlegend anderes - ist Pflicht, wenn man auf seine Rechte verweisen möchte. Wenn man "All Rights Reserved" schreibt, muss noch ein Kopier- und Vervielfältigungs-Verbot vermerkt werden!
Uralt, aber für den Einstieg immer noch gültig:
Schwieriger wird es da schon beim Verhalten des Programms, wenn alle sichtbaren Fenster geschlossen sind. Und richtig Aufwändig wird die systemabhängige Unterscheidung zwischen Ribbons und Toolbar... mag sein, dass das Programm dadurch immer noch plattformübergreifend ist, aber wenn ich an den Programmieraufwand denke... eine Arbeitserleichterung gegenüber C++ Code sieht da anders aus.
Lieber intuitiv, gut durchdacht und ansprechend gestaltet^^
Derzeit programmiere ich viel in Python, davor in Java, C++, C, PHP alles etwa in gleichen Teilen.
Das ist genau das Hauptargument gegen Setter. Was ich mich dabei immer frage: Wer sagt, dass man in Settern nicht mehr machen darf? Wer hat das denn so definiert? Beispielsweise ein Setter, der zunächst überprüft, ob die übergebene Variable im Wertebereich liegt und zur Not einen Fehler auslöst - warum ist dies kein Setter?
Einfaches Gegenbeispiel: Ich habe zwei Klassen, eine "Stundent", eine "Vorlesung". Der Student hat eine Matrikelnummer, das ist eine Eigenschaft von Student, für die Student verantwortlich ist, sie muss also in Student stehen. Die Vorlesung speichert nun die Studenten, die sie besuchen, da dies eine Eigenschaft von der Vorlesung ist (1:n Beziehung, oder wenn du magst, kannst du auch eine n:m Beziehung daraus machen). Nun sollen sich natürlich nur Studenten zur Vorlesung eintragen können, die auch dazu berechtigt sind, also braucht die Vorlesung die Matrikelnummer.... klarer Fall für einen Getter (sofern die Attribute privat sind.) Deinem Argument nach wäre das Design schlecht, da die Vorlesung ein Implementierungsdetail, nämlich die Matrikelnummer, braucht. Wie würdest du diese (zugegebenermaßen etwas gestellte) Aufgabe lösen? Mit public Attributen? Warum trifft dein Argument nun auf deine public-Attribute nicht zu?
Ist das nicht gerade der Vorteil von Gettern? Bei public-Attributen (die einzige mir bekannte Alternative zu Gettern) kannst du das "Feld" erst recht ändern!? Dazu gibt es ja dann das immutable Pattern, oder?
Also auch nur in aller Kürze.. Trotzdem kannst du dadurch Nebeneffekte provozieren. Beschränkung auf Wertebereich reicht eben nicht, auch ob derjenige das überhaupt darf, zählt.struct Student {
string firstname;
string lastname;
string imma_nr;
};
interface Vorlesung {
...
void einschreiben(Student student) raises EinschreibenFehlgeschlagenException;
...
};Das ist keine Ignoranz, das geht einfach nicht anders, da ObjC dynamisch Typisiert ist und es deswegen für den Compiler unmöglich ist, die richtige Methode auszuwählen. Was du machen kannst ist dir eine setPoint:-Methode zu basteln und dann dort abfragen, was für einen Typ dein Objekt hat. Das ist aber hässlich und sollte vermieden werden. Da ist es eleganter verschiedene Methoden zu implementieren, die sich nur nach dem Verhalten eines Objektes richten und nicht nach dem Typ.
Das muss ich mal heftigst widersprechen. Gerade Getter und Setter sorgen dafür, dass man eben keine Implementierungsdetails benötigt. Ohne Getter und Setter kannst du die interne Struktur deines Objektes nicht ändern ohne die Schnittstelle nach außen zu ändern.
Dummes Beispiel: Ich habe ein Benutzer-Objekt und will an die E-Mail-Adresse. Das Benutzer-Objekt ist ein guter-Ort die Mailadresse aufzubewahren. Das Benutzer-Objekt sollte aber nicht dafür zuständig sein Emails zu verschicken, einen mailto-Link zu zeichen. Oder sonst sämmtliche Aktionen durchzuführen für die man die Mail-Adresse braucht. Ergo: Ich brauche das Feld außerhalb des Objektes. Also brauche ich einen Getter.
Wie kommst du da jetzt ohne Getter an eine Liste der Studenten ran?
Dann hast du OOP nicht verstanden. Objekte haben einen inneren Zustand und ein Verhalten. Da macht man nichts falsch wenn man das „vermischt“.
Nochmal: Mich interessiert der innere Zustand nicht. Deswegen Getter. Damit bekomme ich Informationen aus dem Objekt raus, ohne den internen Zustand kennen zu müssen. Beispiel:
class Benutzer {
public string VollständigerName() {
if(spitzname) return name + " '" + spitzname + "' " + nachname;
return name + " " + nachname;
}
}void einschreiben(Student student) raises EinschreibenFehlgeschlagenException;Willst du etwa dass die Vorlesung für sämtliche Aktionen zuständig ist, die mit der Liste der Studenten möglich ist? Also drucken, als HTML ausgeben, als PDF ausgeben, per Mail an den Dozenten verschicken? Dann muss man für jede neue Aktion das Objekt verändern. *DAS* ist schlechtes Design. Da landen wir beim gleichen Problem wie beim Benutzer-Objekt. Willst du jetzt die Vorlesung auch zu einer Entität degradieren und die Logik wieder an eine anderes Klasse delegieren? Da dreht man sich nur wieder aufs neue im Kreis.
Wenn du den Zustand eines Objektes von außen nicht manipulieren willst, dann darf keine einzige Methode deiner Klasse Parameter erwarten, denn jede könnte den Zustand deines Objektes ändern. Nein du darfst noch nicht einmal Methoden ohne Parameter aufrufen, denn die können auch den internen Zustand eines Objektes verändern und da knallt es auch mit Threads.