Static oder wie?

[tfa]

genauso unschlüssig ist es, aus reinem Selbstzweck sinnlos einen bedeutenden Grundsatz einzusetzen

Einverstanden :toll:

Und selbst wenn es nur eine Implementierung des Interface gibt, fallen einem genug Gründe dafür ein, trotzdem auf dem Interface zu arbeiten...

Wenn man diesen Satz etwas umformuliert, wird es deutlicher:

Wenn es erstmal nur eine Implementierung des Interfaces gibt, einem aber gute Gründe dafür einfallen, dass es später einmal mehr geben könnte, sollte man mit Interface arbeiten.

 

[Verjigorm]

oh man, wieso hab ich nur gefragt, war doch klar, dass es so ausartet 😀 :shock: :autsch: :bloed:

Auch wenn ich normal alles OOP mache, finde ich, hier ist ein guter Platz für statische Methodenaufrufe 🙂
Weil die Funktionen keinerlei Bezug zu einer Instanz/Klasse/Objekt haben/brauchen

*closed* für mich persönlich!

 

[byte]

'Programmierung nach Interfaces' ist auch für sich kein Grundsatz den man überall einsetzt,
etwa bei allen Datenklassen, bei JFrames usw,
kein Mensch hat doch wohl ein ganzes Programm nur aus Interfacen?,
insbesondere wieder noch weniger in einfachen Anfängerprogrammen

wenn man das so sieht, dann hat ja static tatsächlich generell jede Berechtigung verloren,
aber das wäre ja noch ein Schritt weiter als ich das bisher hier gesehen habe,
für ALLE Klassen in einem Projekt..

Klar machen Interfaces bei Datenklassen Sinn. Wenn Du Deine Anwendung über verschiedene Schichten kaspelst, willst du bestimmt nicht die konkreten Implementierungen über deine Fassaden sichtbar machen, sondern eben nur die Interfaces. Auch im Kontext der GUI-Programmierung sind Interfaces natürlich sinnvoll, z.B. bei der Umsetzung eines MVC-Konzepts (gemeinsame Schnittstelle aller Views und Controller in Interfaces extrahieren).

In den meisten Fällen ist es einfach Faulheit, wenn man Funktionen static macht. Nicht selten rächt sich das dann irgendwann, denn es ist Gang und Gebe, dass sich Anforderungen mit der Zeit ändern. Vielleicht gibts übermorgen doch noch eine alternative Berechnungsvorschrift? Dann bist Du froh, wenn Du Dir nicht jegliche Möglichkeit der Polymorphie verbaut hast.

 

[SlaterB]

wie gesagt einer der Grundsätze: unmöglich zu verbauen und jederzeit kinderleicht nachzurüsten,
bei eindeutigen Klassennamen und den einfachen statischen Aufrufen fast schon per Replace

 

[byte]

Sowas ist natürlich auch immer ein riesen Spaß in großen Projekten mit vielen Entwicklern. Vor allem wenn man auf mergen steht. :roll:

 

[SlaterB]

das ist ein gutes Argument, wenngleich es mir persönlich auch noch nie ernstlich begegnet ist,
wenn das mal passiert werde ich vielleicht auch so denken

 

[hupfdule]

Sowas ist natürlich auch immer ein riesen Spaß in großen Projekten mit vielen Entwicklern.

Gerade in großen Projekten merkt man den Horror, den eine unnötige exzessive Verwendung von Interfaces und Design Pattern erzeugt. Denn großen Projekte sind ja nun mal schon von sich aus komplex. Wenn dann noch Abstraktionsschichten enthalten sind, die nur aus Prinzip eingefügt wurden, obwohl klar ist, dass diese gar nicht nötig waren, erzeugt das massiven Mehraufwand bei der Weiterentwicklung. Gerade dadurch kann man sich etwas verbauen, nämlich eine vernünftige Wartbarkeit.

 

[byte]

Dem kann ich so nicht ganz zustimmen. Ich gebe Dir insofern recht, dass der Code durch die Verwendung von Pattern auf den ersten Blick nicht umbedingt übersichtlicher oder leichter verständlich wird. Die Wartbarkeit steigt aber auf jeden Fall durch den Einsatz der Pattern - man muss dafür aber das Pattern verstanden haben.

 

[maki]

IMHO hat man in großen Projekten gar keine andere Chance vernünftige Wartbarkeit zu bieten als Design Patterns einzusetzen und die auch zu dokumentieren, sei es nur mit ein paar schlichten UML Diagrammen welche die Klassen und die Patterns darin zeigt.

(Anti) Pattern welche die Wartbarkeit erschweren gibt es auch, Singleton zB., ist aber wohl bekannt und dokumentiert.

Einfach nur zu "Übungszwecken" Pattern zu verbauen kann allerdings schnell schief gehen, wenn sich die Autoren über die Vor-/Nachteile oder gar den eigentlichen Zweck des Patterns nicht klar waren.

zB. wird das Singleton gerne verwendet, um von überall auf ein Objekt zugreifen zu können.
Dafür war es nicht gedacht und genau dieser Anwendungsfall macht oft Ärger, zB. beim testen.

Soll heissen: Patterns können Probleme lösen, oder sie erzeugen.

Zusätzliche Abstraktionsschichten sind eigentlich das allheilmittel der SW Branche *g*

So sagte Butler Lampson 1972:
"All problems in computer science can be solved by another level of indirection."

IME sind richtig angewandte Interfaces&Patterns in großen Projekten ein muss, aber dann bitte richtig.

 

[ms]

... Design Patterns einzusetzen und die auch zu dokumentieren ...

das ist der Punkt, auf den es ankommt.
Komplexität sollte nicht mit fehlendem Verständnis oder mangelndem Überblick verwechselt werden.
Und dazu sind gewisse Dokumentationen notwendig.

Zb. für die Zertifizierung zum SCJD (Sun Certified Java Developer) wird unter anderem ein Dokument verlangt in dem Designentscheidungen dokumentiert werden sollen, also warum verwende ich welchen Pattern.
Ob ein Pattern jetzt sinnvoll, nicht sinnvoll oder gar nicht eingesetzt wurde ist die eine Sache. Aber die Begründung für diese Entscheidung sollte in jedem Fall festgehalten werden.

ms

 

[maki]

Hast Recht ms,

diesen Punkt hatte ich vollkommen vergessen, die Designentscheidungen begründen & Dokumentieren.

 

[ms]

Bitte jetzt nicht denken, dass ich immer alles brav dokumentiere. 😀
In all meinen bisherigen Projekten hat es eine solche Dokumentation nicht gegeben.
Nur mittlerweile erkenne ich die Wichtigkeit guter Dokumentation.
Ich denke es liegt an der bei uns gelebten Projektkultur, dass die Dokumentation nur eine üble Notwendigkeit darstellt.
Und genauso sehen sie dann auch meistens aus.

ms