# Static oder wie?



## Verjigorm (26. Mrz 2008)

Moin,

ich hab momentan folgendes nonkretes Problem:

Ich habe ein Programm mit komplizierter teilweise selbstgezeichneter GUI.
Es gibt massig Hilfsklassen, die für die Gui irgendwelche Dinge berechnen,ausrichten,verändern oder sonstwas machen.
Da ich es eigentlich relativ unnötig finde, von jede dieser Hilfsklassen (momentan etwa ein Dutzend, werden wohl noch mehr) eine Instanz anzulegen, habe ich mir überlegt, ob ich das ganze nicht in statische Funktionen verpacke.
Aber da hier im Forum immer wieder auf OOP hingewiesen wird, wollte ich mal eure Meinung dazu einholen.

Für den Objektgedanken spricht für mich eigentlich nix, was meint ihr dazu?

mfg Verjigorm


----------



## SlaterB (26. Mrz 2008)

Hilfsoperationen passen immer gut statisch,
siehe die Math.xy(), Arrays.xy(), Collections.xy()-Operationen usw.

mach alles nur dann nicht-statisch, wenn es einen guten Grund gibt,
OOP ist kein Selbstzweck


----------



## PollerJava (26. Mrz 2008)

SlaterB hat gesagt.:
			
		

> mach alles nur dann nicht-statisch, wenn es einen guten Grund gibt,



Das ist mal ein anderer Ansatz, ich hab auf der UNI immer gehört, nur das static zu machen, was unbedingt notwendig ist, aber ich sehe immer wieder, dass viele Anfänge zu viel static einbauen und somit den OOP- Gedanken nicht mitbekommen,


----------



## The_S (26. Mrz 2008)

Naja, wenn man OOP kann, dann weiß man auch wo static sinnvoll ist und wo nicht. Was da aber teilweise von Anfängern an static verbaut wird geht auf keine Kuhhaut mehr :roll:


----------



## Verjigorm (26. Mrz 2008)

Nunja, ich mach eigentlich immer alles OOP

aber hier wäre nun der Fall, dass ich 3/4 aller Methoden static machen würde, da ich einfach das Objekt an sich nicht benötige und die Berechnungen etc. einfach aus der Gui-Klasse auslagern möchte.

Wird das dann "nicht zu viel static" ?


----------



## maki (26. Mrz 2008)

3/4 ist definitiv zuviel.

Helper Klassen samt Methoden sind eigentlich nie static, zumindest selten.

Allgemeine Utility Methoden dagegen sind meist static.


----------



## Verjigorm (26. Mrz 2008)

aber was bringt es mir, wenn ich nen Objekt von einer Klasse anlege, die mir lediglich 2 Funktionen bereitstellt?


----------



## maki (26. Mrz 2008)

"Seperation of Concerns" zum Beispiel 

Ist sogar üblich und OO viele Klassen mit wenig Methoden zu haben.


----------



## SlaterB (26. Mrz 2008)

ob wenig oder viele Operationen hat mit statisch oder Objekt erzeugen nix zu tun

'Separation' übrigens


----------



## maki (26. Mrz 2008)

SlaterB hat gesagt.:
			
		

> ob wenig oder viele Operationen hat mit statisch oder Objekt erzeugen nix zu tun


Natürlich nicht, aber 3/4 statische Methoden hat mit OO nix zu tun


----------



## Verjigorm (26. Mrz 2008)

maki hat gesagt.:
			
		

> "Seperation of Concerns" zum Beispiel
> 
> Ist sogar üblich und OO viele Klassen mit wenig Methoden zu haben.



OOOKKK, naja deswegen frag ich ja

Für mich isses nur so, dass die angebotene Funktion quasi kein Bezug zur Klasse hat, deswegen hätte ich alles static gemacht


----------



## SlaterB (26. Mrz 2008)

immer noch: gerne mag man static an sich verfluchen,
aber mit der Separation hat das nun wirklich nix zu tun


