Ich habe ein paar Funktionen, die sich mit Cookies beschäftigen. Wäre es eine schreckliche Idee, sie zu gruppieren, indem man sie in eine eigene Klasse überführt und sie als statische Methoden benutzt?Funktionen vs. statische Methoden
Funktionen:
function cookie_get(){}
function cookie_set(){}
function cookie_delete(){}
Statische Methoden:
class cookie
{
static function get(){}
static function set(){}
static function delete(){}
}
Ja, das wäre eine schreckliche Idee, weil static methods are hard to test and mock sein. Erstellen Sie einfach eine echte Cookie-Klasse, die Sie zur Laufzeit mit diesen Methoden als normale Methoden konfigurieren können.
Wenn Sie nur die Funktionen in einem Paket gruppieren möchten, können Sie genauso gut use Namespaces.
bearbeiten: Da Sie es in den Kommentaren gebracht: ja, für alle Testzwecke regulären Funktionen wie Statik als nicht überprüfbar sind. Ihre Ausgangssituation ist also so "schrecklich" wie eine statische Klasse zu verwenden. Selbst der Pseudo-Namespace bringt keinen Vorteil, da Sie dies bereits auf Ihre normalen Funktionen angewendet haben. cookie_get ist so gut oder schlecht wie Cookie::get.
+1 für das Hinzufügen der Referenz. Gut zu wissen. – karim79
Es ist schade Namespaces sind nicht verfügbar bis PHP 5.3. –
@Emanuil [PHP 5.2 hat offiziell das Ende der Unterstützung am 16. Dezember 2010 erreicht] (http://www.php.net/archive/2010.php#id2010-12-16-1). [Alle Benutzer werden aufgefordert, auf PHP 5.3 zu aktualisieren.] (Http: //de2.php.net/migration53) – Gordon
Es wäre eine gute Idee sein, vorausgesetzt, Sie von der caveats involved voll bewusst sind. Dies wird als Utility Pattern bekannt:
Gute Kandidaten für Utility-Klassen Bequemlichkeit Methoden, die funktionell miteinander gruppiert werden können.
Danke, das ist toll zu wissen. Ich frage mich jedoch, warum nicht die nativen Funktionen von PHP dies nutzen. Warum ist 'str_replace()' nicht 'str :: replace()'? –
PHP ist eine prozedurale Sprache, mit OOP-Funktionen als nachträglicher Einfall angeheftet. Es geht um eingebaute Funktionen (mit sehr inkonsistenten Benennungskonventionen) im Gegensatz zu statischen Hilfsklassen, die verwandte Funktionen zusammen gruppieren. – karim79
@EmanuilRusev Der PHP-API-Kern ist im Allgemeinen schlecht entworfen, aber besonders, wenn es um Namespaces geht, weil diese erst in der relativ neuen Version von PHP5 verfügbar waren. Die Form str :: replace() wäre definitiv vorzuziehen, aber ich bezweifle ernsthaft, dass irgendjemand sie rückwirkend zu irgendeinem Zeitpunkt in naher Zukunft zu ihrem Kern hinzufügen wird. –
Es ist eigentlich eine gute Übung, solche Funktionen zu organisieren. Eine moderne Alternative wäre die Verwendung eines namespace.
Das ist eine gute Möglichkeit der Organisation von Code sein würde, aber warum statische Funktionen verwenden, stellen Sie einfach eine Klasse für die erforderliche Funktionalität.
Oder wie oben gesagt die Verwendung von Namespaces, aber ich bin nicht besonders mit den Vor/Nachteile von ihnen vertraut.
$cookie->get() schöner ist als mit cookie_get() meiner Meinung nach bewusst
nur zur Arbeit der üblichen „statische Klassen/Singletons sind der Feind der Unit-Tests“ Probleme auftreten können. –