C# Welche Variante ist besser?

[Gast]

Hallo zusammen :)

Ich habe hier zwei Varianten. Könnt ihr mir sagen, welche besser ist?

using System;
using System.Collections.Generic;
using System.Text;

namespace Klassen
{
class Program
{
static void Main(string[] args)
{
wert wert = M_Wert();

Console.WriteLine(wert.wert1);
Console.ReadKey();
}

private static wert M_Wert()
{
wert wert = new wert();
wert.verarbeitung();
return wert;
}

class wert
{
public string wert1;

public void verarbeitung()
{
wert1 = "Das ist ein Test";
}
}
}
}



using System;
using System.Collections.Generic;
using System.Text;

namespace Klassen
{
class Program
{
static void Main(string[] args)
{
wert wert = new wert();
wert.verarbeitung();

Console.WriteLine(wert.wert1);
Console.ReadKey();
}

class wert
{
public string wert1;

public void verarbeitung()
{
wert1 = "Das ist ein Test";
}
}
}
}


Vielen Dank

[rad05]

Der code macht ja das gleich also ist er eigentlich gleichwertig. Aber die statische Methode ist eigentlich überflüssig, wie ja das zweite Beispiel zeigt. Statische Methoden sollte man eigentlich vermeiden, wenn sie nicht notwendig sind. Besonders bei Verwendung mehrerer Threads können diese zu Problemen werden.
In deinem Fall gibt es aber eigentlich kein Besser. Du teilst ja im Prinzip den Code ja nur auf zwei statt einer statischen Methode auf.

[Monger]

Der code macht ja das gleich also ist er eigentlich gleichwertig.

Nä, also das Argument lasse ich nicht gelten! ;)
Es gibt wichtigeres als Funktionalität.


Statische Methoden sollte man eigentlich vermeiden, wenn sie nicht notwendig sind.

Kann man so pauschal nicht sagen. Static factories sind ein sehr nützliches Pattern.


Ist aber in dem Fall völlig unwesentlich. Code muss in erster Linie lesbar sein, in zweiter Hinsicht dann möglichst robust. Wie das dann konkret aussieht, muss man anhand eines realen Beispieles entscheiden, nicht anhand eines Gerippes.

[Gast]

Will heissen, dass wenn ich noch 3-5 Klassen mehr habe, könnte es sinnvoll sein, diese mit Methoden anzusprechen?

[rad05]

Nä, also das Argument lasse ich nicht gelten! ;)
Es gibt wichtigeres als Funktionalität.

Es gibt NICHTS wichtigeres als Funktionalität. Wenn etwas schön programmiert ist, aber nicht funktioniert dann hilft das nichts. Da ist es besser, wenn es nicht so schön programmiert ist, aber funktioniert. Natürlich ist gut programmiert und es funktioniert am Besten.


Kann man so pauschal nicht sagen. Static factories sind ein sehr nützliches Pattern.

Ich habe ja auch nicht pauschal gesagt, daß statische Methoden keinen Sinn machen. Man soll sie halt nur dort einsetzen, wo sie Sinn machen und sonst vermeiden. In deinem Beispiel machen sie ja Sinn, das habe ich ja nie behauptet.

[Monger]

Will heissen, dass wenn ich noch 3-5 Klassen mehr habe, könnte es sinnvoll sein, diese mit Methoden anzusprechen?

Soll heißen: wie eine Klasse optimalerweise aufgebaut sein sollte, hängt im wesentlichen davon ab, was denn genau diese Klasse tun soll.

In deinem Beispiel erzeugst du ja erst eine Instanz deiner Klasse, und führst dann eine Methode "Verarbeitung" aus. Ist das eine Methode, die zwingend notwendig ist um die Funktionsfähigkeit dieser Klasse zu garantieren? Wenn ja, sollte es nicht möglich sein, ein Objekt dieser Klasse zu erzeugen, ohne diese Methode auszuführen.

Erfüllt deine Methode "M_Wert" eine abgeschlossene Aufgabe, die vielleicht auch von woanders her aufgerufen werden können sollte? Dann hat sie definitiv ihre Existenzberechtigung, und sollte nicht in die Main integriert werden.

Wie gesagt: sowas kann man nur am konkreten Beispiel demonstrieren.

Es gibt NICHTS wichtigeres als Funktionalität. Wenn etwas schön programmiert ist, aber nicht funktioniert dann hilft das nichts. Da ist es besser, wenn es nicht so schön programmiert ist, aber funktioniert.
Naja, darüber kann man streiten. Eine Methode die zwar irgendwas tut, aber nicht das was der Anwender erwartet, ist irgendwo zwischen nutzlos und gefährlich.
Und: Implementierungsdetails kann man jederzeit verbessern. Die Änderung einer Klassenstruktur ist aber - wenn sie erstmal im Gebrauch ist - nahezu unmöglich.

[rad05]