----------



## maki (26. Mrz 2008)

SlaterB hat gesagt.:
			
		

> immer noch: gerne mag man static an sich verfluchen,
> aber mit der Separation hat das nun wirklich nix zu tun


Ja, mit static hat das nix zu tun tun.
SoC deswegen weil es nix schlechtes ist, viele Klassen mit wenig Methoden zu haben, siehe vor-vorletzten Post des TS.


----------



## Verjigorm (26. Mrz 2008)

jojo, ich habs ja verstanden 

Wie ist das denn mit Speicherverhalten?
Der Speicherverbrauch ist doch dann so generell gesehen "größer" oder? (auch wenns hier nicht ins Gewicht fällt)


----------



## SlaterB (26. Mrz 2008)

man ey, hast du keine echten Probleme über die du dir Gedanken machen musst? 
die paar Bytes wo jedes Programm standardmäßig schon MegaBytes belegt


----------



## quippy (26. Mrz 2008)

Die Diskussion über zu viel oder zu wenig statische Methoden verstehe ich echt nicht.

In OOP ist die Klassenmethode genauso berechtigt wie die Instanzmethode.

Eine Instanz benötige ich, wenn meine Klasse eine konkrete Ausprägung haben muss (konkret ist also der Kunde Meier).

Eine Instanzmethode benötigt die konrekte Ausprägung der Klasse (klassisch: getter und setter, oder sowas wie "getFullName()", was Vor- und Nachnamen konkateniert)

Eine Klassenmethode verwende ich immer dort, wo eine konkrete Instanz nicht benötigt wird - die Methode als mit den Instanzvariablen nichts am Hut hat.

Wenn man nun eine Helper-Klasse baut, welche allgemeine Routinen für z.B. die Formatierung eines Datums oder die Berechnung zum zentrieren eines Frames auf einem Parent oder Desktop enthält, dann können alle diese Methoden auch statisch sein. Das widerspricht dem OOP-Gedanken in keinster Weise.

Aufpassen muss man, wenn man diese statischen Methoden nicht in eine Helperklasse auslagert, sondern im konkreten Objekt ablegt, also z.B. eine allgemeine Stringkonkatenierungsroutine für zwei Strings als Static im Kunden-Objekt. Das macht wenig Sinn.
Die nächste Frage ist immer, ob man ein Überschreiben der Methode in Subklassen ermöglichen will. Dann wiederum muss man wohl oder übel ohne static arbeiten. In dem Fall kann man aber auch von einer engen Verknüpfung zwischen der Objektinstanz und der Methode sprechen.

Wenn man desweiteren beherzigt, den Klassennamen vor die statische Methode zu schreiben, fällt während dem Coding eigentlich schnell auf, ob man da nun ein Designproblem hat oder nicht.


----------



## Verjigorm (26. Mrz 2008)

quippy hat gesagt.:
			
		

> Wenn man nun eine Helper-Klasse baut, welche allgemeine Routinen für z.B. die Formatierung eines Datums oder die Berechnung zum zentrieren eines Frames auf einem Parent oder Desktop enthält, dann können alle diese Methoden auch statisch sein. Das widerspricht dem OOP-Gedanken in keinster Weise.



Genau deswegen wollte ich diese Funktionen static machen, weil sie einfach nur berechnungen etc ausführen, so wie es die Funktionen von Math auch tun
Werte rein, neue Werte raus. Deswegen seh ich hier Sinn nicht, Instanzen anzulegen


----------



## PollerJava (26. Mrz 2008)

Mal so ein Einwurf von mir, man könnte ja auch lauter Singeltons machen, das wäre dann so ein mittelweg, 

Ich weiß, das das Singleton - Pattern nicht das gelbe vom Ei ist, aber es ist eine alternative bzw. eine Zwischenlösung,

Das Factory- Pattern arbeitet ja auch in die Richtung -> eine Instanz für die Helperklassen kann nur einmal erzeugt werden,


