Software Design mit Namensmustern 

Nach der ursprünglichen Definition des DDD hast du recht. Danach kann die Logik in den Domain Klassen abgelegt werden. Aber sind wir doch mal ehrlich, seit wann hebt sich der Container selbst aufs Schiff?

Natürlich sollte man das NICHT immer trennen. Sonst hätte man ja keine Objekte mehr sondern würde wieder prozedural programmieren. Man muss unterscheiden zwischen Objekten und Datenstrukturen. Datenstrukturen dienen dazu Daten zu transportieren und haben kein Verhalten. Objekte haben Verhalten und natürlich auch entsprechende gekapselte Daten. Objekte werden verwendet, wenn man davon ausgeht, dass in Zukunft weitere ähnliche Objekte hinzukommen. Stichworte: Vererbung/Polymorphie/Open-Closed Principle. Wenn ich nun z.B. eine Klasse Dokument habe und das Dokumente soll z.B. eine Unterschrift erhalten, dann erhält die Klasse Dokument eine Methode Sign(). Nun kann ich eine Beliebige Menge verschiedenster Dokumente gleichzeitig unterzeichnen indem ich einfach mit einer Schleife drüberlaufe und auf jedem Objekt die Sign() Methode aufrufe. Würde ich das Prozedural implementieren müsste ich einen DocumentSigner erstellen, wo ich die Dokumente reinschicke. Kommt jetzt ein neues Dokument hinzu, dann muss ich die DocumentSigner Klasse ändern -> Open-Closed gebrochen und lange switch-cases sind vorprogrammiert -> SRP gebrochen. Bei Objekten muss ich nur ein neues Dokument ableiten und bin fertig. Deine Devices haben sinnvollerweise eine Connect Methode. Wenn nicht zu erwarten ist, dass in Zukunft viele weitere Methoden hinzukommen, gibt es überhaupt keinen Anlass daraus eine Datenstruktur zu machen. Das wird hier für mein Empfinden zu undifferenziert besprochen.

@@discovideo987 Danke für die Erläuterung

Ich sehe da aber definiv ein Problem. Die Connect Methode gehört in einen ConnectionHandler. Das Namensmuster müsste man nochmal diskutieren, aber auf jeden Fall muss die Methode in eine Klasse die die ganze Verbindung händelt. Und einem neunen ConnectionHandler würdest du dann über einen IoC Container das Device übergeben. Dann kannste folgendes machen: BluetoothDevice bluetothDevice = new BluetoothDevice(new MacAddress("00:00:00:00:00:00")); IConnectionHandler connectionHandler = new BluetoothConnectionHandler(bluetothDevice ); Connection connection = connectionHandler.Connect();

@@discovideo987 Sehe ich anders. POCOs haben nur Daten wie daten manipuliert werden, wird durch eine Logikklasse implementiert.

@Disco Video: Bin da bei K4i - wobei wir glaube nur ein Definitionsproblem haben - reine Datenobjekte (bei mit heißen sie POCO) haben kein Verhalten, die Klassen die diese Verändern (Logikklassen) schon. Anders bekommt man die Qualitätsattribute Austauschbarkeit und Wiederverwendbarkeit m.E. nicht hin, Gruß David

Hey, solange die getter und setter keine aufwändige Logik enthalten (Validierung z.B.) ist das kein Problem, gehört ja zur Datenkapselung. Gruß David

Einerseits ja, andererseits weiß doch jeder, was gemeint ist in den meisten code bases. Wenn ich nen Rechnungsobjekt habe und nen Interface RechnungsManager, weiß ich, dass da wohl dann alles drin ist, wenn ich mit Rechnungen arbeiten will und schau mir dann die Interface Methoden an. Meistens sind es halt nur 5-10 und ich hab die Komponente in 30 Sekunden verstanden. Klar kann ich jetzt aus Prinzip weil Manager böse sind, die 5 Methoden in 3 Interfaces verteilen und eins RechungsDrucker und eins RechungsArchiv und eins RechungsSpeicher nennen, aber das hilft der Übersicht und dem Verständnis des Systems überhaupt nicht weiter und jetzt hat meine Rechnungs-Komponente 3 Interfaces statt 1? Viele extrem erfolgreiche OpenSource Produkte nutzen "Manager" oder "Service" für diesen zentralen Einstiegspunkt, weils jeder sofort kapiert. Und wenn wir schon dabei sind, ja, "Helper" oder "Util" ist auch ganz böse, aber jeder Idiot versteht, was er in einer Klasse "StringUtil" finden wird und dann ist es sehr leicht, im Code nach der passenden Methode zu suchen, die man braucht. Aber manche Leute sind so verbissen mit diesem dogmatischen Quatsch, dass 20 String Methoden dann in 8 Klassen verteilt wurden, die alle sehr sprechende Namen hatten, aber die Leute haben die Logik nicht mehr gefunden, weil kein Mensch nach der Klasse "StringPadder" sucht. Manage,r Helper, Util - da sollte man immer mal drauf schauen, aber wenn 5 von 5 Leuten klar ist, was gemeint ist und kein besserer Name hervor sticht, ist es auch gut. Diese Konvention ist reine Schönheits-Masturbation and löst kein einziges reales Problem, es verbrennt nur Zeit und erzeugt rollende Augen. Mindestens 1000 andere Dinge sind viel wichtiger beim Thema Namen bevor es ein "sauber" genutzter Manager/Service/Util Name ist.

Da könnte XyzRepository für mehr Klarheit sorgen.

Danke, ich gucke am Wochenende mal. Sorry!

Kein Problem. Das Buch welches du meinst, könntest du dazu ebenfalls einen Link geben. Ich vermute es ist das OOP vom Rheinwerk Verlag?

Ich habe grade das gesamte Video nochmal geschaut, bei mir funktionieren alle links (falls du das "verlinke ich euch mal oben" meinst) Meinst Du das auch, oder stehe ich auf dem Schlauch? Das mit der Verlinkung mache ich, danke für den Hinweis!

Letzte Frage vergessen, ja genau das Buch meine ich :)

Ja das "verlinke ich oben" habe ich gemeint. Du hast dies insgesamt 3mal erwähnt und bei mir wurde nur beim letzten auch der Link oberhalb angezeigt. Habe es nun noch einmal extra angeschaut und nun sind die anderen Links auch dabei. 🤔 Entschuldige, keine Ahnung was da schief gelaufen ist.