C# mit Klassen arbeiten.

[Rene K. (xdraconix)]

Ich habe ein Programm, welches nun mehr immer größer und größer wird - 
nun wollte und würde ich dies gerne in mehrere Dateien aufteilen. So wie 
dies in C mit .h Dateien war geht es ja nun leider nicht. Man muß ja mit 
Namespaces und Klassen arbeiten. Nun zu meinem Problem - ich gebe mal 
folgenden Code:

// Die Hauptdatei:

namespace MeinNamespace
{

   public partial class Form1 : Form
   {
       public pCarsClass pCarsData = new pCarsClass;

       private void Funktionen
       {
       }  
    }
}


// Nun die Nebendatei:

namespace MeinNamespace
{
   class CarData
   {
       public void CarFunktion
       {
            // Hier bräuchte ich Zugriff auf pCarsData
       }  
    }
}

Ja wie oben schon steht, wie kann ich da Klassenübergreifend auf die 
Variablen zugreifen?! Wie stelle ich das am dümmsten an?!

[Peter II (Gast)]

Rene K. schrieb:
> Ja wie oben schon steht, wie kann ich da Klassenübergreifend auf die
> Variablen zugreifen?! Wie stelle ich das am dümmsten an?!

gar nicht, man greift nicht auf Membervariablen von anderen Objekten zu.

Wenn CarData das objekt pCarsData  braucht, dann musst du es ihm z.b. im 
Kontruktur mitgeben.

[Rene K. (xdraconix)]

Kann ich denn keine Variable in einem Namespace Global vergeben?! Denn 
wenn ich mehrere brauche, dann kann ich es ihm doch nicht allen als 
Konstruktor mit übergeben?!

[Joey5337 (Gast)]

mehrere Möglichkeiten:

1. dein Programm hat ja irgendwie eine Main-Klasse. Da kann man das 
gemeinsam benutzte Zeug als member-Variablen speichern und den Objekten, 
die das brauchen geben, z.B. als Konstruktorparameter

2. Es gibt statische Member-Variablen. Da kann man global einmaliges 
Zeug hintun. Geschmacksache ist, ob die deiner main-Klasse gehören oder 
ob es eine Holder-Klasse für sowas gibt oder ob das über den Code 
verteilt wird. Alles nicht so besonders fein!

3. Es gibt auch private static member. Wenn du von irgendeiner Klasse 
ein Singleton brauchst kannst du in der Klasse eine statische 
Factory-Methode bauen, die dir dann das (eine, globale) Objekt liefert 
und ggf. vorher instanziiert.

[Joey5337 (Gast)]

Rene K. schrieb:
> Denn
> wenn ich mehrere brauche, dann kann ich es ihm doch nicht allen als
> Konstruktor mit übergeben?!

Wenn du mehrere hast werden die ja vermutlich zusammengehören, gehören 
also in eine Klasse.

Wenn du ein Formular zum bearbeiten eines Adressdatensatzes hast bekommt 
das als Parameter nicht Name, Straße Hausnummer, PLZ und Ort, sondern 
eine Instanz der Klasse "Adresse".

Das Formular kann dann die Eigenschaften des einen Adressobjekts 
bearbeiten.

Speichern macht dann das Adressobjekt selber, oder ein passender 
Dienstleister, dem man das Objekt gibt. Nicht das Formular!

Don't mess with others privates.

[Rene K. (xdraconix)]

Warum muss das bei C# so kompliziert und umständlich sein. Aber gut, ich 
schau mir das alles mal an, komme ja so oder so irgendwann nicht 
darumherum.

Danke euch...

[Martin S. (sirnails)]

Was heißt kompliziert?

Partial Class bedeutet - wie der Name sagt - partiell. Die Klasse darf 
also geteilt werden. Es darf n mal die gleiche partielle klasse im 
Projekt geben.

Pack also deinen Code in der klasse in exakt die gleiche Form Partial 
Class und du kannst auf alle privaten Methoden zugreifen.

[Peter II (Gast)]

Rene K. schrieb:
> Warum muss das bei C# so kompliziert und umständlich sein. Aber gut, ich
> schau mir das alles mal an, komme ja so oder so irgendwann nicht

das hat nichts mit C# zu tun. Das ist bei Java und C++ genauso. Auch 
globale Variablen sind dort böse.

Wenn du ein Zentrales-Objekt brauchst, dann suche mal nach Singelton.

Martin S. schrieb:
> Pack also deinen Code in der klasse in exakt die gleiche Form Partial
> Class und du kannst auf alle privaten Methoden zugreifen.

er hat aber eine neue Klasse und in diese darf er auch nicht auf Members 
von anderen Objekten zugreifen.


@Rene Krüger
du solltest dir mal einige Beispiele von C# anschauen, dort wirst du 
keine globalen Objekte finden - weil man sie gar nicht braucht. Wenn du 
denkst das du sie brauchst, ist dein Denkansatz falsch.

[Kaldwauz (Gast)]

