nicht angemeldet
Hi!
Überlegt hatte ich mir, dass ich irgendeine Datenstruktur verwenden wollte, bei denen ich Variablen für mehrere Funktionen zur Verfügung habe, die aber nicht global sind (eben um nichts zu verschmutzen).
Was machen denn diese Variablen und warum können sie nicht Eigenschaften eines Objekts sein?
Da es keinen Sinn machte, mehrere Objekte von einer "Login-Klasse" zu instanzieren,
Ist es nur nicht sinnvoll, oder muss verhindert werden, dass mehrere Instanzen entstehen? Oder willst du durch das Singleton-Pattern nur eine genau definierte Zugriffsmethode erstellen, die alle anderen Verwender nehmen können, ohne irgendeine Instanzvariable kennen zu müssen?
Nach einiger Suche bin ich dann eben auf das Singleton-Muster gestoßen bin, das ja eigentlich meine Anforderungen erfüllt: Eine Klasse, von der man nur ein Objekt erzeugen kann und schön "gepackte" Variablen.
Schön gepackte Variablen bekommt man durch die OOP, da braucht es noch kein Singleton dazu. Schön gepackt bekommt man auch alles, wenn man funktional programmiert.
Jetzt frage ich einfach (wieder einmal): Wie würdest du so etwas realisieren?
Dazu müsste ich erst einmal konkrete Vorstellungen haben, was alles für Anforderungen gelöst werden sollen. Am Ende wird sicher nicht nur eine Klasse entstehen, wenn man es "richtig" angehen will. Melkt eine Kuh sich nicht selbst? Eine Benutzer-Klasse kann Eigenschaften und Methoden haben, die den Benutzer und seine Fähigkeiten beschreiben. Wenn er aber irgendwo Zugang haben möchte, vollführt er mit seinen Ausweis eine Handlung an einem Zugangskontrollsystem. Schon hat man zwei Klassen. Wenn das ZKS seine Daten in einem DBMS speichert, kommt noch eine Datenbankabstraktion hinzu. Für einfache Fälle will man vielleicht nur eine Textdatei haben => sind wir schon bei 4 Klassen.
Das kann man nun noch weiter treiben wenn man will. Die Frage ist: Muss es so umfangreich ausgestaltet sein? Ein wichtiges Prinzip bei der Entscheidungsfindung ist YAGNI - "Du wirst es nicht brauchen". Kapseln und definierte Schnittstellen schaffen für die Funktionalität, die du dir vorstellst, ist erst einmal wichtiger als das Ausgestalten dahinter.
Du solltest zuerst einmal alle Möglichkeiten der OOP ausschöpfen, bevor du Namensräume als Lösung für dein Projektstrukturierproblem ansiehst.
Welche Möglichkeiten habe ich denn mit OOP noch?
Objekte. Punkt. Schau dir immer auch an, wie die Dinge in echt funktionieren, wenn du ein Abbild zu erschaffen versuchst.
Außerdem dachte ich, Namensräume wären Bestandteil davon.
Nö, ich sehe da keinen konkreten Zusammenhang. Es ist nur sinnvoll, Gliederungen zu erstellen, damit man sich nicht ins Gehege kommt. Schon Turbo Pascal kannte mit Units Namensräume, zwei Jahre und Versionen bevor es OOP lernte.
Programmieren scheint wirklich nur das Lösen von Problemen zu sein
Ja, von solchen, die man ohne Computer gar nicht hätte.
Leider habe ich da das Problem [...], dass ich bereits "Factory" nicht verstehe, geschweige denn "Repository"
Factory kann man in obgem Szenario anwenden, wenn das Zugangskontrollsystem einen Datenspeicher ansprechen will. Welcher das konkret ist, ist dem System egal, Hauptsache sie verhalten sich gleich. Dazu kann man die verschiedenen Implementationen von einem Interface oder einer Basisklasse abstammen lassen. Ein Objekt einer konkret zu verwendenden Klasse zu besorgen, ist Aufgabe der Fabrik. Sie bekommt anhand eines Dats (Einzahl von Daten) einen Auftrag und liefert etwas konkretes, so dass man nicht selbst beispielsweise ein switch-Konstrukt erstellen muss, um eine konkrete Klasse zu instantiieren.
Repository will ich nicht weiter vertiefen, das wirst du sicher nicht benötigen.
Hoffentlich werde ich jetzt langsam dieses System überhaupt einmal anfangen können. Ich habe schon mehrere Entwürfe verwerfen müssen...
Wenn du dir Perfektionismus als Lebensziel gestellt hast, wirst du dich darauf einstellen müssen, ständig zu scheitern.
Lo!