Klassen nutzt man doch hauptsächlich wenn man den Quelltext übersichtlich gestalten will.
Daher habe ich folgende Klasse erstellt.
class Mitarbeiter
{
// globale Variablen
string vorname;
string nachnahme;
int alter;
string schule;
public Mitarbeiter(string vorname, string nachnahme , int alter, string schule) {
this.vorname = vorname;
this.nachnahme = nachnahme;
this.alter = alter;
this.schule = schule;
}
public void anzahlMitarbeiter() {
}
}
In Form1 rufe ich 8 Instanzen wie folgendermaßen auf.
Mitarbeiter name = new Mitarbeiter("Name", "Vorname", 1,"schule");
Mitarbeiter name2 = new Mitarbeiter("Name", "Vorname", 1,"schule");
Mitarbeiter name3 = new Mitarbeiter("Name", "Vorname", 1,"schule");
Mitarbeiter name4 = new Mitarbeiter("Name", "Vorname", 1,"schule");
In "public void anzahlMitarbeiter() " wollte ich jetzt eine Methode schreiben die mir die Instanzen zählt welche ich aufgerufen habe.
Kann mir da jemand helfen wie ich da verfahren soll?
Klassen nutzt man doch hauptsächlich wenn man den Quelltext übersichtlich gestalten will.
Nicht nur 😛 Im Grunde lässt es sich aber darauf zusammen dampfen.
Probier das mal:
public class MyClass
{
public static int AmountInstances { get; private set; }
public MyClass()
{
AmountInstances++;
}
}
Das ist aber nicht threadsafe, mit der Interlocked-Klasse wäre das aber einfach möglich.
@Palladin007
Bei dem Beispiel muss noch IDisposable implementiert werden um die Anzahl der Instanzen auch wieder runterzuzählen.
Und dann muss man überall, wo die Instanzen verwendet werden, entweder using nutzen oder direkt Dispose aufrufen.
T-Virus
Developer, Developer, Developer, Developer....
99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.
string nachnahme;
Wieso keine Vorauskasse oder per Rechnung? 😉
@T-Virus:
Stimmt
Allerdings würde ich da direkt den Destruktor verwenden:
~MyClass()
{
AmountInstances--;
}
Es gibt keine Ressourcen, die ich frei geben müsste und das runter zählen ist eine minimale Aufgabe, daher würde ich in diesem Fall auf IDisposable verzichten.
Wichtig wäre zu wissen was soll damit erreicht werden?
Wenn es darum geht die Anzahl von Mitarbeitern in einem Unternehmen zu erfassen, sollte man lieber zählen wie viel Mitarbeiter in einer Datenbank stehen, oder in einer XML Datei, oder wie viele Mitarbeiter jemand gerade eingegeben hat ....
Aber nicht die Anzahl der erstellten Instanzen. Wenn jemand sich dreimal die Ansicht für Mitarbeiter geöffnet hat, für jeden angezeigten Mitarbeiter dreimal eine Instanz geöffnet wurde und eine unbekannte Anzahl Instanzen vom GC schon wieder entsorgt wurden, was sagt das noch aus?
Sich aus Interesse ansehen wollen wie oft eine Instanz erzeugt wird, ist natürlich was anderes. Auch da muss man sich allerdings bewusst sein dass nicht alle erstellten und noch nicht entsorgten Instanzen in diesem Moment noch benötigt werden.
@Palladdin007
In C# ist dies kein Destruktor sondern ein Finalizer.
Sollte man nur implementieren, wenn man weiß was er macht und wozu er gut ist.
In diesem Fall wäre er sogar kontraproduktiv, da das Objekt erst viel später zerstört wird als beim disposen.
T-Virus
Developer, Developer, Developer, Developer....
99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.
@Palladdin007
In C# ist dies kein Destruktor sondern ein Finalizer.
Syntaxtisch gesehen ist es in C# ein Destruktor. Technisch gesehen in .NET ein Finalizer.
Man spricht aber umgangsprachlich durchaus allgemein einfach von einem Destruktor.
Trotzdem macht ein Zählen über den Destruktor keinen Sinn, wenn es um die Anzahl der Mitarbeiter geht.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Ich möchte im Hauptcode Checkboxen anzeigen lassen. Wenn 4 Mitarbeiter sind, sollen es 4 werden, bei 5, 5 Checkboxen usw.
Nun habe ich eben die Mitarbeiter angelegt im Hauptcode via neue Instanz und den passenden Parametern und wollte nun zeitlich zählen lassen wieviel Checkboxen nun angezeigt werden sollen.
Hoffe das es verständlich war, was ich wollte.
Warum speicherst du dann nicht die Instanzen zwischen bzw. wie machst du es den bisher?
Du musst doch die Menge der Arbeiter kennen oder?
Dann musst du dies einfach dynamisch mit einer for Schleife machen.
Nachtrag:
Anbei solltest du NIE mit öffentlichen Feldern arbeiten, dafür gibt es die Properties.
Felder sollten immer private sein.
Aktuell legst du die interna deiner Mitarbeiter Klasse über deine "globalen" Variablen offen.
Globale Variablen sind absolut schlechter Stil in der OO Welt.
T-Virus
Developer, Developer, Developer, Developer....
99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.
Du musst die Mitarbeiter in einer Liste (List<T>) führen.
Da gibt es dann eine Count-Property bzw. kannst Du dann darüber iterieren.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Das Wissen über die Gesamtzahl der Mitarbeiter gehört nicht in den Aufgabenbereich der Klasse Mitarbeiter (wie im richtigen Leben auch). Führ ein Element ein, dass die Erstellung und Löschung von Mitarbeiter-Objekten in seiner Kontrolle hat (heisst: eine Klasse, die zB über die genannte Liste die Mitarbeiter speichert und als einziges new Mitarbeiter() aufrufen darf). Dort ist dann auch die Anzahl der momentan vorhandenen Mitarbeiter-Instanzen bekannt.
LaTino
"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)
Das ist ein Standardproblem, das sich auch mit herkömmlicher objektorientierter Programmierung lösen läßt:
public class Company
{
public List<Employee> Employees { get; set; }
public int EmployeeCount
{
get { return Employees.Count; }
}
}
Warum man da auf die Idee kommen sollte, mit statischen Variablen, Konstruktoren und Destruktoren zu arbeiten, und warum diese Idee hier auch noch weiter verfolgt werden sollte, erschließt sich mir nicht.
Weeks of programming can save you hours of planning