----------



## Verjigorm (26. Mrz 2008)

Singleton ist hier doch garnicht interessant,
ich hab wenn überhaupt doch eh nur eine Instanz der Klasse


----------



## Marco13 (26. Mrz 2008)

Das ist wohl eine Sache, zu der man keine allgemeine Regel aufstellen kann - ausser der, die ich schon ein paarmal geopstet hatte:
- Fields sollten nur static sein, wenn sie es unbedingt sein müssen (und das müssen sie fast nie)
- Methoden sollten static sein, wenn man sie ohne Krämpfe static machen kann

Wenn du sagst, dass die Funktionen "nur irgendwas berechnen", kann man nicht sagen, ob sie static sein sollten oder nicht. Am Beispiel, das weiter oben angedeutet war: Eine Klasse "Kunde" hat Methoden, um sich Vor- und Nachnamen zu holen. Man könnte jetzt eine Methode anbieten

```
String getFullName() { return vor + nach; }
```
Wenn man aber stattdessen auf die Idee käme, sich dafür eine Utility-Klasse zu machen

```
class FullNameOfCustomerGetter
{
    public static String getFullName(Customer c) { return c.getVor() + c.getNach(); }
}
```
dann wäre das etwas, was IMHO in die Kategorie "Krampf" fallen würde...

Muss man wohl von Fall zu Fall enscheiden...


----------



## Verjigorm (26. Mrz 2008)

Jo, das seh ich ein
aber meine Helper-Klassen haben z.B. nicht mal Klassenvariablen


----------



## ms (26. Mrz 2008)

Verjigorm hat gesagt.:
			
		

> Jo, das seh ich ein
> aber meine Helper-Klassen haben z.B. nicht mal Klassenvariablen


Ich finde es ist in Ordnung wenn du alles static machst.
Es gibt kein "zu viel" oder "zu wenig".
Schau dir mal java.lang.Math an, 100% statische Methoden und Felder.
Ich denke deine Klasse erfüllt analog dazu denselben Zweck.

ms


----------



## Verjigorm (26. Mrz 2008)

yup, seh ich auch so, sind halt nen dutzend davon, die ich nach bestimmten "Kategorien" getrennt habe


----------



## maki (26. Mrz 2008)

Hört sich wirklich danach an, als ob static reicht.

Genaues kann man erst sagen, wenn man den Code sieht


----------



## PollerJava (26. Mrz 2008)

Noch ein Einwurf auch auf die Gefahr, dass er nicht zweckmäßig ist aber so weit ich weiß wäre da ja auch das Decorierer- Muster passend, da ich Objekte einhülle und nacheinandere Verhalten hinzufüge,
Das ist ja genau das, was Du da mit den Helper- Klassen versuchst.
Also ich persönlich würde mir eher das Designpattern-- Buch durchsehen, obs da eine NICHT- static Lösung gibt,
wenn man zu viel static macht, is ja gleich die Frage ob mans nicht in C macht (alles schnell ung global)


----------



## Marco13 (26. Mrz 2008)

_aber meine Helper-Klassen haben z.B. nicht mal Klassenvariablen_

Selbst das sagt ja nichts aus: Man kann praktisch ALLE Methoden static machen (wobei Konstruktoren und setter/getter hier eine Sonderrolle einnehmen). Ganz einfach indem das Objekt, auf dem sie arbeiten sollen, als Referenz übergeben wird. (Und - genau so macht das die JVM intern auch :wink: )


```
class Foo
{
    float a, b, result;
    void computeResult() { result = a + b; }
}
```
->

```
class Foo
{
    float a, b, result;
    static void computeResult(Foo foo) { foo.result = foo.a + foo.b; }
}
```

Das macht halt "manchmal" Sinn, aber "meistens" nicht - muss man sich halt überlegen....


----------



## Verjigorm (26. Mrz 2008)

@ Marco13:

Sowas wie "float a, b, result;" existiert in meinen Klassen ja grade nicht, du macht WIEDER ein Beispiel damit ^^


