Konstruktor mit Parameter

  • Allgemein

Es gibt 12 Antworten in diesem Thema. Der letzte Beitrag () ist von mrMo.

    Konstruktor mit Parameter

    Guten Tag,

    ich hätte hier einmal euere Meinung gewusst.

    Ich selbst habe einige Klassen codiert, wo ich im Kontruktor Parameter übergeben und im Konstruktor Variablen setze und ebenfalls andere Klasse instanziere, wo ich diese Parameter z.B. benötige.
    Nun hatte ich eine Disskusion mit einem anderen Entwickler, der meinte, dass im Konstruktor keine Parameter und keine weiteren Instanzierungen etwas zu suchen habe, sondern nur . z.B. InitializeComponents (Form) etc.
    Über eine eigene Methode sollten dann die anderen internen Klassen instanziert werden.

    Mir selbst ist diese Methode nicht bzw. nur in bestimmten Fällen bekannt und hatte auch kein wirkliches Gegenargument. Weil im Prinzip ja beides möglich ist. Nun wollte ich euch fragen, wie ihr das macht bzw. liege ich da wirklich falsch?

    Danke für eure Antworten
    Gerhard

    Willkommen im Forum.

    Wenn eine Klasse ohne korrekte Initialwerte keinen Sinn ergibt, ist ein parameterbehafteter Konstruktor Pflicht. Da etwas zu machen wie

    VB.NET-Quellcode

    1. Dim Foo As New Foo
    2. Foo.InitializeWith(Bar, Baz, Buzz)
    wenn InitializeWith zwangsläufig aufgerufen werden muss, da Foo sonst sinnlos ist, ist insofern gefährlich, weil man es vergessen könnte einzufügen. Oder man es an der falschen Stelle platzieren könnte. Ein (kleiner) Vorteil beim Konstruktor ist ja auch, dass man ReadOnly-Members belegen kann. Das geht mit der o.g. Variante nicht mehr. Kommt natürlich auf die Situation drauf an. Im Form-Konstruktor selber arbeite ich nur an einer Stelle: Um sauberer zu arbeiten.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Danke für die rasche Antwort. Also, wenn ich es jetzt richtig verstanden habe, liege ich mit meiner Codierung richtig. Wenn ich Parameter zum Zeitpunkt der Instanzbildung noch nicht weiß, dann mache ich es später mit Properties. So habe ich es zumindest gelernt.

    Aber dieser Entwickler behauptet ja auch, dass von Formen keine Instanzen gebildet werden müssen, weil diese automatische gemacht werden. Er ruft alle Formen mit Form.Show auf, also ohne eigene Instanzen. Da hatte ich auch schon einige Diskussionen geführt.

    Was solls, ich danke jedenfalls...

    GerhardW schrieb:

    Aber dieser Entwickler behauptet ja auch, dass von Formen keine Instanzen gebildet werden müssen, weil diese automatische gemacht werden. Er ruft alle Formen mit Form.Show auf, also ohne eigene Instanzen.
    :D Genauso, wie man es nicht machen sollte. Die Gründe stehen auch in dem in Post#2 von mir verlinkten Thread alias Warum »Form1.Show« und Co. einem irgendwann ins Bein schießen
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    GerhardW schrieb:

    Aber dieser Entwickler behauptet ja auch, dass von Formen keine Instanzen gebildet werden müssen, weil diese automatische gemacht werden. Er ruft alle Formen mit Form.Show auf, also ohne eigene Instanzen.
    Für mich sagt das genügend über des Kollegen Kompetenz aus.

    Und: So einen Kollegen hatte ich auch mal. Das war eine sehr schwierige Situation, zumal er dienstälter.



    Übrigens: Speziell bei Forms muss man allerdings einen parameterlosen Konstruktor bereitstellen. Sonst kann der Designer das Form nicht anzeigen.
    Also wenn man einen Form-Konstruktor mit Parametern ausstattet, braucht man eine zusätzliche ctor-Überladung ohne Parameter.

    Willkommen im Forum. :thumbup:
    Beliebtestes Zitat:

    GerhardW schrieb:

    Aber dieser Entwickler behauptet ja auch, dass von Formen keine Instanzen gebildet werden müssen, weil diese automatische gemacht werden.
    Dieser Entwickler denkt wahrscheinlich auch, dass gleichzeitig nur eine Instanz einer Form offen sein kann.
    Mit solch "Beton-Köpfen" kann man leider nicht vernünftig reden.
    Seid Ihr eine Firma?
    Habt Ihr Codierungs-Regeln?
    Wenn ja, dann musst Du Dich dran halten.
    Sind die .NET-konform?
    Falls nein, kannst Du da vielleicht einen Vorstoß machen.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    GerhardW schrieb:

    Aber dieser Entwickler behauptet ja auch, dass von Formen keine Instanzen gebildet werden müssen
    Aufgewachsen mit VB6 und sich nie wirklich mit VB.Net befasst.
    Dazu passt auch der parameterlose Konstruktor.
    In VB6 ging als Konstruktor nur Class_Initialize().
    Und der konnte keine Parameter.

    Wir sind aber inzwischen ein Vierteljahrhundert älter und die Zeit ist nicht stehen geblieben.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    Ich danke euch für eure Antworten und fühle mich bestätigt. Habe schon an mir und meinen Codiererfahrungen gezweifelt. Das Problerm ist, dass das bestenden Projekt auf OOP geändert werden soll. Diese Anregung kam von mir. Es wurde im bestehenden Code ausschließlich mit Public Variablen (Modul) gearbeitet, welche dann irgnedwo im Programmcode verändert wurden. Sprich zum Lesen des Codes ein Horror. Dann wurden sehr viele klassische zweidimensionale Array verwendet, wo jeder Eintrag eigentlich eine Eigenschaft eines Objektes darstellt. Nachdem ja keine Instanzen von Formen gebildet wurden, konnten auch nicht wirklich Parameter weitergereicht werden. Usw.

    Jetzt ist es so, dass der Chef mir vertraut und wir es umbauen. Aber ich muss mich halt immer wieder rechtfertigen, warum ich eine Instanz bilde, warum ich mit Events arbeite und nicht direkt auf die Controls zwischen den Formen zugreife usw. Die letzte Diskussion führte uns zu der GC. Ich habe gesagt, dass ich bei meinen Klassen immer ein IDisposibel einbaue und wenn ich die Instanz nicht mehr benötige diese dispose. Er meinte ist nicht notwendig, macht eh die GC. Da hat er eigentlich ja nicht unrecht, aber ich habe es mir so gelernt und helfe der GC ja nur.

    Aber es wird schon, ich bin guter Dinge. Und wie ich sehen, bin ich hier gut aufgehoben ;)

    GerhardW schrieb:

    Da hat er eigentlich ja nicht unrecht, aber ich habe es mir so gelernt und helfe der GC ja nur.
    Nö - du störst ihn eher.
    Verwende IDisposable nur, wenns net anders geht. Es gibt ganz klare Richtlinien, wann es erforderlich ist.
    In allen anderen Fällen lass den GC seine Arbeit tun.

    Überflüssiges IDisposabel erzeugt nur unnötige Komplexität. Weil das muss ja auch bedient werden - kannst ein disposables Objekt ja nicht einfach undisposed lassen. Und dann wirds vergessen, und dann wird nachgeguckt, was da eigentlich passiert, und dann passiert da gar nichts, und dann wird nachgefragt, was da denn passieren sollte, ob da was abhanden gekommen ist, und und und....

    GerhardW schrieb:

    dass das bestenden Projekt auf OOP geändert werden soll.
    Da steht doch die Antwort.
    Nur: Umstricken kannst Du / könnt Ihr das alte Projekt nicht, Ihr müsse es neu implementieren.
    Sicher kann da Mathematik und Co übernommen werden, aber alles,, was GUI ist, wird völlig neu.
    Das müssen Deine Leute verstehen.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    @GerhardW Was du so erzählst lässt an der Kompetenz deines Kollegen zweifeln. Vermutlich nen „alter VB6ler“ der noch nicht in .Net und OOP angekommen ist. Lass dich nicht beirren, du bist auf dem richtigen Weg.
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen

Facebook
Telefonspende