Verwendung der statischen Methode und der Variablen - Gut gegen Schlecht

8

Ich entwickle C # und asp.net Web-Anwendung.

Ich habe allgemeine Klasse namens Dienstprogramme, ich habe viele öffentliche und statische Variablen in dieser öffentlichen Dienstklasse.

Da diese Zahl allmählich zunimmt, möchte ich wissen, ob es sinnvoll ist, Dienstprogramme-Methoden und -Variablen als public static zu speichern.

Beispiel für meinen Code

%Vor%     
Shruti Sharma 08.09.2011, 10:21
quelle

5 Antworten

12

An static -Klassen ist nichts von Natur aus falsch, obwohl sie normalerweise keine state (fields) haben sollten. Die Verwendung von public static -Feldern zeigt an, dass dies nicht der Fall ist. Daher scheint es, als ob Sie das static -Schlüsselwort leicht missbrauchen. Wenn Ihre Klasse einen Zustand haben muss, sollte es eine normale, nicht statische Klasse sein, und Sie sollten Instanzen davon erstellen. Andernfalls sollten die einzigen öffentlichen Felder, die in der Klasse sichtbar sind, const sein (berücksichtigen Sie die Klasse Math , mit Konstanten wie Math.PI - eine gute Verwendung von static Methoden und Feldern).

Eine weitere Überlegung ist Zusammenhalt . Methoden existieren typischerweise in einer Klasse gruppiert, weil sie auf die eine oder andere Weise eng miteinander verwandt sind. Auch hier ist die Math -Klasse ein gutes Beispiel; alles da drin hat mit Mathematik zu tun. An einem bestimmten Punkt möchten Sie Ihre globale Dienstprogrammklasse in mehrere kleinere, fokussiertere Klassen aufteilen. Sehen Sie Wikipedia für einige Beispiele zur Kohäsion, es klingt wie Ihre Verwendung fällt unter "Zufälliger Zusammenhalt (am schlechtesten)" .

    
Daniel B 08.09.2011, 10:49
quelle
6

Es ist nichts falsch mit diesem Ansatz für Methoden, aber Variablen sollten wirklich const sein, wenn sie statisch und öffentlich sind. Wenn sie sich ändern, sollten Sie eine andere Struktur für Variablen betrachten, die von mehr als einer Komponente manipuliert werden.

Persönlich bin ich ein Fan des Singleton Musters.

    
acron 08.09.2011 10:28
quelle
2

static ist per se keine schlechte Sache. Methoden, die nicht auf Membervariablen oder Methoden zugreifen müssen, sollten immer als statisch deklariert werden. Auf diese Weise sieht der Leser des Codes sofort, dass eine Methode die Membervariablen oder Methoden nicht ändert.

Bei Variablen ist die Situation anders, Sie sollten static Variablen vermeiden, es sei denn, Sie machen const . Public static Variablen sind global zugänglich und können leicht Probleme verursachen, wenn mehrere Threads ohne ordnungsgemäße Synchronisation auf dieselbe Variable zugreifen.

Es ist schwer für Ihren Fall zu sagen, ob es eine gute oder eine schlechte Idee ist, Statik zu verwenden, weil Sie keine Kontextinformationen angegeben haben.

    
thumbmunkeys 08.09.2011 10:40
quelle
2

Es ist keine gute Übung, eine Klasse zu erstellen, um alles zu tun, und es wird empfohlen, Ihr Projekt zu strukturieren und Dinge, die zueinander gehören, von der Zufälligkeit getrennt zu halten.

Ein gutes Beispiel dafür war ein Projekt, das ich von einem Kollegen übernommen habe. Es gab eine Klasse namens Methoden. Es enthielt über 10K Zeilen von Methoden.
Ich kategorisierte sie dann in ca. 20 Dateien, und die Struktur wurde wiederhergestellt.

Die meisten Methoden aus diesem Projekt validierten Benutzereingaben, die leicht in ein static class Validation verschoben werden können.

Eine schreckliche Sache, die ich bemerke, sind die veränderlichen öffentlichen und statischen Variablen. Dies ist aus mehreren Gründen schlecht:

  1. Falsches Verhalten, denn wenn eine Methode dies ändert, obwohl dies nicht der Fall ist, führt dies dazu, dass andere Methoden sich nicht richtig verhalten, und es ist wirklich schwer, das Verzeichnis zu finden / zu debuggen.
  2. Nebenläufigkeit, wie werden wir die Threadsicherheit gewährleisten? Überlassen wir es allen Methoden, die damit arbeiten? Sagen Sie, wenn es ein Werttyp ist, was werden wir sie sperren lassen? Was ist, wenn eine Methode vergisst, sie threadsicher zu machen?
  3. Expand-Fähigkeit (ich hoffe, Sie verstehen, was ich damit meine), wenn Sie zum Beispiel statische Daten haben, die all diese öffentlichen statischen Variablen speichern, die Sie nicht haben sollten. Es kann einmal gespeichert werden, wenn Sie zum Beispiel Ihre Anwendungsstruktur etwas ändern und sagen, dass Sie zwei Projekte auf demselben Bildschirm laden möchten, dann ist es sehr schwierig, dies zu ermöglichen, weil Sie nicht zwei erstellen können Instanzen einer statischen Klasse. Es gibt nur eine Klasse und es wird so bleiben.

Für Nummer 3 wäre eine sauberere Lösung, entweder eine Liste von Instanzen einer Datenklasse zu speichern oder einen Verweis auf die Standardklasse und / oder die aktive Datenklasse zu speichern.

Statische Member und private statische Member (oder geschützt) sind eine gute Methode, solange Sie keine großen Klassen erstellen und die Methoden verwandt sind.

Öffentliche und statische Variablen sind in Ordnung, wenn sie nicht wirklich variabel sind.
Die zwei Möglichkeiten, dies zu tun, sind, indem Sie sie als konstant markieren ( const Modifikator) oder nur lesen ( readonly Modifikator).

Beispiel:

%Vor%

Der Vorteil von Methode 1 besteht darin, dass Sie sich nicht um die Thread-Sicherheit kümmern müssen, der Wert kann sich nicht ändern.
Methode 2 ist nicht Thread-sicher (obwohl es nicht schwierig ist, dies zu tun), aber es hat den Vorteil, dass die statische Klasse selbst den Verweis auf die Utilities-Klasse ändern kann.

    
Aidiakapi 08.09.2011 10:40
quelle
1

Nein, es ist keine gute Methode für große Anwendungen, besonders nicht, wenn Ihre statischen Variablen veränderbar sind, da sie dann effektiv globale Variablen sind, ein Code-Geruch, den die objektorientierte Programmierung "lösen" sollte.

Beginnen Sie zumindest damit, dass Sie Ihre Methoden in kleinere Klassen mit zugehöriger Funktionalität einteilen - der Name Util verrät nichts über den Zweck Ihrer Methoden und Gerüche einer inkohärenten Klasse an sich.

Zweitens sollten Sie immer überlegen, ob eine Methode besser als (nicht statische) Methode für dasselbe Objekt implementiert werden kann, für das die Daten, die als Argumente an die Methode übergeben werden, ebenfalls existieren.

Schließlich, wenn Ihre Anwendung ziemlich groß und / oder komplex ist, können Sie Lösungen wie den Container Inversion of Control in Betracht ziehen, der die Abhängigkeit vom globalen Status reduzieren kann. ASP.Net Webforms ist jedoch schwer in eine solche Umgebung zu integrieren, da das Framework in sich sehr eng gekoppelt ist.

    
Jonas H 08.09.2011 10:32
quelle