----------



## Marco13 (26. Mrz 2008)

Die statische methode würde dann in der Helper-Klasse liegen, d.h "Foo" wäre eine deiner Klassen, die KEINE Helper-Klasse ist. (Und wenn du NUR Helper-Klassen hast, solltest du dir mal LISP ansehen  :bae: )


----------



## maki (26. Mrz 2008)

Verjigorm,

ohne Code ist das alles nur Spekulation, aber 3/4 static riecht verdächtig...


----------



## Verjigorm (26. Mrz 2008)

Ich hab ja noch keinen Code, nur Modelle

Eine Methode soll z.B. folgendes machen:

Übergabewerte: Liste mit Int-Werten, JPanelbreite
Rückgabewerte: Liste mit Int-Werten

Die Funktion soll die Int-Werte der Liste auf die Breite des Panels transformieren.

Es wird die Spannweite der Int-Werte ermittelt (z.B. 0 bis 13)
dann wird die Panelbreite durch 13-0 geteilt und jedem Int-Wert so eine X-Koordinate in der Ebene zugeordnet.
Die neu erstelle Liste mit X-Koordinaten wird zurückgegeben.
Und die GUI-Klasse kann diese dann anzeigen.

Nix weltbewegendes, klingt für mich halt extrem nach Math-Prinzip über statische Methoden.

Und so Methoden gibt es aktuell 14 geplante, wobei das ständig mehr werden. Und die sind halt in Klassen zusammengefasst

Und die einzige Frage ist nun, ob ich das als statische Methode mache oder halt nicht


----------



## maki (26. Mrz 2008)

Dafür würde ich keine static Methoden nehmen.

Lieber wrapper schreiben, vielleicht sogar das hier bereits erwähnte Decorator Muster.


----------



## Gast (26. Mrz 2008)

Hallo,

auch auf die Gefahr hin mir den Zorn von diversen Personen abzubekommen. Aber wenn es darum geht "sauber" zu arbeiten sollte man auf static verzichten. Ich moechte hier nur ein kurzes Bsp. bzgl. der Helperklassen geben.


```
public class StringHelper {

    public static boolean machEt()...

}

public class Irgendwas {

    public void machirgendwas() {
        ...StringHelper.machEt()....
    }
}
```

Kurzanalyse:

Vorteile:
Das koennen die static Anhaenger sicher benennen...

Nachteile:
Man ist auf die Klasse StringHelper festgelegt, d.h. wenn man die mal Austauschen moechte gibt es Probleme.

Andere Moeglichkeit:

```
public interface StringHelper {

    public static boolean machEt();
}

@Component
public class StringHelperImpl implements StringHelper {

  public static boolean machEt()...

}

public class Irgendwas {

    @Autowired
    private StringHelper _stringHelper;

    private StringHelper getStringHelper() {
        return _stringHelper;
    }

    public void machirgendwas() {
        ...getStringHelper().machEt()....
    }
}
```

Vorteile:
- Man arbeitet gegen ein Interface und kann die Impl ohne Probleme austauschen.

Nachteil:
- Es muss ein DI-Container benutzt werden, z.B. Spring
- Es gibt ein Interface mehr .......


Gruesse

Gast


----------



## SlaterB (26. Mrz 2008)

ein zumeist unnötiger Aufwand, der bei Bedarf kinderleicht nachgerüstet werden kann


----------



## maki (26. Mrz 2008)

> - Es muss ein DI-Container benutzt werden, z.B. Spring


Nicht wirklich, DI setzt keinen speziellen Container voraus 
Spring ermöglicht es "nur", sehr einfach die Implementierungen auszutauschen, konfigueriert wird per XML.

Ansonsten stimme ich dir zu


----------



## Gast von eben (26. Mrz 2008)

> ein zumeist unnötiger Aufwand, der bei Bedarf kinderleicht nachgerüstet werden kann



