Klassendesign (wie wählt man zwischen statischen Klassen und freien statischen Klassen)

Denn im Design einiger Frameworks sehen wir oft
DB::get('mall')->where('aaa');
Warum können wir das nicht tun?
DB::get(' mall')::where('aaa');

Ein weiteres Problem besteht darin, dass Objekte, die in Fabriken oder statischen Containern hergestellt werden, im Allgemeinen statisch sind.
Für eine Protokollklasse habe ich beispielsweise sowohl statische als auch nicht statische Designs gesehen. Etwas unsicher

Sagen Sie mir nicht, welcher Werkzeugtyp statisch sein soll, anstatt Unsinn wie neu zu verwenden.

Antwortinhalt:

Denn im Design einiger Frameworks sehen wir oft
DB::get('mall')->where('aaa');
Warum können wir das nicht tun?
DB::get(' mall')::where('aaa');

Ein weiteres Problem besteht darin, dass Objekte, die in Fabriken oder statischen Containern hergestellt werden, im Allgemeinen statisch sind.
Für eine Protokollklasse habe ich beispielsweise sowohl statische als auch nicht statische Designs gesehen. Etwas unsicher

Sagen Sie mir nicht, welcher Werkzeugtyp statisch sein soll, anstatt Unsinn wie neu zu verwenden.

Zunächst müssen Sie den Unterschied zwischen statisch und nicht statisch verstehen.

Statische Klasse kann ohne Instanziierung verwendet werden. In diesem Fall wird es eine leichte Leistungsverbesserung geben.

Statische Attribute werden von allen Instanzen gemeinsam genutzt. Egal wie viele Instanzen es gibt, es gibt nur ein statisches Attribut.

Natürlich gibt es eigentlich keinen großen Unterschied, wenn nicht statische Klassen als Singletons verwendet werden.

Wie kann man also zwischen statisch und nicht statisch wählen? Abhängig vom objektorientierten Verständnis jedes Einzelnen ist die Verwendungsmethode unterschiedlich.

Zum Beispiel loggen Sie sich ein. Wenn es in einem System nur ein Protokollobjekt gibt, ist die Verwendung statischer Klassen zweifellos die beste, da sie im Hinblick auf Methodenaufruf, Leistung und Datenspeicherung praktischer ist. Zu diesem Zeitpunkt können Sie dieses Protokollobjekt als Entitätsobjekt oder als abstraktes Objekt verwenden.

Aber wenn das Protokoll in ein Benutzerverhaltensprotokoll, ein Datenbankbetriebsprotokoll, ein Serverstatusprotokoll usw. verfeinert wird, ist das Protokoll bereits ein abstraktes Objekt und muss zur besseren Verwendung über eine Entität verfügen. Zu diesem Zeitpunkt wäre es besser, nicht statische zu verwenden und neue separat zu verwenden. Denn obwohl sie alle zum selben Protokollobjekt gehören, verfügen sie über unterschiedliche Daten und Methoden. Funktion.

Mein persönliches Verständnis ist also, dass es am besten ist, eine Klasse statisch zu schreiben, wenn es sich bei einer Klasse um ein vollständiges Funktionsmodul handelt, das nicht von anderen Modulen abhängt und nicht erweitert werden muss, um die Funktion dieses Moduls zu vervollständigen.
Wenn eine Klasse nur ein abstraktes Objekt ist und auch von anderen Modulen abhängt, erweitert werden muss, vererbt werden muss usw., ist es besser, nicht statische zu verwenden

• Tatsächlich entspricht es nicht den objektorientierten Designprinzipien. Tatsächlich funktioniert es auf jede Art und Weise, wie Sie es schreiben können

• Zweitens sind statische Klassen nicht einfach zu recyceln. In Skriptsprachen wie PHP endet der Lebenszyklus des Skripts im Allgemeinen, wenn das Skript ausgeführt wird recycelt, also verwenden Theoretisch gibt es für statische Klassen kein Problem beim Speicherrecycling. Aber für Java usw. ist die Verbreitung statischer Klassen nicht förderlich für die Speicherwiederherstellung