OOT Desing gemäss Prozess

😉Hallo zusammen
Nachdem ich einige Stunden /Tage /Wochen und Monat kontinuierlichem Aufbau meines Programmierwissens beschäftig bin war, möchte ich gerne eine kleine Disskusion anstossen.

Mich würde interessieren, wie ihr den Prozess der gesamten Softwareentwicklung durchlauft.

Gemäss Schulbüchlein geht man ja (Korrkturen erwünscht) so vor:

1. Man schreibt sich auf was das Programm alles machen kann, soll, müsste
2. Abstrahierung der verwendeten Objekte im Programm die verwendet werden.
3. Erstellt ein UML Diagramm /oder ein Klassendesign im VSS.
4. Code schreiben

Nun, nach der Durchwälzung der OOT-Literatur und Beispielen ist es auch heute noch ziemlich schwer ein reales Objekt abzubilden, dass eigentlich gar nicht so real ist (Datenbankverbindung (kann ich ja nicht anfassen 😉 ).

Was mich interessieren würde, arbeitet ihr nach bestimmten vorgegebenen Prozessen?

Wie geht ihr vor wenn ihr eine Lösung erarbeiten müsst? Ist für euch klar, dass ihr in eurem Programm Interfaces, Singletons benutzen werdet, oder arbeitet ihr nach einer Projektvorlage?

Es würde mich freuen, wenn soviele Rückmeldungen wie möglich geschrieben werden würden.

Hallo,

sehr interessanter Post. Ich hoffe das viele leute die mehr Ahnung von diesem Thema haben als ich antworten trotzdem möchte ich kurz etwas dazu sagen.

So wie ich das bis jetzt verstanden habe entsprichen die von dir genannten Schritte dem "klassischen" Softwaredevelopment. Interessant wäre demgegenüber die Agilen Softwareentwicklungsmethoden zu betrachten die zumindest die von dir genannten Schritte nicht durchführen bzw. in deutlich abgewandelter Form durchführen. So gibt es keine großen UML Diagramme und Vorausplanungen sondern "Stories" und "Iterationen" usw. usf.

Ich muss immer dazu sagen das ich mich nur Hobbymäßig ab und zu mit diesen Themen beschäftige und somit nicht aus der (Industrie-)Praxis sprechen kann.

Wollte dieses Thema nur mal kurz anschneiden und hoffe auch auf rege Beteiligung.

Grüße
Bastian

PS wenn ich mal programmiere versuche ich mich ein wenig an den Prinzipien des Test Driven Developments und den Grundideen der "Extremen Programmierung" zu orientieren.

Genau, ich hoffe dass viele, die grosse Erfahrung aufweisen, an diesem Thread sich beteiligen, denn so könnten evenutell sinnlose Fragen eher vermieden werden, wenn dass Desing ein bisschen mehr im Vordergund ist.

Es wird ja nicht verlangt dass Rainbird, norman_timo, FZelle, herbivore und alle die sehr bewandert sind ihre gesamte Weise der Softwareentwicklung darlegen, sondern eher, was sind die Knacknüsse (wie zum Beispiel vom Entwurf bis zur Erstellung einzelner Klassen) geknackt werden sollten.

Gut jeder der eine Ausbildung in die Richtung SW-Engineering /Entwicklung durchlaufen hat, sollte dies wissen, aber ich denke wenn auch die Hobby-Programmierer (zu denen ich mich auch zähle), mehr Qualität beim Programmieren zu stande bringen, aufgrund der Tipps der Profis im Forum, dann könnte optimistisch gesehen grosser Beitrag an der Qualität der Software-Entwicklung beigetragen werden (Soweit ich mich erinnere ist dass die Signatur von Rainbird 😉 )

Hallo schaedld,

Nun, nach der Durchwälzung der OOT-Literatur und Beispielen ist es auch heute noch ziemlich schwer ein reales Objekt abzubilden, dass eigentlich gar nicht so real ist.

warum sollte es schwerer sein immaterielle Objekte abzubilden als materielle. Ich finde, es spricht sogar einiges dafür, dass das Gegenteil zutrifft.

Was mich interessieren würde, arbeitet ihr nach bestimmten vorgegebenen Prozessen?

Wenn man nicht agile Techniken einsetzt, dann gibt es schon die Phasen Analyse, Design/Entwurf und Programmierung. Nicht zu vergessen die anschließenden Phasen Testen und Release/Deployment/Softwareverteilung. Heute wird man allerdings kaum noch das reine Wasserfallmodel (alle Phasen strikt hintereinander) antreffen, sondern zumindest Zyklen zurück zu früheren Phasen finden, z.B. wenn man beim Testen einen Fehler im Entwurf findet, geht es zurück in die Entwurfsphase oder sogar in die Analysephase.

Wie geht ihr vor wenn ihr eine Lösung erarbeiten müsst? Ist für euch klar, dass ihr in eurem Programm Interfaces, Singletons benutzen werdet, oder arbeitet ihr nach einer Projektvorlage?

Interfaces und Entwurfsmuster gehören in die Phase Design/Entwurf und kommen erst nach der Phase der Analyse, in der es darum geht, die (Business-)Objekte zu identifizieren. Beim Entwurf guckt man dann eben danach, ob und wo sich Entwurfsmuster einsetzen lassen bzw. wo eine Entkoppelung durch Interfaces angebracht ist. Und ja, ein guter Designer sollte wissen, wo was angebracht ist.

herbivore

Analyse, Design/Entwurf und Programmierung

Wenn wir diese drei klassischen Phasen der Software-Entwicklung anschauen dann hätten wir meiner Meinung nach folgende Tätigkeiten die zur Erledigung sind:

Angenommen wir hätten ein Programm, dass Einen Report aus Active Directory erstellen soll.

1. Analyse: Da stellen sich folgende Fragen:
   a.) Welche Mittel benötige ich für die Aufgabe (Scripting, C# etc.)?
   b.) Auf welcher Plattform soll die Anwendung funktionieren?
   c.) Was für Abhängigkeiten habe ich?