Aufwand ist immer ein Feind von Qualitaet.

zusaetlicher Aufwand:

1. Erstellen des Interface

2. einfueges eines StringHelper Attributes 

Zu 1.:

Dauer mit der richtigen IDE ca. 1 Minute

2. Template schreiben (2 Minuten) und in der Klasse aufrufen ca. 2 Sekunden.

Also, wegen letztendlich 2 Sekunden Mehraufwand pro Klasse wird auf ein bei groesseren Systemen wichtiges Architekturprinzip verzichtet....

Gruesse

Gast


----------



## SlaterB (26. Mrz 2008)

Operation anklicken, rechte Maustaste, Open Declaration,
brauche ich zig mal am Tag,
wenn man dann nur zum Interface kommt und die Klasse manuell suchen muss, werde ich immer fast wahnsinnig
(Basisklase ginge natürlich auch)

edit:
dazu noch mehrere Hilfsklassen, Separation of Concerns wurde ja schon erwähnt
-> Klasse seitenweise gefüllt ohne echten Nutzwert,

dazu noch Hilfsklassenaufruf aus hunderten bis tausenden Datenobjekten heraus, wer soll die füllen?
alles ein heilloses Durcheinander wenn man so simple Dinge wie Math.max() braucht

selbstverständlich findet man sowas nicht in der Millionenfach-verwenden Java-API (also im einfachen Teil: Math, Collections, Arrays), 
was wäre das für eine unvorstellbare Arbeitszeitvernichtung (ultimativ: System.out, statische Logger  )


natürlich gibt es tolle Anwendungen dafür in wichtigen Stellen der 'groesseren Systeme',
für Allerweltshilfsklassen in Anfängerprogrammen ist das aber keine ernsthafte Alternative


----------



## maki (26. Mrz 2008)

> natürlich gibt es tolle Anwendungen dafür in wichtigen Stellen der 'groesseren Systeme',
> für Allerweltshilfsklassen in Anfängerprogrammen ist das aber keine ernsthafte Alternative


Sehe ich nicht so, Java Anfänger (s/w)ollen doch OO lernen, und Helper waren eigentlich schon immer dynamisch, Utils eher nicht.

Speziell für Viewhelper würe ich keine rein statischen Lösung wählen.


----------



## SlaterB (26. Mrz 2008)

worums genau geht muss man ja individuell festlegen,

> Helper waren eigentlich schon immer dynamisch, Utils eher nicht

mag sein und klingt ja schon anders als 'wenn es darum geht "sauber" zu arbeiten sollte man [generell] auf static verzichten'
was ja zurecht schon im Voraus den 'Zorn von diversen Personen' heraufbeschwor


----------



## ms (27. Mrz 2008)

Gast hat gesagt.:
			
		

> Andere Moeglichkeit:
> 
> ```
> public interface StringHelper {
> ...


Eine statische Methode in einem Interface deklarieren geht nicht.

ms


----------



## SlaterB (27. Mrz 2008)

also auf 'Tippfehler, hier hast du fälschlicherweise static geschrieben' hinzuweisen wäre ja etwas banal, aber richtig 
(ich hatte es nicht gesehen  )

zu unterstellen, dass da jemand mit so viel Erklärung eine statische Operation in einem Interface deklarieren wollte,
ist aber fast schon ein größerer Fehler


----------



## ms (27. Mrz 2008)

SlaterB hat gesagt.:
			
		

> zu unterstellen, dass da jemand mit so viel Erklärung eine statische Operation in einem Interface deklarieren wollte,
> ist aber fast schon ein größerer Fehler


Die Erklärung deutet aber leider nicht auf diesen Tippfehler hin.
Habs nur erwähnt damit jemand, der das hier in vielleicht 300 Jahren liest, nicht glaubt dass es so richtig ist.

ms


----------



## quippy (27. Mrz 2008)

Verjigorm hat gesagt.:
			
		

> Ich hab ja noch keinen Code, nur Modelle
> 
> Eine Methode soll z.B. folgendes machen:
> 
> ...



Hier beginne ich zu grübeln. Wenn Du das JPanel mit übergibst (und nicht einen "int width"), klingt das eher nach einer Methode, welche in den JPanel-Ableitungsbaum gehört und damit nicht static sondern eine Service-Methode sein sollte. 

Also eher etwas der Art 

```
public abstract class CenterableJPanel extends JPanel // Keine Instanzen von diesem Ding hier!
{

