Modules oder "fake" static Klasses?

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 4 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    Modules oder "fake" static Klasses?

    Guten Abend,

    bekanntlich ist dass static classes als solche in Vb.Net nicht existieren. Im Vb.Net sind dafür die Modulen da.

    Jetzt aber (und immer mehr) soll man sich OOP Practices angewohnen und das ist z.B keine Modulen mehr benutzen.

    Jetzt die Frage was würdet ihr empfehlen bzw. was macht ihr denn:
    • Trotzdem Module benutzen
    • "Fake static Klassen" erzeugen, mit NonInheritable und alle Methodes als Shared deklarieren?
    Leider kann man nicht das Instanzieren (AFAIK) verbieten, so dass man trotzdem eig. eine Instanz von dieser "static class" erzeugen kann und das ist auch unschön.

    Würde gerne hören was ihr mit euren Projekten macht.

    Gruß
    Life doesn't give you a datasheet. Sometimes the docs are wrong and you have to try it.

    Wir kommst du darauf das man Module nicht mehr benutzten soll? Für Erweiterungsmethoden sind die m.W.n. sogar zwingend erforderlich.

    Nachtrag: Im OOP Kontext sollte man die (Module/Statische Klassen) natürlich vermeiden, das heißt aber nicht das sie tabu sind.

    rgomez schrieb:

    keine Modulen mehr benutzen.

    Das denke ich nicht, C#/VB.Net sind keine reinen OOP Sprachen wie z.B. Smalltalk. Das siehst du auch am Beispiel von Math und etlichen anderen Framework-Klassen die statisch sind. Andres rum ist F# auch keine rein Funktionale Sprache. Ich finde so eine kleine Toleranz, bzw. Freiheit für den Programmiere eigentlich ganz gut. Sich an gewisse Pattern zu halten ist durchaus positiv, keine Frage, aber jedes Pattern hat seinen Anwendungsfall also brich dir nicht auf Teufel komm raus einen ab um OOP strikt durch zu ziehen, wenn es eigentlich gar nicht passt.

    Ok, d.h. ihr würdet Module anstatt fake statische Klassen benutzten, OK. Ich muss sagen, seit ich C# kenne, finde ich die Aussage keine Module mehr benutzen iwie sinnig, da eig. man kann wie schon erwähnt die Module durch NotInheritable Klassen mit Shared Methoden ersetzen. Aber im End-effekt man erreicht das selbe. Aber ja, habe mehrmals (z.B. in StackOverflow oder Blogs von Microsoft MVPs), dass man Modulen vermeiden sollte, die aber nicht verboten/tabu, denn ja VB.Net ist auch ne "alte" Sprache, wo das OOP Konzept noch nicht so verbreitet war.

    Jetzt dann ne andere Frage. Ich habe für jede Klasse egal wie klein sie ist, eine Datei. Wie macht ihr dann es mit Modulen? Auch das selbe?
    Und das Thema custom exceptions? Eine Datei für jede Exception? oder in den Modulen speichern? oder wie?
    Life doesn't give you a datasheet. Sometimes the docs are wrong and you have to try it.

    Code muss 1) funktionieren, 2) menschenlesbar sein, dann kommt erstmal ganz lange garnichts auf der Prioritätenliste...

    Und ich würde weder 1000 MiniDateien mit je nix drin noch 1 MonsterDatei mit 10000 LOC als "menschenfreundlich dimensioniert" betrachten.
    Also wenn (kleine) Inhalte inhaltlich zusammenpassen, ist das sehr menschenfreundlich, sie auch zusammenzustecken - unter einer sinnvollen Überschrift/Dateiname.

    Ebenso ists menschenfreundlich, sich ausdehnende Inhalte auf mehrere Dateien zu verteilen (vorzugsweise als eigene Klassen, aber nur wenn sinnvoll)
    Ich find so 50 - 300 Zeilen ein gutes Mass für eine Datei.

    Siehe auch dazu mein cp-Artikel: codeproject.com/Articles/11939…nnot-understand-this-code

Facebook
Telefonspende