Programmierstil und OOP

[Chase]

Ich habe nun mein erstes etwas komplexeres Programm fertig (zusammen ~2000 zeilen), mache mir aber grade Gedanken ueber den Programmierstil. Ich habe das Programm logisch in Klassen unterteilt, allerdings verwende ich ueberall nur statische variablen und/oder methoden - und alle klassen greifen munter auf den inhalt der restlichen zu. Daher frage ich mich, ob ein staendiges verwenden von "public static .." nicht irgendwie ein schlechter stil ist, oder ob es trotzdem sinnvoll ist, den code auf mehrere klassen aufzuteilen. (da ich immer static verwende, koennte ja auch einfach alles in eine datei)
Soll ich mich jetzt zwingen, Objekte zu erzeugen und diese als Parameter von Funktion zu Funktion weiterzureichen, nur um objektorientiert zu programmieren, oder ist das garnicht immer angebracht?
Und ueberhaupt: Wo liegt eigentlich der Vorteil eines solchen Programms ? Ich habe oft von "Wiederverwendbarkeit" gehoert, allerdings hab ich die auch so.
Eine Klasse 'Calculator' wandelt beispielsweise einen String mit den Grundrechenoperationen in ein ganzzahliges Ergebniss um. Schadet es jetzt irgendwie, dass die Klasse vollkommen statisch ist, und kein Objekt von ihr erzeugt werden muss ?
Ich hoffe mal ihr könnt ein wenig Senf dazu geben

 

[Bleiglanz]

sehr viel static ist iA schlecht

das sind ja dann reine Funktionsbibliotheken, ohne "Zustand"

Soll ich mich jetzt zwingen, Objekte zu erzeugen und diese als Parameter von Funktion zu Funktion weiterzureichen, nur um objektorientiert zu programmieren, oder ist das garnicht immer angebracht?

Nicht als Selbstzweck, das hat keinen Sinn

Guter Stil wärs aber, beachte jedoch dass du nicht alle "als Parameter" umherreichen musst, es gibt auch Membervariablen usw.

 

[Beni]

Du hast dir doch gerade Chuckys Rechner angeschaut Chase? Er hat es mit vielen Objekten gemacht, und zu deiner Frage:

Ich hab die gleiche Frage in nem eigenen Thread gestellt, aber warum muessen die Operatoren eigentlich muehevoll erzeugt werden, ein Interface impementieren und in ein Array gepackt werden ? Wie du sagtest, statisch waer das doch viel einfacher..

Jetzt überleg mal, wieviel Code Chucky ändern muss, wenn er noch eine Operation einführen möchte. Er muss eine Klasse schreiben, und ein Objekt in die Liste von Operationen schieben. Sehr trivial :wink:
Wenn er es mit static gemacht hätte... Methode schreiben, von Hand ein neuen Button machen, die Oberfläche von Hand anpassen um dem neuen Button Platz zu machen, die korrekten Listener beim Button registrieren, im Listener auf den neuen Button reagieren, und die neue Methode aufrufen.
Die Chance dabei einen Fehler zu machen... astronomisch.

Deshalb nennt man die erste Variante "wiederverwendbar", weil man mit wenig Code, relativ sicher neues Zeugs hinzufügen kann (oder auch alte Operationen löschen)-

 

[Chase]

Danke für die Antworten. Ich werd auf jeden Fall versuchen in Zukunft ofter Objekte zu erzeugen, nur manchmal kommt es mir unglaublich umstanedlich vor.
Als Beispiel hab ich die Klasse "Writer", die statt System.out.println("..") die Zeichen einzeln ausgibt (Tippeffekt)

 public class Writer
{
   private final static int PAUSE = 10;
   
   public static void say(String s)
   {
          String say = s + "\n";
          
           for(int i = 0; i < say.length();i++){
                 System.out.print(say.charAt(i));
                 try{Thread.sleep(PAUSE);}
                 catch(InterruptedException e) {};
                                                           };
   }
}

Wie sollte diese Klasse jetzt nicht-statisch sein, wenn sie denn von jedem Punkt des Programms aus verwendet werden können soll ?
Ich müsste irgendwo einen Writer haben, der dann an andere Klassen übergeben werden muss, um nicht jedesmal eine neue Instanz zu erzeugen, oder ?

 

[bygones]

OOP in allen Ehren, aber übertreiben muss man es nicht. Wenn die Klasse nur aus dieser einen Methode besteht würde ich mir Gedanken machen, ob sie nicht obsolet ist und du die Methode wo anders unterbekommst.

Klasse sollte man logisch unterteilen. D.h. man soltle sich überlegen, welche Aufgaben das Programm hat und welche Teilgebiete dabei anfallen. Danach überlegt man sich welche logisch bzw. funktionell zusammenhängen und erstellt dann daraus seine Klassen

 

[byte]

ich empfehle dir mal ein buch über objektorientiertes programmieren zu lesen. dein problem ist glaube ich, dass du deine beispiele zu "banal" sind (nicht wertend gemeint). sinn und zweck von klassen und objekten ist ja der, dass man gerne mal viele unterschiedliche instanzen ein und derselben klasse hat. in deinem beispiel mit der write-methode, macht static durchaus sinn, weil es einfach zustandslose funktionalität ist. wenn du aber z.b. mal komplexere sachen programmieren willst, dann wirst du probleme kriegen, wenn du alles statisch lösen willst.

daher mein tipp: lies ein ordentliches buch. da sind häufig mehr oder weniger sinnvolle beispiele drin, wie man mit objekten und klassen umgehen kann. ein beispiel: es gibt eine klasse auto, aber es kann viele unterschiedliche instanzen von autos geben, weil je nach auto die farbe oder die reifen oder das chassie (schreibt man das so? *g*) variieren kann.

 

[Chase]

Danke für den Tipp. Ich lese grade das recht bekannte Buch "Java ist auch eine Insel". Mir ist schon klar was Objekte für Vorteile mit sich bringen, aber scheinbar haben die Spielereien die ich bisher programmiert habe, weder mehere Instanzen noch Unterklassen,etc. verlangt.. ich hoffe mal das kommt mit der Zeit, das wichtigste ist wohl sich immer neue Aufgaben zu stellen.

 

[byte]

man wächst mit neuen aufgaben.

ein recht beliebtes beispiel an unis sind auch immer wieder verkettete listen. ich glaube, das wäre ein gutes beispiel, wo man statisch nicht wirklich weiterkommt.