   public void centerMeOn(int []ordinates)
   {
      //(....) Voodoo
   }
}
```

Ggf. bietet sich ein Interface an - dann hast Du aber wieder die Wahl der Implementierung... Eine statische Helper-Methode hätte ich erwartet, wenn die Übergabeparameter das Int-Array plus x,y,width,height des graphischen Objektes - also komplett Objekt-unabhängig wären.

Bei Math ist z.B. alles static, da man pro Methode nur einen Übergabewert hat, der nicht als klassifizierung des Math-Objektes dient. Bei einer Klasse "Winkel" mit trigonometrischen Funktionen wäre das aber wieder anders!


----------



## Statischer Gast (27. Mrz 2008)

Stimmt natuerlich static in interface geht nicht.

Das zeigt wieder das Strg-C und Strg-V meist nicht zur Erhoehung der Codequalitaet beitraegt....  :wink:


----------



## quippy (27. Mrz 2008)

Gast hat gesagt.:
			
		

> auch auf die Gefahr hin mir den Zorn von diversen Personen abzubekommen. Aber wenn es darum geht "sauber" zu arbeiten sollte man auf static verzichten.



Das mit dieser Logik "static" per se nicht sauber ist, ist absoluter blödsinn.

Auch die Aussage


			
				Gast hat gesagt.:
			
		

> Also, wegen letztendlich 2 Sekunden Mehraufwand pro Klasse wird auf ein bei groesseren Systemen wichtiges Architekturprinzip verzichtet....


stimmt so nicht.

Selbst in Großprojekten sind statische Helper-Methoden mit eindeutigen Funktionen sinnvoll. Klar, daß ich die Implementierung nicht dynamisch austauschen kann, ist logisch - aber wenn man das will oder es zukünftig so sein könnte, darf man den static nicht verwenden. Zudem ist die statische Methode dann auch keine allgemeingültige Funktion mehr, wenn es bei unterschiedlichen Impls unterschiedliche Ergebnisse geben kann - damit gehört sie sowieso in ein Objekt und ist eine Instanzmethode.

Es wird z.B. niemand auf die Idee kommen, die Sinus-Funktion in Math auszutauschen. Das Ding berechnet einen Sinus - was sonst.

Eine Berechnungsmethode der folgenden Form

```
/*
 * Return the center x position on the screen coordinates for
 * an object of witdh oWidth
 */
