Compilerfehler CS0120 Für das nicht statische Feld, die Methode oder Eigenschaft ist in Objektverweis erforderlich



  • Knoten geplatzt.

    Kurze Erläuterung: ich komme von C, mein Motiv ist die grafische Windows-Oberfläche. Wenn das nicht wäre, man kann auf der Konsole alles auch in C programmieren. Aber eben nur auf der Konsole, und die Optik ... ist definitiv nicht mehr zeitgemäß.

    Daher beschäftige ich mich jetzt einige Wochen mit C# und diese Fehlermeldung hat mich fast zum Wahnsinn getrieben, weil ich sie im Internet nirgendwo verständlich erklärt gefunden habe.

    Gestern ist der Knoten geplatzt. Ich möchte dazu mal einen Beitrag einstellen für solche Beginner, denen es vielleicht hilft. Anstelle von komplizierten Code-Beispielen soll das hier mal wirklich klar und kurz erklärt werden.

    Das Problem vom Umstieg aus einer prozeduralen Sprache (C) auf eine OOP (C#) ist die Kapselung der Daten und wie sie angesprochen werden.

    Prozedural:

    int function1

    int function2

    int function3

    main {
    int i,j,k;
    i= funct1

    j=funct2

    k=funct3

    }

    So ist man das gewohnt. Eine Funktion kann irgendwo in dem Programmcode verteilt stehen und von überall mit ihrem Namen aufgerufen werden. In Ansi C empfiehlt es sich, zwecks Übersicht die Funktionen in Header-Dateien zu sortieren und einzubinden, damit die Main-Routine übersichtlich bleibt. Die Header-Dateien werden mit #include.xxx.h hierarchisch gestaffelt und man hat eine schöne Übersicht und Struktur.

    Alles das geht in C# überhaupt nicht.

    Jeder Zugriff auf diese Funktionen führt zu der besagten Fehlermeldung.

    Warum?

    Nun es ist das Paradigma OOP, daß die Daten gekapselt werden. Und die spätmöglichste Bindung erfolgen soll. Der Kreuz- und Quer-Zugriff soll unterbunden werden, und die Funktionen sollen als Eigenschaften der Klassen aufgerufen werden.

    Der Zugriff wird sogar verweigert, ohne Objektinstanz, wenn die Funktionen in derselben Klasse gelistet sind.

    Was hab ich mir darüber den Kopf zerbrochen.

    Nun also, ein Lösungsweg:

    Wir haben (Konsole) eine Klasse

    main{}

    Und natürlich wollen wir da nicht hintereinander unsere Funktionen reinschreiben, um das ganze sauber zu halten.

    Wir erklären für alle Funktionen eine Klasse class myfunc und schreiben dort alles rein an Funktionen. Z.B. erstmal eine Klasse myDateiFunc.

    main {}

    class myDateiFunc
    {

    public bool datei_neu(string filename){}
    public bool datensatz_anhängen(string filename){]
    public string[] datei_lesen(string filename){]

    }

    Die Main-Funktion ist jetzt sauber, die ganzen Funktionen sind in die Klasse myDateiFunc ausgegliedert.

    Wir rufen wir sie nun auf? If (datei_neu) ... usf, käme sofort die Fehlermeldung.

    Sie sind ja Methoden/Eigenschaften einer anderen Klasse, man kann sie nicht wie in c gewohnt einfach aufrufen. Und auch nicht als Methoden der eigenen Klasse.

    Jetzt kommt der Knoten, der mir gestern im Kopf geplatzt ist, seitdem ist das Problem gelöst:

    Wir erstellen diesen besagten Objektverweis.

    Wie erstellt man einen Objektverweis? Hier:

    myDateiFunc myDateiHandle;

    Das ist der Objektverweis. Der ist allerdings noch nicht aktiviert, noch nicht "scharf geschaltet". Das ist exakt so, als würde man in C einen Zeiger definieren, der aber dann noch auf null zeigt.

    Um die Sache mit Leben zu erwecken, muß Speicherplatz angefordert werden:

    myDateiFunc myDateiHandle = new myDateiFunc();

    Jetzt steht der Zeiger auf dem Anfangsbereich des Speicherplatzes der Klasse. Und der Speicherplatz ist zugewiesen.

    Und damit verschwindet der Compilerfehler CS0120 für immer (forever).

    Denn nun können wir, genau wie das Paradigma der OOP Sprache C# fordert, die ganzen Funktionen zwar immer noch nicht direkt aufrufen (niemals, never), aber als Eigenschaften der Klasse, nämlich mit dem Punkt-Operator, wobei uns IntelliSense mächtig behilflich ist:

    myDateiHandle.funktion

    konkret, aus dem obigen Beispiel:

    string filename =@"d:\Irgendeine_Datei";
    string buffer ="";
    string[]dateiinhalt;

    if (myDateiHandle.datei_neu(filename)
    if myDateiHandle.datensatz_anhängen(filename, buffer);
    dateiinhalt=myDateiHandle.datei_lesen(filename);

    Das war der ganze Knoten.

    Ist jetzt fast schon wieder wie prozedural 😃 (o.k., unpassende Bemerkung)

    Wenn man genau dieselbe Strukturierung in der WindowsForm implementiert, ist der Aufruf etwas anders, nämlich an die Ereignisse der Click - oder sonstigen Events gebunden. Es wird da aber fast noch einfacher, weil der aufrufende Code als leeres Gerüst immer an die passende Stelle gesetzt wird und man nur noch die Details der Programmierung eintragen muß.

    Meiner ersten Einschätzung nach dürfte man mit C# WindowsForms bei der Erstellung eines interaktiven Anwenderprogramms mit Eingabemasken etc. im Vergleich zur Konsolenprogrammierung um mindestens 50 Prozent schneller zum Ziel kommen. Sofern man diese "Besonderheiten" wie beschrieben von C# im Griff hat.

    Pascal



  • Soll das ein Witz sein? Das ist kein "Knoten" der platzen muss, sowas liest man in den ersten Kapiteln jedes C#-Buches nach. Dein Beitrag ist fürchterlich formatiert, enthält fehlerhaften Pseudocode statt C# und klärt eine Trivialität auf. Desweiteren bist Du auf dem völlig falschen Weg, wenn Du möglichst prozedural in C# programmieren willst.

    pascal2009 schrieb:

    Sofern man diese "Besonderheiten" wie beschrieben von C# im Griff hat.

    Und bitte keine Tutorials schreiben, wenn man eben diese Besonderheiten nicht im Griff hat.



  • µ schrieb:

    Soll das ein Witz sein? Das ist kein "Knoten" der platzen muss, sowas liest man in den ersten Kapiteln jedes C#-Buches nach. Dein Beitrag ist fürchterlich formatiert, enthält fehlerhaften Pseudocode statt C# und klärt eine Trivialität auf. Desweiteren bist Du auf dem völlig falschen Weg, wenn Du möglichst prozedural in C# programmieren willst.

    pascal2009 schrieb:

    Sofern man diese "Besonderheiten" wie beschrieben von C# im Griff hat.

    Und bitte keine Tutorials schreiben, wenn man eben diese Besonderheiten nicht im Griff hat.

    Du bist ein Stinkstiefel, der hier schon zum 2. Mal bei meinen Beiträgen (insgesamt 2) nur abkotzt.

    Freundin abgehauen?

    Daß ich in C# prozedural programmieren will, entstammt deinen Wahnvorstellungen. Jedenfalls dem Beitrag ist das nicht zu entnehmen.

    Der Pseudocode ist Absicht, ist nicht fehlerhaft sondern abstrakt.

    Es ist eine Falschbehauptung, daß das Thema dieses Beitrags in C# Büchern schon in den Anfangskapiteln behandelt wird. Ich behaupte, es wird nirgendwo klar erklärt.

    Vielleicht kannst du ja durch einen Literaturverweis diesen Nachweis für deine Behauptung antreten.

    Ansonsten verschone mich mit deinen Beiträgen.

    Pascal



  • pascal2009 schrieb:

    Der Pseudocode ist Absicht, ist nicht fehlerhaft sondern abstrakt.

    Er ist nichtmal als Pseudocode syntaktisch konsistent.

    pascal2009 schrieb:

    Es ist eine Falschbehauptung, daß das Thema dieses Beitrags in C# Büchern schon in den Anfangskapiteln behandelt wird. Ich behaupte, es wird nirgendwo klar erklärt.

    Vielleicht kannst du ja durch einen Literaturverweis diesen Nachweis für deine Behauptung antreten.

    Siehe Bücherthread.
    Oder jedes beliebige andere Buch zum Thema C#-Grundlagen. Nach mehreren Wochen hast Du gestern erst rausgefunden, wie man ein Objekt anlegt und damit nicht-statische Methoden aufruft. Willst Du ernsthaft behaupten, das wäre tiefes Wissen und nicht eine totale Trivialität der C# Programmierung? Da Du im Internet, Deiner Aussage nach, keine Antwort gefunden hast, gehe ich davon aus, dass Du noch garkein Buch hast und nur über Tutorials gestolpert bist, die in der Qualitätsliga Deines Eigenen spielen. Nun, merkst Du was?

    pascal2009 schrieb:

    Du bist ein Stinkstiefel, der hier schon zum 2. Mal bei meinen Beiträgen (insgesamt 2) nur abkotzt.
    [...]
    Ansonsten verschone mich mit deinen Beiträgen.

    Gewöhne Dich einfach an Kritik. Ich werde nicht damit aufhören, wenn weiterhin schlechte oder falsche Beiträge gepostet werden.

    Meiner Freundin geht's übrigens prima und mir auch, danke der Nachfrage 🕶


  • Administrator

    @pascal2009,
    Zügle dich bitte in deinem Ton. Was du hier bisher geschrieben hast, zeigt auf, dass du sehr wenig Ahnung von C# oder OOP hast. Die Kritik von μ mag ein wenig direkt und nicht mit Rosen bestickt sein, aber im Grunde ist sie richtig.

    Dein Beitrag hier ist bereits im ersten Satz äusserst fraglich. Und stellt daher sogar deine Kenntnis in C in Frage. Mit C kann man problemlos auch graphische Benutzeroberflächen unter Windows programmieren. Ich verweise dich hier mal in die Abteilung der WinAPI. Es gibt auch Frameworks, welche einem da weiterhelfen und die WinAPI zusätzlich kapseln.

    Zum Rest kann ich nur sagen, dass du typische Anfängerfehler machst, wenn jemand von einer prozeduralen Programmiersprache umsteigt. Es zeigt eigentlich klar auf, dass du Objektorientierung noch nicht mal im Ansatz richtig verstanden hast. Du probierst derzeit deine prozedurale Denkweise auf die objektorientierte zu zwängen. Damit wirst du nur in Probleme kommen. μ schreibt daher ganz korrekt, dass du eigentlich weiterhin prozedural programmieren willst. Du musst hier unbedingt in deinen Gedanken eine klare Trennung machen, sonst kommst du in die Teufelsküche. Es gibt nicht 1:1 Übersetzungen von prozedural zu objektorientiert und wieder zurück. Probleme werden komplett anders angegangen.

    Viele C# Anfängerbücher gehen eigentlich auf die Grundlagen der objektorientierten Programmierung ein. Es gibt aber auch einige C# Anfängerbücher, welche auf C++ Programmierer ausgerichtet sind und daher die Objektorientierung nicht behandeln. Wenn du tatsächlich ein Buch hast, was ich allerdings etwas bezweifle, dann hast vielleicht da ein falsche aufgegriffen.

    Ansonsten kann man auch sowas empfehlen:
    Objektorientierte Programmierung für Dummies | ISBN: 9783826629846

    Ich fand damals das Buch noch ganz gut. Ist etwas kurz und knapp gehalten, aber kann durchaus ein sinnvoller Einstieg in die Welt der Objektorientierung darstellen.

    Grüssli



  • @pascal2009
    Die Antworten auf deine Beiträge sind stinkig, weil deine Beiträge stinken. µ war da eigentlich noch recht freundlich.


Log in to reply