Software Design mit Namensmustern
Вставка
- Опубліковано 15 вер 2024
- Das Software Design ist ein wichtiger Teil der Softwarearchitektur und damit der Softwarequalität. In der objektorientierten Programmierung sollte jeder Entwickler im Rahmen des objektorientierten Designs in der Lage sein, ein flexibles und erweiterbares Software-Design zu erstellen, egal ob die Software in C#, Java, Python oder oder einer vergleichbaren Sprache geschrieben wurde. In dieser Episode schauen wir uns die Grundlagen an und zeigen warum dieses Thema das gesamte Team angeht.
▬ Über diesen Kanal ▬▬▬▬▬▬▬▬▬▬▬▬
Seit vielen Jahren arbeite ich als Consultant, Coach und Trainer für professionelle Softwareentwicklung mit den Schwerpunkten Softwarequalität, Softwarearchitektur sowie Prozessmanagement. Auf meinem Kanal möchte ich Euch mein Wissen und meine langjährige Erfahrung in diesen Bereichen vermitteln - natürlich kostenlos. Dabei versuche ich stets Euch das Wissen so zu vermitteln, dass Ihr damit direkt in der Praxis loslegen könnt und das ganze immer mit guten Portion Humor. Lernen soll ja schließlich Spaß machen :)
▬ Empfohlene Videos ▬▬▬▬▬▬▬▬▬▬▬▬
Wie viel Softwarequalität Ihr braucht - • Architekturen - Von Mo...
Warum Software unwartbar wird - • Warum Software unwartb...
Architektur - Modularisierung - • Architektur - Modulari...
Was ist Architektur - • Was ist Architektur?
Warum Architektur - • Warum Architektur für ...
▬ Wichtige Links ▬▬▬▬▬▬▬▬▬▬▬▬
Abonniere meinen Kanal: / @davidtielke
Alle Videos: / @davidtielke
▬ Social Media ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
► Twitter: / davidtielke
► Xing: www.xing.com/p...
► LinkedIn: / david-tielke-06140912b
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
Ich verstehe nicht wieso du nur rund 5k Abonnenten hast.
Ich finde deine Videos top super und einfach erklärt👍 Videos weiterleiten alle die zu gucken und abonnieren
Ich kann mich dem Vorgänger nur zustimmen. Deine V'ideos verdienen ein Millionenpublikum. Danke dafür. Du rettest mir den Job bzw. bringst meine Tätigkeit entscheidend voran. Jetzt gibt es auch deutsche Videos die mit englischen Quellen gleichziehen. Super.
Hallo,
ich hab jetzt dieses Video entdeckt. Sehr hilfreich. Danke.
bzgl der Trennung von Logik und Datenklassen. Wie ist denn das im Hinblick auf das 'anemic domain model' (www.martinfowler.com/bliki/AnemicDomainModel.html) zu verstehen?
Gibt es ein Video das die Verwendung der Logic-Klassen zeigt. Also nicht nur den Manager (der ja nicht mit einer Instanz eines Objektes arbeitet) sondern ein z.B. ...Comparator der dann zwei Instanzen vergleicht (oder von mir aus auch eine Instanz mit einem string (z.B. Hash))?
Mich würde interessieren wie mehrere Aufgaben (die man sonnst in eine Klasse packt (Daten & Methoden)) auf mehrere Klassen aufteilt und dann entsprechend verwendet.
Danke schon mal und toller Kanal, habe mir ALLE Videos in 4 Playlists (nach Prioritäten sortiert) gelegt und schaue mir nach uns nach alle an. Ich hoffe ich vergesse keine Likes ;-)
Ich bin etwas verwirrt, von dem Beispiel von Daten und Logik trennen, denn bei DDD habe ich doch definitiv einen Teil der Logik in den Domain Models oder?
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?
Hm, "Manager" ist mindestens so bedeutungsschwanger wie "Helper". Was managet der denn? Tabellenzugriff? Lesen? Ändern? Erstellen? Löschen? All das, also CRUD? Däumchen drehen? Da findet man doch spezifischere Namen.
Wenn der Manager eine Person/Position im Unternehmen repräsentiert, ok.
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.
Ich bin ein bisschen verwirrt wegen der Daten und Logik Klassen Trennung, sollte man hier nie beides in einer Klasse haben?
Folgendes Beispiel dazu: Ich habe irgendwelche Devices in meinem System die ich verwalte und mit denen ich interagiere (z.B. Bluetooth Devices). Nun hat logischerweise diese Klasse BluetoothDevice Daten wie zum Beispiel eine "MAC Addresse", sie hat aber auch Methoden wie "Connect()". Ist das nun okey oder nicht?
@@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
Eine Datenobjekt soll also keine Methoden enthalten? Was ist mit getters und setters?
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
Für mich ist schon ein "Manager" ein Anti-Namensmuster, da die Leute da immer alles mögliche reinwerfen ...
Das verlinken hat leider nicht funktioniert 😏
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.
pfui Manger!