Rene K. schrieb:
> Ich habe ein Programm, welches nun mehr immer größer und größer wird -
> nun wollte und würde ich dies gerne in mehrere Dateien aufteilen.

Dann wirst du die Struktur des Programms vermutlich neu durchdenken 
müssen. Die Aufteilung in Dateien ist eher ein Nebeneffekt; der 
Kernpunkt ist die Festlegung der Aufgaben der Klassen und die 
Zusammenarbeit der Objekte.

Vielleicht hast du in C völlig hemmungslos globale Variablen 
verwendet, dann ist der Kulturschock natürlich noch etwas größer ... ;-)

Vielleicht hilft dir das hier, dich in die objektorientierte 
Programmierung reinzudenken:
http://openbook.rheinwerk-verlag.de/oop/

[Martin S. (sirnails)]

Peter II schrieb:
> Rene K. schrieb:
>> Warum muss das bei C# so kompliziert und umständlich sein. Aber gut, ich
>> schau mir das alles mal an, komme ja so oder so irgendwann nicht
>
> das hat nichts mit C# zu tun. Das ist bei Java und C++ genauso. Auch
> globale Variablen sind dort böse.
>
> Wenn du ein Zentrales-Objekt brauchst, dann suche mal nach Singelton.
>
> Martin S. schrieb:
>> Pack also deinen Code in der klasse in exakt die gleiche Form Partial
>> Class und du kannst auf alle privaten Methoden zugreifen.
>
> er hat aber eine neue Klasse und in diese darf er auch nicht auf Members
> von anderen Objekten zugreifen.

Eine partielle Klasse ist KEINE NEUE Klasse!

[Peter II (Gast)]

Martin S. schrieb:
> Eine partielle Klasse ist KEINE NEUE Klasse!

ist sind aber 2 Klasse

public partial class Form1

class CarData

[Thorsten (Gast)]

Ich muss auch sagen, dass das Thema irgendwie recht schwierig für mich 
ist.
In meinem Lernbuch 
"http://www.amazon.de/Visual-2015-Grundlagen-Profiwissen-Rezepte/dp/3446443819"; 
hat der Autor die Beispiele hier zur Verfügung gestellt 
www.doko-buch.de/ . In einem Beispiel zur Asyncronenprogrammierung wurde 
eine Klasse mit statischen Werten als Globale benutzt und das Updaten 
der UI erfolgt über den UI Scheduler, persönlich gefiehl mir das sehr 
gut, ob es wirklich die Profiart ist weiss ich nicht, trotzdem komme ich 
auch desöfteren ins schwanken bei Datenaustausch zwischen den Klassen, 
insbesondere, wenn ich auch noch Events zur Verfügung stellen muss. 
Wirklich gute Beispiele finde ich zu diesen Thema nicht. Freien 
Sourcecode findet man natürlich, aber unkommentierten oder nicht 
dargestellten Programmablauf zuverstehen ist nie einfach.

[Rene K. (xdraconix)]

Also ich habe ja nun, euren Ratschlägen sei dank, mich das ganze 
Wochenende über mit dem Thema Klassen beschäftigt.

So weit, das ich Events auslöse (z.b. wenn sich der Wert einer Variable 
ändert) oder mit Asynchroner Ausführung, bin ich noch nicht 
vorgedrungen.

Ich habe erstmal Versucht den Sinn hinter den Klassen zu finden, und 
muss nun eingestehen das dies eine feine Sache ist. Selbst für meine 
"kleinen" Bedürfnisse. Die Idee dahinter, das alles zu instanzieren, ist 
gar nicht verkehrt.

Ich habe damals, vor über zwanzig Jahren, angefangen mit Basic über 
Pascal zu ASM und hin zu C zu arbeiten. Und da ist es halt nunmal so, 
das dieses alles ein statischer Programmablauf ist. Und das ist halt 
verdammt schwierig diesen Ablauf aus dem Kopf zu bekommen und einen 
Zugang zu einer OO Programmiersprache zu bekommen. Da stellt sich halt 
sehr oft der Kopf einfach in die Quere.

[Martin S. (sirnails)]

Rene K. schrieb:
> So weit, das ich Events auslöse (z.b. wenn sich der Wert einer Variable
> ändert) oder mit Asynchroner Ausführung, bin ich noch nicht
> vorgedrungen.

Es ist zugegeben schwer, bei der Fülle von neuen Sprachelementen einen 
Einstieg zu finden. Ich selbst programmiere C# erst seit ein paar 
Monaten in .NET. Aber irgendwann stolpert man zwangsläufig über 
Delegaten, Events, Threads und all dem anderen, dass es so gibt. Meine 
Lieblinge werden gerade abstrakte Klassen, weil sich ganz tolle Dinge 
damit machen lassen.

So als Beispiel:

Ich kann sagen, ich erzeuge eine abstrakte Klasse namens Vehikel. Und 
ich erzeuge eine Klasse namens Auto, die von Vehikel erbt. In Visual 
Basic wäre die Vererbung schon gar nicht möglich und Vehikel sowie Auto 
zwei verschiedene, nicht kompatible Klassen.