Naja, darüber kann man streiten. Eine Methode die zwar irgendwas tut, aber nicht das was der Anwender erwartet, ist irgendwo zwischen nutzlos und gefährlich.
Und: Implementierungsdetails kann man jederzeit verbessern. Die Änderung einer Klassenstruktur ist aber - wenn sie erstmal im Gebrauch ist - nahezu unmöglich.

Funktionalität=Die Methode tut genau das, was sie tun soll. Eine Methode, die nicht tut was der Anwender erwartet hat in der Funktionalität versagt.
Keine Ahnung wie du Funktionalität definierst, anscheinend anders.

[Monger]

Was der Anwender erwartet, hängt maßgeblich von der gewählten Struktur ab. Was anderes ist ja von außen auch gar nicht erkennbar.
Machen wir mal ein konkretes Beispiel. (ist zugegebenermaßen arg konstruiert, aber mir fällt grad nix besseres ein) :)
Nehmen wir mal an, ich möchte eine Funktion haben, die mir die aktuelle Zeit als String zurückgibt.
Eine sauschlechte Umsetzung wäre z.B. sowas:


public class TimeOperations{

public String timeNow;

public void initialize(){
timeNow = Date.Now().ToString();
}

}

// Verwendung:
TimeOperations op = new TimeOperations();
op.initialize();
String currentTime = op.timeNow;

Syntaktisch völlig richtig, tut sogar genau was es soll, aber ausgesprochen fehleranfällig. Der Anwender könnte vergessen, initialize vorher aufzurufen, und würde dementsprechend eine Exception um die Ohren gehagelt bekommen. Er könnte zwischen initialize und getCurrentTime noch anderen Code ausführen, und damit eine völlig andere Zeit herausbekommen. Wozu überhaupt initialize da ist, lässt sich vom Benutzer her auch nicht erschließen. Deutlich besser wäre sowas:


public class TimeOperations{

private TimeOperations(){}

public static String getCurrentTime(){
return Date.Now.ToString();
}

}

Zum einen beseitigen wir den Instanzbezug. Für so etwas gibt es keinen Grund, einen Instanzbezug zu erzwingen. Zum anderen verhindern wir, dass die Klasse instanziiert werden kann. So wird klar, dass diese Klasse nur als Toolbox für Hilfsmethoden dient.

Ist jetzt nur ein Beispiel, aber die erste Variante kann einem möglicherweise höllische Kopfschmerzen bereiten, wenn man leichtsinnigerweise sowas zur allgemeinen Verwendung freigegeben hat. So schwere Kopfschmerzen, dass es besser gewesen wäre wenn man es nie geschrieben hätte.

[Gast]

Ist jetzt nur ein Beispiel, aber die erste Variante kann einem möglicherweise höllische Kopfschmerzen bereiten, wenn man leichtsinnigerweise sowas zur allgemeinen Verwendung freigegeben hat. So schwere Kopfschmerzen, dass es besser gewesen wäre wenn man es nie geschrieben hätte.

Das ist so pauschalisiert ziemlicher Unsinn. Denn im Vergl. zu deiner Helferklasse kann es ja absolut gewollt sein, dass man Instanzen mit einem Datumswert speichern möchte. Deine statische Methode liefert immer nur das aktuelle Datum.

[Monger]

Das ist so pauschalisiert ziemlicher Unsinn. Denn im Vergl. zu deiner Helferklasse kann es ja absolut gewollt sein, dass man Instanzen mit einem Datumswert speichern möchte. Deine statische Methode liefert immer nur das aktuelle Datum.
Das passt aber nicht so recht dazu, dass die Variable "timeNow" heißt.

Natürlich wird es in so einem Fall Anwender geben, die genau dieses (Fehl-)Verhalten nutzen. Wenn du dann einen Fehler ausbügeln willst, musst du dich entscheiden ob du die Abwärtskompatibilität brechen willst, oder beim alten Schrott bleibst. Keine leichte Entscheidung.

[Gast]

Das passt aber nicht so recht dazu, dass die Variable "timeNow" heißt.


Das ist ja auch dein Beispiel gewesen, nicht das des Threaderstellers. Es hängt eben vom Anwendungsfall ab, ob man denn Instanzen benötigt oder nicht.

[Bietchiebatchie]

Hallo zusammen :)
Ich habe hier zwei Varianten. Könnt ihr mir sagen, welche besser ist? ...

Eigentlich ziemlich egal - die statische Methode ist allerdings recht unnötig - denn du machst genau eine Aktion darin. Eine Methode aufzurufen, die genau eine andere Methode aufruft, macht eher selten Sinn.

Desweiteren würde ich mich schon direkt am Anfang an die .Net Konventionen halten: in deinem Fall Klassen groß schreiben und Methoden einen sinnvollen Namen geben (M_Wert is relativ nichtssagend).

@Monger: Du kannst dir den privaten Konstruktor sparen und einfach ein static vor die Klasse setzen ;)

[Gast]

@Monger: Du kannst dir den privaten Konstruktor sparen und einfach ein static vor die Klasse setzen ;)

Eine static Klasse darf auch nur statische Methoden enthalten.
Bei einem privaten Konstruktor ist das keine Vorrausetzung.