2. Design: Angenommen wird haben uns alle Fragen in der Analyse beantworten können, dann stellen sich daraus im Design die folgenden Fragen:
   a.) Wie wird die Umsetzung in UML durchgeführt. Man hat ja den Bediener der gewisse Aktionen durchführen kann.
   b.) Wenn nach dem reinen OOT Grundsatz gegangen wird, dann hätten wir in unserem Fall die Objekte Active Directory, eine WMI- oder LDAP-Abfrage, einen Report und ein Drucker /Druck-Objekt
   c.) Die Aktivitäten sind das Abfragen, generieren des Reports und das Drucken des Reports.
   d.) Die Eigenschaften /Attribute der einzelnen Objete wären für AD = OU, Benutzer, Computer etc. Für die WMI- oder LDAP Abfrage müssten die gleichen Eigenschaften wie für das AD gewählt werden, indem man die Abfrage Klasse von der AD Klasse erben lässt. Somit hätten wir die gleichen Attribute /Eigenschaften für die Klasse Abfrage zur Verfügung und müssten diese nicht nocheinmal festlegen.

3. Programmierung
   a.) Wenn wir das ganze abstrahieren, dann hätten wir in diesem Fall 2 Klassen. Eine für die Active Directory Abfrage und eine für die das Generieren und Drucken des Reports (Eigentlich sinds ja drei wenn man die Program.cs auch dazu zählt).
   b.) Nun stellt sich die Frage, wie die gemeinsam genutzen Attribute Eigenschaften implementiert werden. Von mir aus gesehen kann man natürlich für jede Klasse immer wieder die gleichen Dinge (Attribute /Eigenschaften /Variablen festlegen) oder man verlagert die Schnittmenge der drei Klassen in eine Singleton Klasse oder in ein Interface ((bitte um Korrektur wenn dies nicht richtig wäre).

Hallo schaedld,

einen Report zu erstellen ist sicher nicht das super Beispiel, um daran OOA und und OOD zu erlernen.

Was deine Schrittfolge angeht: Für mich steht am Ende es OOA schon fest, welche (Business-)Klassen es gibt und zumindest auch deren wichtigste Eigenschaften und Methoden. Um das auszurücken wird man auch schon in der OOA-Phase UML einsetzen.

Wie man Klassen, Methoden und Eigenschaften finden kann, steht in Kurzform in statisch, Klassenvariable oder lokal? .

Für die Vertiefung empfehle ich - wie auch in dem anderen Thread angesprochen - die Lektüre entsprechender Bücher. Auch wenn du sagst, du hättest das schon gemacht, denke ich, dass du Antworten auf allgemeine Fragen eher aus Büchern als aus einem Forum bekommst. Denn wie du schon richtig erkannt hast, müsste man sich die Finger wundschreiben, wenn man auch nur eine der Phasen halbwegs allgemeingültig beschreiben sollte.

herbivore

Für die Vertiefung empfehle ich - wie auch in dem anderen Thread angesprochen - die Lektüre entsprechender Bücher. Auch wenn du sagst, du hättest das schon gemacht, denke ich, dass du Antworten auf allgemeine Fragen eher aus Büchern als aus einem Forum bekommst. Denn wie du schon richtig erkannt hast, müsste man sich die Finger wundschreiben, wenn man auch nur eine der Phasen halbwegs allgemeingültig beschreiben sollte. Ich dachte eher daran nicht im Detail sondern eher als Ablaufprozess wie das Ganze entsteht.

Für die Vertiefung empfehle ich - wie auch in dem anderen Thread angesprochen - die Lektüre entsprechender Bücher. Auch wenn du sagst, du hättest das schon gemacht, denke ich, dass du Antworten auf allgemeine Fragen eher aus Büchern als aus einem Forum bekommst.

Nur so als Anmerkung: Theorie und Praxis sind immer zweierlei Paar Schuhe, sodass es sicherlich hilfreich ist wenn man einen Leitfaden hätte.

Mir ist klarr dass das Sprichwort "Übung macht den Meister" hier sicherlich angebracht ist, aber mal abgesehen davon wäre es sicherlich als Ergänzung zu den Büchern sicher wertvoll, wenn Profiwissen der Forums-Korifäen einfliessen würde. Sei es auch nur in der Art und Weise, dass im OOA die Anforderungen im Pflichtenheft genaustens überprüft werden müssen.

Sicherlich wird sich dass Wissen und können auch durch die Erfahrung erweitern, ich bin aber der Meinung dass heute weniger Software von 0 auf entsteht als dass man sie erweitern und pflegen muss, daher werden die wenigsten die in grossen Firmen tätig sind, sich noch lange mit OOA, OOD beschäftigen dürfen.

Ich denke, dass Du und die anderen Betreiber des Forums sicherlich an 5 bis 10 Jahre Erfahrung in dieser Materie habt, denn sonst wären Dir die Business-Klassen nicht schon zeitgleich mit der OOA bekannt 😉

Mir fehlt bei deinem ganzen ansatz das Testen.

Ich kenne einiges an Cobolentwicklern, da ich auch schon ein paar tage dabei bin,
und leider ist in der Zeit des Romane schreibens ( sorry 😉 diese wichtige Phase
in der Entwicklung viel zu kurz gekommen, was dann zu der heute immer noch
weit verbreiteten BananenSoftware führt.

Stichworte wie TDD solltest Du Dir im gleichen zuge wie OOA/OOD ansehen.

Also eigentlich sollte das dann eher so aussehen:

Kunde ( kann auch innerhaus sein ) setzt sich mit Architekt zusammen.

K beschreibt, was er haben will, nicht wie er es gelöst haben will.

A setzt sich hin und schreibt "Stories" in denen ganz detailiert steht was die SW
können soll ( immernoch ohne die herangehensweise ).
In dieser Phase werden alle Interfaces erstellt, die die Funktionalitäten abdecken.

Hierraus werden dann als erstes die Tests erstellt, die alle im ersten anlauf
Rot sein sollten.

Jetzt wird sich hingesetzt, und die herangehensweise/Technologie zur Implementation
ausgearbeitet.
Hierbei immer bedenken:

"ES WIRD NUR SOVIEL IMPLEMENTIERT, WIE GEBRAUCHT WIRD, UM ALLE TESTS AUF GRÜN ZU BRINGEN!"

Dieser Prozess lässt sich dann beliebig erweitern und verschachteln.
Wie der A die Anforderungen schreibt, wie die Interfaces erstellt werden
( UML oder Ölgemälde ) ist dabei dann geschmacksache.
Aber so geht nur getestete SW aus dem haus.

Wie der A die Anforderungen schreibt, wie die Interfaces erstellt werden
( UML oder Ölgemälde ) ist dabei dann geschmacksache. Hier redest Du jetzt von Interfaces in C# oder?

Hallo schaedld,

nein, ich denke er meint Schnittstellen in dem Sinne, dass festgelegt wird, welche Methoden mit welchen Parametern und Rückgabewerten eine Klasse hat.

herbivore

Hallo herbivore

nein, ich denke er meint Schnittstellen in dem Sinne, dass festgelegt wird, welche Methoden mit welchen Parametern und Rückgabewerten eine Klasse hat.

Ah ok, dann für den Hinweis.

Es kommt hierbei auf die grösse der Lösung an.

Ist es ein "Wochenprojekt" kann der A gleich die wirklichen Interfaces implementieren und vorgeben.

Hat den Vorteil das auch gleich alle test mit den concreten Implementationen funktionieren.
Ansonsten werden die "echten" interfaces im zuge der Testimplementation erstellt.

Ohne dieses ist ein testen der echten Klassen ja nicht wirklich möglich.

Hallo FZelle,

nur hat man doch auch bei großen Projekten bei weitem nicht für jede Klasse auch echte Interfaces, also im Sinne des interface-Schlüsselwort.

herbivore

Alles was als Funktionalität vorgegeben wird sollte Interfaces haben.
Schon um die Funktionalität testen zu können.

Wie willst Du sonst unabhängig von der echten Implementierung die
Fall Tests machen?

Hallo FZelle,

du meinst Tests mit Mock-Klassen? Ich nenne die Mock-Klassen einfach genau wie die echten Klassen. Und bestimmte durch das makefile welche Klassen zusammen compiliert werden. Dafür echte Interfaces zu verwenden, halte ich für unnötig redundant und für ungünstig. Insofern kann ich der Aussage

Alles was als Funktionalität vorgegeben wird sollte Interfaces haben.

nicht zustimmen.

herbivore

Jedem das seine 😉

Ich halte es für sinnvoll beim start der Codingphase, alle Interfaces und Tests
bereits fertig zu haben ( soweit das machbar ist ).

Dann erlebt man keine Überraschungen.

Aber das ist genauso geschmacksache wie Pairing, TDD i.a. und oder UML.

Hallo FZelle,

ich weiß nicht, ob wir aneinander vorbei reden.

Dass die Schnittstellen der Klassen (Methodennamen, Parameter, Rückgabewerte) vor Beginn der Coding-Phase festgelegt sind, halte auch ich für sinnvoll, insbesondere natürlich bei den Klassen, die von einem anderen Programmierer benutzt werden als dem, der die Klassen implementiert.

Ich halte es nur nicht sinnvoll, für alle Klassen echte Interfaces (per interfaces-Schlüsselwort) zu definieren.

herbivore

Jedem das seine 😉 So mehr oder weniger ist dass auch mit OOT denke ich. Es kommt immer auf die Person drauf an die das Programm entwirft. Ich denke es kann zu 60%, 70% oder höher an der OOT liegen oder auch nicht. Funktionieren tut's sicherlich und leider habe ich kein Patentrezept für die Erstellung gefunden.

Bin gerade dran ein Klassendiagramm zu erstellen, welches ich dann verwenden will und würde gerne, wenn ich damit fertig bin, euch um Rückmeldungen bitten, was noch besser gemacht werden kann und was alles nicht korrekt ist.

FZell und herbivore ich danke euch, für die bisherigen, wertvollen Inputs und hoffe dass noch mehr folgend werden.

@herbivore:
Nein, wir reden nicht aneinander vorbei.
Ich bin schon der Meinung, das Schnittstellen, die Vordefiniert sind auch genauso
implementiert werden sollten, also macht es sinn auch Interfaces gleich zu deklarieren.

Sonst kann man Interfacedefinitionen doch auch gleich sein lassen, wenn man
diese dann nicht benutzen will.

@FZelle

Sonst kann man Interfacedefinitionen doch auch gleich sein lassen, wenn man
diese dann nicht benutzen will. Dann ist rein theoretisch jedes Drittsystem auf dass man zugreift eine Schnittstelle und müsste per Interface referenziert werden.

Jain.

Interfaces sind nur dafür gedacht um sicherzustellen, das die Minmalanforderungen
an das Object erfüllt sind.

Nur weil etwas ein Interface implementiert, heist nicht, das man auch nur darüber zugreifen muss.
Eine List<byte> implementiert z.B. IList, aber zugreifen würde ich schon lieber
auf die typsicherere version.

Aber im Grunde ist alles, was bei der Implementation als "Ansprechpartner" oder Schnittstelle definiert ist ja ein Interface.

Und genauso sollte man es auch behandeln.

Ist ja auch durch die refactoring Möglichkeiten von VS nicht wirklich mehraufwand.

Aber nochmal, nur weil etwas ein Interface implemeniert,muss man dieses nicht so benutzen.

Nur so als erste Zusammenfassung:

1. Schnittstellen wie Oracle Verbindungen würdet ihr als Interfaces implementieren? Oder hab ich da was falsches verstanden?

2. Texte, Statusmeldungen und Verbindungszeichenfolgen wären dann gemäss der obigen Logik in Ressourcen-Dateien zu speichern.

Original von herbivore
Ich halte es nur nicht sinnvoll, für alle Klassen echte Interfaces (per interfaces-Schlüsselwort) zu definieren.

Interfaces und Unit-Testing sind ein gutes Gespann. Das allein kann ein guter Grund sein, Interfaces anstelle von konkreten Klassen zu verwenden. Explizite Mock-Klassen sind unter .NET ein großes Problem, weil man die Mock-Klassen von der "Original-Klasse" ableiten muss. Und das ist - anders als in Java - schon deswegen ein Problem, weil nicht alles per Default virtual sind. Interfaces sind daher die Rettung.

Dann würde ich ja mit meiner ersten Aussage völlig korrekt liegen.

Hallo svenson, hallo FZelle,

ich kann gar nicht glauben, wie exzessiv ihr mit Interfaces arbeitet. Ich nenne die Mock-Klassen wie gesagt genauso wie die echten und mache den Rest über die Steuerung des Build-Processes. Ich kann kaum glauben, dass sich der Aufwand mit den Interfaces lohnt, zumal dann die Erzeugung der Objekte immer über irgendwelche Erzeugungsmuster (z.B. abstrakte Fabrik) laufen muss, was die Software zusätzlich und m.E. unnötig verkompliziert. Oder übersehe ich da was?

Hallo schaedld,

zu 1. So wie ich es verstehe, verwenden die beiden noch viel mehr Interfaces. Ich möchte mich aber gegen den von den beiden beschriebenen Gebrauch von Interfaces aussprechen.

Aber zu deiner konkreten Frage: Ein Interfaces für eine Oracel-Verbindung wäre eher kontraproduktiv. Wenn dann wäre ein Interface für eine Datenbank-Verbindung sinnvoll und eine konkrete Klasse, die das Interfaces für eine Oracle-Verbindung implementiert. Dann und nur dann hätte man nämlich die Möglichkeit, die konkrete Klasse durch eine andere Klasse zu ersetzen, die z.B. eine DB2-Verbindung implementiert, ohne das Programm, das über das Interface zugreift, ändern zu müssen. Vielleicht hast du es so gemeint, aber ich denke diese Klarstellung ist wichtig. An solchen Stellen sehe ich Interfaces als sinnvoll an.

zu 2. ja, das ist sinnvoll, inbesondere wenn man die Anwendung später lokalisieren will.

herbivore

@herbivore
Danke Dir für die Rückmeldung.

Aber zu deiner konkreten Frage: Ein Interfaces für eine Oracel-Verbindung wäre eher kontraproduktiv. Wenn dann wäre ein Interface für eine Datenbank-Verbindung sinnvoll und eine konkrete Klasse, die das Interfaces für eine Oracle-Verbindung implementiert. Dann und nur dann hätte man nämlich die Möglichkeit, die konkrete Klasse durch eine andere Klasse zu ersetzen, die z.B. eine DB2-Verbindung implementiert, ohne das Programm, das über das Interface zugreift, ändern zu müssen. Vielleicht hast du es so gemeint, aber ich denke diese Klarstellung ist wichtig. An solchen Stellen sehe ich Interfaces als sinnvoll an. Genau wegen diesen "Kleinigkeiten" die man doch sicher beachten sollte, wenn man programmiert habe ich den Thread eröffnet, dass alle die nicht so stark sind sich hier ein Bild machen können.

Also könnte ich am konkreten Beispiel sagen:

1. Ich habe eine Oracle Klasse die "nur" Datenbank Kommandos (INSERT, UPDATE, DELETE, SELECT) durchführt
2. Ich habe ein Interface welches mir für die Oracle Klasse die die Kommandos bereithält, die Verbindung zur Verfügung stellt.

Eine Frage drängt sich mir noch auf: Ist es sinnvoll die ConnectionStrings und eventuelle vom Programm generierte Meldungen (selber erstellte) in der app.config zu speichern? Die Verbindung ja, dass habe ich in einem anderen Thread von Golo gelesen, aber was ist mit den Mitteilungen die über Console.WriteLine() ausgegeben werden? Ist dies sinnvoll? Wie exzessiv sollte man die resx brauchen? Gibt es da Nachteile wenn man alle seine verwendeten Strings darin speichert (Ich habe sie bis jetzt nicht verwendet, da meine Projekte eher im überschaubaren Rahmen waren 😉 )

Hallo schaedld,

Also könnte ich am konkreten Beispiel sagen:

ich würde das genau andersherum sehen. Wenn du eine konkrete Klasse für Oracle als Basis nimmst und deren Methodensignaturen dann in ein Interface übernimmst, dann landen in der Regel irgendwelche Oracle spezifischen Sachen im Interface und man muss sich verbiegen, um das Interface für eine andere Datenbank implementieren zu können. Es sollte also immer das Interface (allgemein für Datenbank, ohne spezifische Annahmen über eine konkrete Datenbank) im Vordergrund stehen und erst dann sollte man es für bestimmte Datenbanken implementieren.

aber was ist mit den Mitteilungen die über Console.WriteLine() ausgegeben werden?

Texte gehören, wenn man das Standardvorgehen verwenden will, in Ressourcen-Dateien (Stichwort, Satelliten-Assemblies), nicht in die app.config.

herbivore

Das mit der Anzahl der Interfaces ist relativ 😉

Ausserdem arbeite ich schon etwas länger mit CAB/SCSF und da ist so ziemlich
alles sowieso über interfaces geregelt.

Das Problem bei getrennten Interfaces für testen ( Mocks ) und den realen
Interfaces ist doch, das du nicht die wirklichkeit, sondern deine "zurechtgerückte"
wahrheit testest.

Deshalb, und weil freiheit bei Entwicklern nicht in jedem Fall zielführend ist,
bin ich dazu übergegangen alles per Interface vorzudefinieren, was eine
einzuhaltende Schnittstelle darstellt.
Dafür sind Interfaces ja auch gedacht.

Und im gegensatz zu vielen Unittestern, teste ich nicht alles und jedes, sondern
nur alles was ein Public interface implementiert, denn nur das soll ja nach aussen
hin eine gleichbleibende Implementierung gewährleisten.

Was die klassen damit intern machen ist mir schnurtz.

Original von herbivore
ich kann gar nicht glauben, wie exzessiv ihr mit Interfaces arbeitet. Ich nenne die Mock-Klassen wie gesagt genauso wie die echten und mache den Rest über die Steuerung des Build-Processes. Ich kann kaum glauben, dass sich der Aufwand

Was machst Du, wenn Du nach dem Build eine Klasse austauschen musst?

Original von herbivore
mit den Interfaces lohnt, zumal dann die Erzeugung der Objekte immer über irgendwelche Erzeugungsmuster (z.B. abstrakte Fabrik) laufen muss, was die Software zusätzlich und m.E. unnötig verkompliziert. Oder übersehe ich da was?

Ein Microkernel macht genau das. Im Programm sagt man ihm nur, gib mir eine Instanz für Interface ISonstwas, und auf welche konkrete Klasse dieses Interface verweist, wird extern per XML-Konfiguration festgelegt.

So kannst Du bequem programmieren, und kannst sämtliche Komponenten, die das gleiche Interface implementieren, jederzeit untereinander austauschen.

Hallo Golo,

Was machst Du, wenn Du nach dem Build eine Klasse austauschen musst?

musste ich noch nicht. Im Zusammenhang mit den Mock-Objekten reden wir ja eh über die Entwicklungs- und Testphase. Wenn ich es bräuchte würde ich natürlich Interfaces benutzen, keine Frage.

Ein Microkernel macht genau das.

Ja, das ist mir klar. Allerdings ändert das ja nichts an meiner Aussage:

was die Software zusätzlich und m.E. unnötig verkompliziert.

Wenn ich für jede Klasse, auch bei denen vielen, die sich vermutlich nie austauschen werde, Interfaces verwende, brauche ich immer mindestens einen zusätzlichen Blick auf die XML-Datei, um zu wissen welche Klasse denn nun tatsächlich angesprochen wird. Oder fachlicher ausgedrückt, ich habe in vielen Fällen eine zusätzliche Indirektionsstufe.

Ich versehe den Sinn und Nutzen von Interfaces und Microkernel schon, aber doch nur da, wo man es braucht. Nur scheinbar sehe ich die Notwendigkeit an sehr viel weniger Stellen als ihr.

herbivore

Ich glaube da reden wir jetzt aneinander vorbei.

Ich spreche hier nicht von der Adresse, der Textbox o.ä.

Ich meine so sachen wie Validierung.
Alles was Validiert werden soll, implementiert eben IValidation.
Alles was persistiert werden könenn soll demnach IEntity ( ist historisch der name ).
Die klasse zum persistieren selber dann IEntityMapper und so weiter.

Wenn man dann mit IOC arbeitet ist das dann alles recht simple zusammenzuschrauben.

[ServiceDependency]
public IEntityMapper m_Mapper{get;set}

Ist dann halt deutlich einfacher auch mit verschiedenen Mappern zu machen.
Und dann relativiert sich auch die Anzahl ( es sind wie schon oft erwähnt garnicht so viele )
und auch die Benutzung ist garnicht unübersichtlich.

Wenn sich die Diskussion so gut entwickelt, könnte ich ja sagen, dass Ereignisse in einem Programm selten bis gar nie verwenet werden müssen, denn eine Methode ist ja eine Aktivität die wiederum als Ereignis im Gesamtkontext angesehen werden kann.

Wie sieht es bei euch aus?

Dann bist du noch nicht in der Windows Welt angekommen, bzw Begriffe wie
Lose kopplung sind auch noch bömische dörfer für sich.

Vielleicht solltest Du dich ersteinmal von deiner alten Proceduralen Welt lösen,
mal komplett in etwas ganz anderes hineinlesen, und dann mal zurückschauen,
ob Du immer noch dieser Ansicht bist.

Ich empfehle dir als Schock mal acropolis.
http://windowsclient.net/acropolis/

Danach wirst Du wissen warum interfaces, warum ereignisse und noch einige andere sachen mehr.

Hallo schaedld,

hm, Interfaces und Ereignisse dienen zwar beide der Entkoppelung, haben aber sonst nicht viel miteinander zu tun. Wie du also zu dem Schluss kommst, dass in einem Programm selten bis gar nie verwendet werden müssen, kann ich also nicht ganz nachvollziehen. Insbesondere in Windows-Forms-Programmen wird man nicht ohne (viele) Events auskommen.

herbivore

Hallo zusammen,

ich kenne nur diese Vorgehensmodelle: Wasserfallmodell, V-Modell und Spiralmodell. Die Agile Software-Entwicklung verwede ich falls ich etwas daheim machen muss 😉

Mein ansatz ist:

1. Requirements Engineering
   Fragen wie: warum, was, wie, wofür. Hier werden die Anforderungen eine Rolle spielen wie: Funktionale und nichtfunktionale, GUI, Interface Anforderungen.
   Am besten für jede Anforderung ein Testfall erstellen. Was auch wichtig wäre, sind Use cases (Szenarios erstellen).

2. Software Design/Architektur
   Architektur:
   Architektur mache ich meistens als dreischichtige oder mehrschichtige Architektur. Wichtig sind die saubere definierte Schnittstellen. Z.B. Client Layer (GUI) - Logical Layer (Public Services) - Data Abstracion Layer (private Services und Persistence Framework) - Data storage Layer (DB, File System).
   Ich benutze oft MVC:
   Das Data Model versuche ich generisch zu halten soweit es geht. So kann ich verschiedene Formate im Data Model speichern. Die Zugriffe auf das Data Model laufen über eine Facade, so ist für den Benuter egal wie das Data Model aufgebaut ist und die Zugriffe werden vereinheitlicht. Das Data Model füllen mache ich über Converter (die IConvert implementieren) damit habe ich so eine Art von Sternkonverter erreicht. Beispielhaft Ich kann in das Data Model mit Daten im Format X füllen und im XML-Format rausholen. Somit bin ich Formatunabhängig.
   In Forms empfange ich die Nachrichten und leite weiter an controller, der Controller bearbeitet dann die Anfragen und das Ergebnis leitet weiter an GUI. Damit kann ich leichter GUI austauschen (weil ganze Logik im Controller drin ist), habe ich schon öfters gemacht und gehts super schnell. Tja, und so können auch die NUnits Tests (für Logik) leichter durchgeführt werden (da brauche ich GUI nicht bedienen).

Design:
na ja, hier müssen die Objekte, Attribute, Methoden usw. erkannt werden. Z.B.
Substantiv --> Klasse, Adjektiv --> Attribut, Verb (Verhalten) --> Methode
Hiwe wird man auch mit Design Patterns arbeiten müssen.

3. Implementierung
   Da weiss jeder wie es gehen soll 😉 Kommentare nicht vergessen.

4. NUnit
   Ich mache meistens so Grey-Box-Test.

Diese Werkzeuge sind bei der Entwicklung sehr nützlich:

• NUnit
• CruiseControl.NET-CCTray
• log4net
• Enterprise Architect
• CVS, ClearCase oä.
• doxygen, Robohelp oä.

Grüße

Robmir

Das was Du da über den Controler sagst, hört sich für mich aber nicht nach
MVC sondern nach MVP an 😉

ja hast Du recht, habe ich vergessen zu sagen, dass es nur an MVC angelehnt ist. Bei MVC wird View und Controller meistes zusammengefügt.
Um Alleskönner zu vermeiden benutze ich meistens mehrere Controller wie: ApplicationController, ContextController....

Ich hatte eher die aussage

In Forms empfange ich die Nachrichten und leite weiter an controller, der Controller bearbeitet dann die Anfragen und das Ergebnis leitet weiter an GUI.

Das ist die Funktionsweise bei MVP.

😁 ma lernt immer was neues, ehrlich gesagt ich habe von MVP noch nie gehört 8o aber danke für die neue Information 🙂

Hallo Herbivore
Da ich momentan "nur" im Schreiben von Konsolen-Anwedungen (da Benutzerinteraktion nicht gewünscht) am Schreiben bin, verwende ich keine Ereignisse (was wohl eher prozedural entspricht). Ich teile das Ganze aber schon in Klassen auf und gehe nach den hier besprochenen Grundsätzen.
Micrsoft sagt so oder so, dass wenn eine Benutzerinteraktion eintritt mit Ereignissen hauptsächlich gearbeitet wird.
Ereigniss-Beschreibung gemäss MS

Wenn ich dass Ganze so ansehe, dann könnte man als Ereignisse alles festlegen was einen Status zurück gibt.

Als Beispiel ein Ping Programm: Das Ereignis wäre ja das Pingen und wenn diesen nicht erfolgreich ist, dann wird zum Beispiel die AKtion (Mehtode) weitere dreimal angeworfen bis ein NOK kommt.

@FZelle

Vielleicht solltest Du dich ersteinmal von deiner alten Proceduralen Welt lösen,
mal komplett in etwas ganz anderes hineinlesen, und dann mal zurückschauen,
ob Du immer noch dieser Ansicht bist. Dass bin ich ja gerade dran, aber dass ist nicht ganz so einfach wie man sich's wünschen würde 🙁
Wie hast Du dass den gemacht? Bist Du direkt in die OOT orientierte SW-Entwicklung oder bist Du quer von der prozeduralen Welt her eingestiegen?

EDIT:
Nur sol als Zusammenfassung: Wenn ich Entkopple, dann gehe ich nach dem Grundsatz, dass allgemein gültige Sachen (wie Abfragen) in Interfaces implementiert werden und wenn zum Beispiel der OracleNamespace für das Öffnen und Schliessen einer Verbindung referenzieren muss, dies in einer separaten Klasse erledige, damit ich das Interface (welches die Abfragen DB-unabhängig bereitstellt) immer wieder verwenden kann. Dann wäre ich mit folgendem Klassendiagramm nicht ganz auf dem Holzweg oder?

Tja, das ist eine gute frage.

Ich habe damals mit dem VC20 und Comodore Basic Angefangen.
Danach dann C ( C++ gab es noch nicht wirklich, der Transpiler hiess Glockenspiel,
falls sich daran jemand erinnert ).
Danach habe ich TPascal 3-5 durchlaufen.

Dann kam der Einstieg per C++ und Objectpascal ( TPascal 6 ).
Das ist aber schon 15 Jahre her.
Wenn man das dann also so lange macht, kann man sich nicht mehr so wirklich
dran erinnern wie der Einstieg damals war.
Ich kann Dir nur sagen, das die Informationen bei weitem nicht so umfangreich
waren.
Auch das WWW und damit Foren waren nicht wirklich vorhanden.

Das ist aber schon 15 Jahre her. Das ist summasummarum ca. 15 mal länger als ich es verwende 8o

Auch das WWW und damit Foren waren nicht wirklich vorhanden. Das ist so, darum bin ich ehrlich froh dass ich auf die sehr professionelle Hilfe zurück greifen kann.

Wenn ich übrigens zu den Interfaces zurück komme, dann kann ich sagen, dass das eigentlich "nur" Baupläne für weitere Klassen sind, die spezifisch für eine Schnittstelle implementiert werden müssen.

Wie sieht es aus mit dem Diagramm? Ich denke nicht dass ich so falsch liege oder? Denn alles was die anderen Klassen auch brauchen wird ja als Vererbung angesehen.

Schade, keine Diskussionen mehr?

Ich möchte keine Lösung von mir erarbeiten, sondern eher als Denkanstoss dazu geben, damit die komplette Diskussion als "Leitfaden" verwendet werden könnte... 😉

Hallo schaedld,

Schade, keine Diskussionen mehr?

Die Diskussion ist schon jetzt eine der längsten. Insofern würde ich mir mehr Zufriedenheit über die bisherigen Hinweise wünschen und weniger Drängen auf noch mehr Hilfe.

OO lernt man m.E. nur in dem man sich über längere Zeit aus verschiedenen Quellen informiert. Das Forum ist daher nur ein unter vielen Quellen.

Ich habe damals wirklich über ein Zeitraum von ca. 6-12 Monaten alles gelesen, was mit über OO in die Finger kam (Bücher, Artikel in Fachzeitschriften) und habe Konferenzen und Kurse besucht und parallel alles schon Gelernte bei der Entwicklung eigener Programme ausprobiert und angewandt. Und erst am Ende dieser Zeit hatte ich eine ungefähre Ahnung von OO. Und das obwohl meine vorangegangenes Studium schon viele Grundlagen gelegt hatte (z.B. kannte ich abstrakte Datentypen schon). Und da ich mich zudem für jemanden halte, der relativ schnell lernt, denke ich kaum, dass man OO in weniger als 6 Monaten durchdringen kann, wenn man von der prozeduralen Programmierung kommt.

Und gerade weil man viele Quellen braucht - jeder (Buch-)Autor sieht OO etwas anders und legt andere Schwerpunkte - kann und wird dieser Thread eh nicht zu dem ultimativen Leitfaden werden, den du dir wünscht. Du wirst m.E. um noch mehr Lektüre sowieso nicht drum rum kommen.

herbivore

Das kannst Du vergessen, da wir hier in den paar zeilen keine Einführung in OOA/OOD hinbekommen werden.

Auch solltest Du Dir in zukunft angewöhnen nicht so mit Informationen zu geizen,
denn bei "nur" Konsolenprogrammen ist es natürlich, das WindowsEreignisse nicht so häufig vorkommen.

Mal zu deinem Bild:

1. In .NET hat diese Ungarische Notation ausgedient. Sie wird eigentlich nur
   noch von "nicht Nettler" eingesetzt. Intellisense sagt dir schon welchen Typ du hast.

2. Bei deinem Logging nimmst du durch diese Vorgabe bereits die implementation vorweg.
   Besser wäre eine Funktion Write, die dann von einem FileLogger oder MailLogger
   implementiert wird.
   ( Siehe hierzu vielleicht mal Loggingframeworks wie log4Net oder die Enterpriselib ).

3. Insgesammt sind deine Interfaces zu implementationsspezifisch.
   Interfaces sind aber gerade für das gegenteil gedacht.

@FZelle

Insgesammt sind deine Interfaces zu implementationsspezifisch. Dann sollten sie meiner Meinung auch nur bei sehr grossen Projekten eingesetzt werden, wenn absehbar ist, dass das Progarm auf eine andere Plattform zugreifen soll und in diesem Fall eigentlich overdosed.

In .NET hat diese Ungarische Notation ausgedient. Sie wird eigentlich nur
noch von "nicht Nettler" eingesetzt. Intellisense sagt dir schon welchen Typ du hast. Sprichst Du die Variablen-Deklaration an?

@herbivore

Ich habe damals wirklich über ein Zeitraum von ca. 6-12 Monaten alles gelesen, was mit über OO in die Finger kam (Bücher, Artikel in Fachzeitschriften) und habe Konferenzen und Kurse besucht und parallel alles schon Gelernte bei der Entwicklung eigener Programme ausprobiert und angewandt. Und erst am Ende dieser Zeit hatte ich eine ungefähre Ahnung von OO. Und das obwohl meine vorangegangenes Studium schon viele Grundlagen gelegt hatte (z.B. kannte ich abstrakte Datentypen schon). Und da ich mich zudem für jemanden halte, der relativ schnell lernt, denke ich kaum, dass man OO in weniger als 6 Monaten durchdringen kann, wenn man von der prozeduralen Programmierung kommt. Im Moment verschlinge ich auch Massen an Literatur und hoffe dass C# live von Golo durchgeführt wird, dann wäre ich sicherlich dabei. Aber ich gebe Dir recht, dass es einen sehr langen Zeitraum braucht um OOT wirklich zu verstehen und sich auch schon fast os zu verständigen 😉

Ich danke auf jedenfall für den Input den ihr alle gemacht habt und denke dass dieser Beitrag mir und vielleicht dem einen oder anderen "Anfänger" hilfreich sein kann, bei der Bewältigung seiner Aufgaben im Bereich C# und OOT.

Dann sollten sie meiner Meinung auch nur bei sehr grossen Projekten eingesetzt werden, wenn absehbar ist, dass das Progarm auf eine andere Plattform zugreifen soll und in diesem Fall eigentlich overdosed.

Dann solltest Du mal in deinen vielen Büchern nachlesen wofür Interfaces gedacht sind.
Wenn Du z.B. einem Logger schon vorgibst, das er File und EMail implementieren
soll, kannst Du auch gleich auf ein Interface verzichten.

Und ja, ich meinte die Variablendeclaration.
Dieses Thema haben wir hier öfter.

@Fzelle

Dann solltest Du mal in deinen vielen Büchern nachlesen wofür Interfaces gedacht sind.
Wenn Du z.B. einem Logger schon vorgibst, das er File und EMail implementieren
soll, kannst Du auch gleich auf ein Interface verzichten.

Und ja, ich meinte die Variablendeclaration.
Dieses Thema haben wir hier öfter. War dass jetzt ironisch, oder wie? Ich habe genau ein Buch und dort ist beschrieben für was ich Interfaces benutzen kann /soll. Ich sehe den Einsatz von Intefaces eher so, dass sie dort eingesetzt werden wo man daran bedacht ist dass ganze Programm wieder zu verwenden aber auf eine andere Plattform. Beim Looger wollte ich auch kein Interface erstellen, denn wenn für alles ein Interface erstellt wird, dass ich als Vorlagenschablone verwenden will, dann habe ich ja die doppelte Arbeit.

Nur so neben bei: Ich habe ja in einer meiner vorherigen Antworten herbivore zugestimmt, dass es länger als 6 bis 12 Monate dauert bis man einigermassen "sattelfest" in der Materie ist. Und da ihr zwei zusammen schon fast 30 Jahre OOT Programmiererfahrung habt ist dass ein gewaltiger Vorsprung gegenüber mich von gerade mal 1 Jahr 😉

Also bitte ich ein bisschen um Nachsicht, auch wenn ich über 500 Beiträge /Antworten habe (was nicht alles Fragen sind 😭 )

Als reine Zusammenfassung auf obiges Beispiel aus dem Beitrag Vererbeung, Interfaces etc. kann ich ja sagen, dass ich ein Interface schreibe, für alle Methoden die von jeder Klassen (LogWrite) verwendet werden und dieses Interface dann den jeweiligen Klassen vererbe die diese Methode implementieren sollen, dann hätte ich die Mehrfachvererbung. Sehe ich dass so korrekt?

Hallo schaedld,

Ich habe genau ein Buch

das hatte ich auch falsch verstanden. Du solltest auf jeden Fall mehrere lesen, auch nicht unbedingt nur welche für C#, sondern auch welche zu OO allgemein oder welche zu anderen OO Sprachen. Auch wenn es sehr alt ist, kann ich z.B. Objektorientierte Softwareentwicklung von Bertrand Meyer empfehlen. Mir persönlich hat das sehr geholfen.

Ich sehe den Einsatz von Intefaces eher so, dass sie dort eingesetzt werden wo man daran bedacht ist dass ganze Programm wieder zu verwenden aber auf eine andere Plattform.

Nein, das wäre zu kurz gesprungen. Interfaces kann man dafür verwenden, aber auch ohne Wiederverwendung und/oder Portierung sind Interfaces sinnvoll.

... dann hätte ich die Mehrfachvererbung. Sehe ich dass so korrekt?

Nein, wenn eine Klasse mehrere Interfaces implementiert, geht das in Richtung Mehrfachvererbung. Wenn man ein Interfaces in mehreren Klassen implementiert hat das nichts mit Mehrfachvererbung zu tun. Siehe auch http://de.wikipedia.org/wiki/Vererbung_(Programmierung)#Mehrfachvererbung

Aber lass uns das Interface-Thema bitte beenden. Es gibt schon viele lange Thread zu dem Thema. Da bauchen wir keinen zusätzlichen.

herbivore

Hallo herbivore
Ich wollte auch nicht weiter auf den Interfaces rumreiten 😉

Die Materie ist sehr "schlecht" greiffbar und auch sonst ziemlich abstrakt 🤔

Aus diesem Grund habe ich diesen Beitrag geschrieben, da ich dachte man könnte generell sagen wenn a zutrifft dann muss ich ein (nur als Beispiel) ein Interface implementieren etc.