Da hat natürlich jeder so seine Meinung. Meine Meinung dazu ist, dass es erstmal wichtig ist, dass die Software wartbar und leicht weiter zu pflegen sein sollte.

Folgende Punkte sollte man ernst nehmen.

• Objektorientierte Programmierung (OOP)

• MV* Design Pattern, wie MVC oder besser sogar MVVM

• Gut Observer und auch ein paar andere Design Pattern, wie das Factory Pattern sind auch manchmal einzusetzen.

• SOLID-Prinzipien sollte man sich unbedingt daran halten, 4 sind von Robert C. Martin.

• Funktionale Programmierung, in manchen Situationen auch sehr wichtig. Wie die Lambdaausdrücke und auch anonyme Funktionen.

• Sprachfutures wie Generic und Enum sind in manchen Situationen auch nicht zu unterschätzen.

Das Singleton Pattern würde ich aus folgenden Gründen selbst vermeiden:

• Da es einen globalen Ansatz besitzt, sind globale Variablen zu leicht umzusetzen.

• Es entspricht nicht der Denkweise der Objektorientierten Programmierung (OOP).

• Die Frage, die ich mir dann Stelle, gibt es denn nicht ein besseres Design-Pattern, welches das Problem dann besser und sauberer lösen kann.

Wie sollte man aber vorgehen? Eine gute Möglichkeit wäre mit Klassendesign mit UML ein Softwaredesign zu beginnen.
Damit hat man eine gute Übersicht, welche jeweiligen Klassenobjekte eine entsprechende Aufgabe besitzen sollte.

Wichtig ist natürlich auch, die Klassen in drei Hauptrollen zu unterteilen. Dazu nutzt man ein MV* Design Pattern. Diese kann man beim Frontend und auch beim Backend nutzen.

Beim Model-View-Controller-Muster (MVC) wären das:

• Models beinhalten die Daten selbst. Diese wären dann zum Beispiel die Daten in einer SQL-Datenbank. Models bestehen immer aus einer Klasse mit ihren Eigenschaften.

• Views sind die Präsentation oder auch die Steuerelemente, mit denen der Anwender arbeitet.

• Controllers sind die Steuerung die Models und Views miteinander verbindet.

Beim Model View ViewModel (MVVM) wären das:

• Models beinhalten die Daten selbst. Diese wären dann zum Beispiel die Daten in einer SQL-Datenbank. Models bestehen immer aus einer Klasse mit ihren Eigenschaften.

• Views sind die Präsentation oder auch die Steuerelemente, mit denen der Anwender arbeitet.

• ViewModels sind zwar die Verbindung zwischen Models und Views, aber jedes Model besitzt immer sein eigenes ViewModel und auch jedes View hat sein eigenen ViewModel, zum Beispiel in WPF per DateContext. Die ViewModels kennen zwar ihren Model, aber die Views kennen sie nicht, für TDD wäre das wichtig. Die Views kennen aber ihre ViewModel.

Auf diesem Weg bekommt man dann besser einen sauberen und wartbaren Code, was immer das Hauptziel sein sollte.

Denn nur ein wartbarer Quellcode ist auch ein wirtschaftlicher Quellcode. Dieser ist so leichter zu pflegen und auch erweiterbar.
So ist es besser möglich ein neues Futures einzubauen oder auch ein Bugfix zu entfernen.

Wenn man aber einen anderen Weg geht und merkt, dass man an der Software hauptsächlich nur noch mit rumflicken beschäftigt ist, sollte man ernsthaft überlegen, was man selbst falsch gemacht hat. Weil so ein Software Design nun nur noch Probleme machen wird.
Grundregel dazu: Umso größer das Projekt wird, umso größer werden die Probleme, die daraus entstehen.

In Vorbereitung...