public static int getCenterX(int screenMin, int screenMax, int oWidth)
{
   return (((screenMax - screenMin)>>1) - (oWidth>>1)) + screenMin;
}
```

ist ebenfalls so dermaßen allgemeingültig, daß sie so dastehen kann.

Wer OOP wirklich verstanden hat, kann die ganzen Designpattern-Bücher in einen wesentlich besseren Zusammenhang bringen und vor allem die Anwendungsgebiete klar erkennen. Keines dieser Pattern ist ein MUSS - aber sie helfen an den Stellen, für die sie gemacht wurden.


----------



## Verjigorm (27. Mrz 2008)

quippy hat gesagt.:
			
		

> Verjigorm hat gesagt.:
> 
> 
> 
> ...



wo steht denn, dass ich das JPanel übergebe??
Nur die Breite des Panels, mehr nich


----------



## byte (27. Mrz 2008)

SlaterB hat gesagt.:
			
		

> Operation anklicken, rechte Maustaste, Open Declaration,
> brauche ich zig mal am Tag


Machst du das echt so umständlich? Ich mache einfach STRG + Click. :roll:


> wenn man dann nur zum Interface kommt und die Klasse manuell suchen muss, werde ich immer fast wahnsinnig
> (Basisklase ginge natürlich auch)


Stimmt, da würde man wahnsinnig, wenns da nicht z.B. die Quick Type Hierarchy geben würde.  Also einfach STRG + T drücken und Implementierung auswählen. Schon ist man da wo man hin will.


----------



## SlaterB (27. Mrz 2008)

> einfach STRG + Click

ja, das wäre auch nicht schlecht,
kommt mir manchmal in die Quere bei 'Doppelklick zum Markieren + Strg-C zum Kopieren'

aber Rechtsklick, Linksklick ist auch schnell gemacht und braucht nur eine Hand, Gewöhnungssache sicherlich

> STRG + T drücken und Implementierung auswählen

das ist mir noch sehr ungewohnt

aber selbst wenn man das hat, ist es immer noch ein Schritt von direkter Sprung zu 'Subfenster, lesen, verstehen, zusätzlicher Klick zum Auswählen',
ziemlich bedeutend, finde ich, das kann man nicht klein rechnen

naja, wenn man nicht eh mehrere Implementierungen zur Auswahl hat,
dann fällt das Verstehen weg, dann muss man eh nur den einen Eintrag unter dem Interface auswählen,
das zeigt aber auch besonders deutlich, wie irrsinnig dieser zusätzliche unnötige Schritt im Gegensatz zum direkten Sprung ist


----------



## byte (27. Mrz 2008)

SlaterB hat gesagt.:
			
		

> > einfach STRG + Click
> 
> ja, das wäre auch nicht schlecht,
> kommt mir manchmal in die Quere bei 'Doppelklick zum Markieren + Strg-C zum Kopieren'
> ...


Naja, aber aus Bequemlichkeit auf einen bedeutenden Grundsatz der OOP zu verzichten (Programmierung nach Interfaces), ist auch nicht der Weisheit letzter Schluß.
Und selbst wenn es nur eine Implementierung des Interface gibt, fallen einem genug Gründe dafür ein, trotzdem auf dem Interface zu arbeiten...


----------



## SlaterB (27. Mrz 2008)

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

es macht keinen Sinn, ganz simpel,

um das Quadrat von 5 auszurechen darf man wirklich
int x = 5*5; rechnen,
und damit auf den bedeutendsten Grundsatz überhaupt, den Objekten selber, verzichten


wenn es in einer bestimmten Situation fachlich absolut egal ist, ob man statisch einsetzt oder nicht,
und das einzige Pro-Argument 'nicht-statisch ist aber schöner OOP' ist,
dann darf ja wohl das Contra-Argument 'schöner, aber macht einen Haufen Arbeit' genauso stehen bleiben 

edit:
'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..


----------



## Guest (27. Mrz 2008)

SlaterB hat gesagt.:
			
		

> > einfach STRG + Click
> 
> ja, das wäre auch nicht schlecht,
> kommt mir manchmal in die Quere bei 'Doppelklick zum Markieren + Strg-C zum Kopieren'
> ...



also ich mach das einfach mit F3


----------



## tfa (27. Mrz 2008)

SlaterB hat gesagt.:
			
		

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


Einverstanden  :toll: 



			
				byto hat gesagt.:
			
		

> 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 (27. Mrz 2008)

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 (27. Mrz 2008)

SlaterB hat gesagt.:
			
		

> '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
> ...


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 (27. Mrz 2008)

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 (27. Mrz 2008)

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 (27. Mrz 2008)

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 (27. Mrz 2008)

byto hat gesagt.:
			
		

> 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 (27. Mrz 2008)

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 (28. Mrz 2008)

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 (28. Mrz 2008)

maki hat gesagt.:
			
		

> ... 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 (28. Mrz 2008)

Hast Recht ms, 

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


----------



## ms (28. Mrz 2008)

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


----------