In C# hingegen kann ich sagen:

 
    class Program
    {
        static void Main(string[] args)
        {

            Vehikel Instanz_einer_Vehikel_Klasse = new Auto();

            Console.WriteLine("OK, ich versuche von A nach B zu fahren.\n");

            // Probieren wir mal zu fahren, ohne dass der Motor an ist
            Instanz_einer_Vehikel_Klasse.Fahre_von_A_nach_B();

            // Ok, das ging nicht -> jetzt starten wir erstmal das Fahrzeug
            Instanz_einer_Vehikel_Klasse.StarteDasFahrzeug();

            // Und jetzt versuchen wir erneut loszufahren
            Instanz_einer_Vehikel_Klasse.Fahre_von_A_nach_B();
        }

        public abstract class Vehikel
        {
            protected bool Ist_das_Auto_an = false;

            public void StarteDasFahrzeug()
            {
                Console.WriteLine("Wüüüiip wüüüüüiip wüiiiip");

                Ist_das_Auto_an = true;

                Console.WriteLine("brumm brumm brumm brumm brumm");
            }

            // Damit die Auto-Klasse weiß, welche Funktionen sie bereitstellen muss
            public abstract void Fahre_von_A_nach_B();
        }

        public class Auto : Vehikel
        {
            public override void Fahre_von_A_nach_B()
            {
                if (base.Ist_das_Auto_an)
                {
                    Console.WriteLine("Gut, der Motor läuft, dann fahre ich jetzt von A nach B");
                    Console.ReadLine();
                } else
                {
                    Console.WriteLine("Ich trete schon so fest ich kann aber das " + this.ToString() + " will sich einfach nicht bewegen!");
                    Console.ReadLine();
                }
            }

            public override string ToString()
            {
                return "Auto";
            }
        }
    }

Ich kann also beispielsweise der Klasse Vehikel einfach ein Objekt vom 
Typ Auto zuweisen, obwohl Auto und Typ zwei verschiedene Objekte sind. 
Dadurch, dass Auto allerdings von Vehikel erbt, stehen dem Auto alle 
Funktionen von Vehikel zur Verfügung. Anders herum gilt allerdings auch: 
Ein Auto, das ein Typ der Klasse Vehikel ist, kann nicht mehr, als jedes 
Vehikel.

> Ich habe erstmal Versucht den Sinn hinter den Klassen zu finden, und
> muss nun eingestehen das dies eine feine Sache ist. Selbst für meine
> "kleinen" Bedürfnisse. Die Idee dahinter, das alles zu instanzieren, ist
> gar nicht verkehrt.

Es geht dabei weniger um das Instanziieren, sondern darum, dass C#.Net 
die objektorienterte Programmierung einfach absolut konsequent umsetzt.

Ich stamme selbst aus der Visual Basic Ecke und habe lange gebraucht, um 
mir die neuen Konzepte zu verinnerlichen. Aber ich muss zugeben, dass 
ich seitdem deutlich glücklicher bin als vorher, auch wenn es 
augenscheinlich erstmal viel umständlicher ist. Aber auf den zweiten, 
dritten oder gar erst vierten Blick wirst Du merken, dass es ein 
weitaus! besseres Konzept ist.

Früher hätte ich nie gedacht, dass ich das selbst mal sage, aber auch 
Visual Basic 6 war einfach grottiger Schrott!

[Thorsten (Gast)]

In deinem Beispiel fällt mir aber die nächste Stufe ein und zwar 
Interfaces. Die Sprache ist schon mächtig, aber ich muss sagen, dass 
viele Beispiele sich auf alte Dinge beziehen und für ein Neuling ist 
schwer zu erkennen, wieso der eine die Methode, Namespace usw. benutzt, 
einiges wurde doch in der Zeit recht vereinfacht nur sind die Beispiele 
für Anfänger wirklich rare, Beispiel Task.Run, async, await und 
Task.StartFactory.

[Jörg M. (derlang)]

Wenn ich diese ganzen Unterstriche sehe, sträuben sich mir die 
Nackenhaare hoch...

In Hochsprachen verwendet man üblicherweise PascalCase/camelCase!!!

[Martin S. (sirnails)]

Jörg M. schrieb:
> Wenn ich diese ganzen Unterstriche sehe, sträuben sich mir die
> Nackenhaare hoch...
>
> In Hochsprachen verwendet man üblicherweise PascalCase/camelCase!!!

Stimmt. Es ging mir nur um Lesbarkeit.

Wer wirklich programmieren will sollte mindestens die Design Rules 
kennen und wissen wer die GoF ist.

[Najaner (Gast)]

Jörg M. schrieb:
> In Hochsprachen verwendet man üblicherweise PascalCase/camelCase!!!

Das stimmt so generell nicht. In C und C++ sind Namen mit Unterstrichen 
gar nicht so unüblich (allerdings klein geschrieben und fast immer mit 
nur einem Unterstrich).