Gibt es einen Bezeichnung für Art von Klasse?

[MB]

moin,

Gibt es einen bestimmte Bezeichnung für Klassen, wobei die Logik in den Klassen bleibt und sie nur einen Eingangspunkt besizten?

so…

class ThingInstance {

  public function __construct ( ? ) {
    $this->doSomeThing ( ? );
    $this->doOtherThing ( ? );
  }

  private function doSomeThing ( ? ) : ? {
    // Logik Teil
  }

  private function doOtherThing ( ? ) : ? {
    // Logik Teil
  }
}

…order so…

class ThingInstance {

  public function __construct ( ? ) {
    // Logik Gesamt
  }
}

es käme bei beiden Beispielen, von außen betrachtet, die gleiche funktionalität hereaus. Ob es sich um Instanzen oder Klassen funktionalität handelt, ist in meine Frage unerheblich.

lgmb

P.S.:Ich hoffe man versteh mich, wenn nicht, ist es nicht tragisch 😉

[pl]

Moin,

der Konstruktor ist eine Klassenmethode. In PHP werden Klassenmethoden auch als statische Methoden bezeichnet.

MFG

PS: Man kann die Klasse jedoch nicht als statische Klasse bezeichnen weil sie instanziiert werden kann.

[dedlfix]

Tach!

der Konstruktor ist eine Klassenmethode. In PHP werden Klassenmethoden auch als statische Methoden bezeichnet.

Nein. Die Konstruktormethode wird aufgerufen, wenn eine Instanz erstellt wird. Und es gibt keine statischen Konstruktoren in PHP.

PS: Man kann die Klasse jedoch nicht als statische Klasse bezeichnen weil sie instanziiert werden kann.

Wenn eine Klasse nicht instantiiert werden soll, gibt man ihr eine private Konstruktormethode. Damit ist sie de facto statisch, weil der Versuch, Instanzen zu erstellen, zu einem fatalen Fehler führt.

Andererseits kann man einer solchen Klasse eine static Methode spendieren, in der Instanzen erstellt werden können, da sie als Mitglied der Klasse die private Konstruktormethode aufrufen darf.

dedlfix.

[pl]

PS: Klassenmethoden verhalten sich statisch, egal ob man static davorschreibt oder nicht. Eine Klasse die nur statische Methoden hat und nicht instanziiert werden kann, ist eine statische Klasse.

MFG

[dedlfix]

Tach!

PS: Klassenmethoden verhalten sich statisch, egal ob man static davorschreibt oder nicht.

Die Methode __construct ist aber nicht statisch, weder mit noch ohne static. Sie wird im Instanz-Kontext aufgerufen, und man kann das auch händisch tun, wenn man mag.

Eine Klasse die nur statische Methoden hat und nicht instanziiert werden kann, ist eine statische Klasse.

Ja, gibt es nur nicht in PHP. Wie schon gesagt, mit privater Konstruktor-Methode kann sie zwar nicht von außen instantiiert werden, aber weiterhin von innen. Somit gibt es keine komplett statischen Klassen in PHP.

dedlfix.

[MB]

moin,

Ok, ich habe da wohl meine Eingangsfrage nicht richtig gestellt. Sry dafür @pl.

lgmb

[pl]

moin,

Ok, ich habe da wohl meine Eingangsfrage nicht richtig gestellt. Sry dafür @pl.

Nun, eine Klasse bezeichnet man als statische Klasse wenn sie

1. nicht instanziierbar ist,
2. nur statische Methoden enthält.

Überlege Dir, wie man (1) also die Instanziierung einer Klasse verhindern kann. Anders gesagt, verhindern kann, daß new aufgerufen wird. Wenn Du diese Bedingung erfüllen kannst, darfst Du Deine Klasse eine statische Klasse nennen.

Ansonsten ist Deine Klasse eine ganz gewöhnliche Klasse. MFG

[dedlfix]

Tach!

Nun, eine Klasse bezeichnet man als statische Klasse wenn sie

1. nicht instanziierbar ist,
2. nur statische Methoden enthält.

Überlege Dir, wie man (1) also die Instanziierung einer Klasse verhindern kann.

Gar nicht in PHP.

Anders gesagt, verhindern kann, daß new aufgerufen wird. Wenn Du diese Bedingung erfüllen kannst, darfst Du Deine Klasse eine statische Klasse nennen.

Ist nicht erfüllbar. Es sei denn, du kennst einen Weg, wie sowohl von außen als auch innerhalb der Klasse eine Instantiierung verhindert werden kann.

dedlfix.

[MB]

moin,

moin,

Ok, ich habe da wohl meine Eingangsfrage nicht richtig gestellt. Sry dafür @pl.

Nun, eine Klasse bezeichnet man als statische Klasse wenn sie […] Ansonsten ist Deine Klasse eine ganz gewöhnliche Klasse.

Wie @dedlfix schon erwähnt hat, mag das durch aus in anderen Sprachen gelten, aber nicht hier. Bitte vermische nicht Programmiersprachen. Das verwirrt Leser (z.B. mich), ist extrem hinderlich und trägt zu lösung des Threads nichts bei.

lgmb

[pl]

moin,

moin,

Ok, ich habe da wohl meine Eingangsfrage nicht richtig gestellt. Sry dafür @pl.

Nun, eine Klasse bezeichnet man als statische Klasse wenn sie […] Ansonsten ist Deine Klasse eine ganz gewöhnliche Klasse.

Wie @dedlfix schon erwähnt hat, mag das durch aus in anderen Sprachen gelten, aber nicht hier.

Selbstverständlich gilt der Begriff statische Klasse für alle Programmiersprachen.

MFG

[dedlfix]

Tach!

Selbstverständlich gilt der Begriff statische Klasse für alle Programmiersprachen.

Nein. Wenn man verhindern kann, dass Instanzen erstellt werden können, macht das die Klasse noch lange nicht statisch. Sie fühlt sich nur von außen so an.

class Foo {
    public $bar = 42;

    private function __construct() {
    }

    public static function newInstance() {
        return new Foo();
    }
}

$foo = Foo::newInstance();
echo $foo->bar;

Du kannst eine Klasse mit private Konstruktor nicht selbst instantiieren, aber Mitglieder der Klasse können das weiterhin. Somit kann die Klasse nicht statisch im engeren Sinne sein.

dedlfix.

[Rolf B]

Hallo dedlfix,

möchtest Du Herrn Ratzinger etwas über Dogmen erklären?

Angesichts der Tatsache, dass PHP das Konzept einer statischen Klasse nicht mit Sprachmitteln unterstützt, bleibt doch nur Duck-naming übrig.

Eine Klasse, die ich nicht instanziieren kann, die nur statische Methoden aufweist (plus einen privaten Konstruktor) und bei der auch intern, von den statischen Methoden, keine Instanzen erstellt werden, ist nach allen relevanten Kriterien eine statische Klasse.

Rolf

[MB]

moin,

möchtest Du Herrn Ratzinger etwas über Dogmen erklären?

😀

Angesichts der Tatsache, dass PHP das Konzept einer statischen Klasse nicht mit Sprachmitteln unterstützt, bleibt doch nur Duck-naming übrig.

Ich kenn Duck-Type. Was ist Duck-Naming???

lgmb

[Rolf B]

Hallo MB,

och komm schon. Wenn Dir duck-typing ein Begriff ist, dann solltest du das doch auf duck-naming übertragen können.

Ist doch nur eine andere Anwendung des Ententests.

Rolf

[pl]

moin,

Selbstverständlich gilt der Begriff statische Klasse für alle Programmiersprachen.

Aber daß Deine hier vorgestellte Klasse nicht so bezeichnet werden kann hat ja damit nichts zu tun.

MFG

[pl]

Moin,

der Konstruktor ist eine Klassenmethode.

Um das mal zu zeigen:

class Foo{
    private function __construct(){}
}

$f = new Foo;

Das wirft eine Fehlermeldung wie folgt:

PHP Fatal error:  Call to private Foo::__construct() from invalid context

Genso so ruft man Klassenmethoden auf, mit dem T_PAAMAYIM_NEKUDOTAYIM, also dem doppelten Doppelpunkt. PHP verrät infolge dieser Fehlermeldung daß der Konstruktor eine Klassenmethode ist und new nur ein Wrapper (Fascade).

MFG

[dedlfix]

Tach!

der Konstruktor ist eine Klassenmethode.

Um das mal zu zeigen:

class Foo{
    private function __construct(){}
}

$f = new Foo;

Das wirft eine Fehlermeldung wie folgt:

PHP Fatal error:  Call to private Foo::__construct() from invalid context

Genso so ruft man Klassenmethoden auf, mit dem T_PAAMAYIM_NEKUDOTAYIM, also dem doppelten Doppelpunkt. PHP verrät infolge dieser Fehlermeldung daß der Konstruktor eine Klassenmethode ist und new nur ein Wrapper (Fascade).

Das ist eine falsche Schlussfolgerung. Die Schreibweise Foo::Bar wird dazu verwendet, um zu kennzeichnen, dass Bar ein Mitglied der Klasse Foo ist - oder auch nicht. Mit statisch hat das nichts zu tun. Es ist nur dieselbe Schreibweise wie bei statischen Aufrufen.

class Foo {}
$f = new Foo();

$f->qux; // Notice: Undefined property: Foo::$qux

$f->qux(); // Fatal error: Uncaught Error: 
           // Call to undefined method Foo::qux()

dedlfix.

[MB]

moin,

Genso so ruft man Klassenmethoden auf, mit dem T_PAAMAYIM_NEKUDOTAYIM, also dem doppelten Doppelpunkt. PHP verrät infolge dieser Fehlermeldung daß der Konstruktor eine Klassenmethode ist und new nur ein Wrapper (Fascade).

Sry, nur zum mitschreiben: durch dieses T_PAAMAYIM_NEKUDOTAYIM Indiz leitest du ab, das __construct() eine Klassenmethode sei, wo du - ich betone - augenscheinlich KEIN PHP Profi bist? Und du willst mit deiner - für mich - wagen Annahme, was du "anscheinend" für einen unmstößlicher Beweis hälst, den PHP Profies im Forum - als Laie - "öffentlich" weis machen, das ihre Fachwerk falsch sei?! Den Profis?!

lgmb

[pl]

moin,

Genso so ruft man Klassenmethoden auf, mit dem T_PAAMAYIM_NEKUDOTAYIM, also dem doppelten Doppelpunkt. PHP verrät infolge dieser Fehlermeldung daß der Konstruktor eine Klassenmethode ist und new nur ein Wrapper (Fascade).

Sry, nur zum mitschreiben: durch dieses T_PAAMAYIM_NEKUDOTAYIM Indiz leitest du ab, das __construct() eine Klassenmethode sei,

Zum Erstellen einer Instanz braucht man eine Klassenmethode. Eine Klassenmethode wird über den Namen der Klasse aufgerufen, logisch denn die Instanz muss ja erst erstellt werden.

Insofern darf man __contruct() auch als eine Klassenmethode betrachten. Wenn Du notierst

$f = new Foo($opts);

nimmt new sogar den Namen der Klasse als Methode an, nämlich um die Argumente $opts zu übergeben. Und wenn Du Dich an frühere PHP Versionen erinnerst:

class Foo{
    function Foo($a){}
}
$f = new Foo(1,2,3);

findest Du genau diesen Sachverhalt wieder. Aber überlege doch mal selbst welche Methode Du als diejenige Klassenmethode bezeichnen würdest, welche die Instanz erstellt, Foo() oder __construct() oder new?

Darüber lohnt es sich mal nachzudenken, es ist dem Verständnis für OOP sehr dienlich. MFG

[pl]

Und hier noch was zum Spielen

class Foo{
    function __construct($a){
        $this->ARGS = $a;
    }
    
    function new_instance(){
        return new self(func_get_args());
    }
}

$f = Foo::new_instance(1,2,3); # rufe eine Klassenmethode
print_r($f);

Das gibt aus
Foo Object
(
    [ARGS] => Array
        (
            [0] => 1
            [1] => 2
            [2] => 3
        )

)

Hier haben wir eine explizite Klassenmethode welche die Instanz liefert. Als einen Wrapper für __construct() und new!

MFG

[Rolf B]

Hallo pl,

hier haben wir keine Klassenmethode, sondern eine Instanzmethode, die statisch aufgerufen wird.

Das Handbuch sagt: Nicht nachmachen!

Rolf

[1unitedpower]

Du redest mal wieder Blödsinn.

Konstruktoren in PHP sind keine statischen Methoden, sonst hätten sie keinen Zugriff auf $this, was ziemlicher Unfug wäre. Man kann es aber auch einfach überprüfen:

class Foo {
    public function __construct() {
    }
}

$class = new ReflectionClass('Foo');
$method = $class->getMethod('__construct');

$method->isStatic(); // false

[kai345]

Du redest mal wieder Blödsinn.

Don't mess with him. He's a stable genius.

[dedlfix]

Tach!

Aber überlege doch mal selbst welche Methode Du als diejenige Klassenmethode bezeichnen würdest, welche die Instanz erstellt, Foo() oder __construct() oder new?

Die Konstruktor-Methode erstellt die Instanz nicht, auch keine andere (Klassen-)Methode. Das passiert aufgrund des Operators new. Die Konstruktor-Methode ist optional und kann schon deshalb nicht zuständig sein. Falls sie vorhanden ist - und dabei ist es egal, ob sie alt wie die Klasse heißt oder neu __construct - führt sie nach der Instantiierung zusätzliche Aktionen aus, die der Programmierer definiert hat.

Darüber lohnt es sich mal nachzudenken, es ist dem Verständnis für OOP sehr dienlich.

Eben. Man sollte beachten, dass Konstruktor und Destruktor nicht für das Erstellen und Beseitigen von Instanzen da sind. Die beiden Begriffe sind Verkürzungen für die Konstruktor-Methode und die Destruktor-Methode, und sie erledigen zusätzliche Aufgaben nach der Instantiierung respektive vor dem Entfernen des Objekts.

dedlfix.

[pl]

Siehe auch

Um einen Vaterkonstruktor zu benutzen ist ein Aufruf von parent::__construct() innerhalb des Kindkonstruktors notwendig.

Das heißt: parent ist ein Synonym für die Basisklasse. So wird der Konstuktor der Basisklasse eben mit dem Namen der Basisklasse aufgerufen und nicht mit einer Instanz der Basisklasse.

Der Konstruktor der Basisklasse wird als Klassenmethode aufgerufen.

MFG

[MB]

moin,

@pl ich muss mich bei Dir Entschuldigen WIE abfällig ich Dir hier geantwortet habe, aber nicht DAS ich dich dir geantwortet habe. Das war anstandslos von mir. Der Informationsgehalt, den ich Dir geantwortet habe, ist Sinngemäß, das was ich Dir schon übermitteln wollte. Ich hoffe du nimmst das Sachlich auf 😉.

lgmb

P.S.: Bezogen auf den Diskusionsgegenstand "Klassenmethode" im Instanziierung Kontext mit Magic Methods: Fals Du einfach nur Begriffe verwechselt hast, wie ich es permantent tue, dann wäre es klar und einleuchtend, das wir uns Missverstehen 😀. Dann mach das aber bitte, bitte deutlich, zur Klärung von Missverständnissen. Ich hab da leidvolle Erfahrungen gemacht ud mache sie immer noch bis an mein lebensende 😕

[pl]

moin,

es gibt keinen Grund für Deinen Kniefall. Und was die Begriffe betrifft, di sind eigentlich gar nicht so wichtig, denn es kommt darauf an das Wesentliche zu verstehen.

Und dafür muss man in seinem Hinterkopf gewisse Vorstellungen entwickeln, ja sogar Bilder projezieren die von der Realität abweichen. Wie z.B. die Vorselung daß OOP die Lehre von Äpfeln und Birnen ist. Oder versuche Dir mal bildlich vorzustellen wie ein Byte aussieht. Und dann erkläre mal einem was ein Byte ist.

Und siehst Du, wenn Letzteres nicht funktioniert ist das nicht schlimm. Du selber musst damit klarkommen, darauf kommt es an.

Alles Gute!

[Tabellenkalk]

Hallo,

Und was die Begriffe betrifft, di sind eigentlich gar nicht so wichtig,

Wenn man Eigenbrötler sein und bleiben will, ok.
Aber sobald man sich mit anderen über das Thema austauschen will, z. B. in einem Forum oder wo auch immer, dann benötigt man die Begriffe in genau der Bedeutung wie sie üblich ist.

Gruß
Kalk

[MB]

moin,

es gibt keinen Grund für Deinen Kniefall.

Danke. Für michselbst ist es aber wichtig.

Und was die Begriffe betrifft, di sind eigentlich gar nicht so wichtig, denn es kommt darauf an das Wesentliche zu verstehen.

Ich sehe es exakt ie @Tabellenkalk es sieht. Wenn man sein dein Eigener Herr ist, ist es ok, weil einem keiner Dazwisdchen grätscht. Aber wenn man im Team arbeiten muss odser will, sind die Begriffe extrem Wichtig! Ich selbst habe es als Untergebener am eigenen Leib erfahren, weil mein Vorgesetzer völlig falschen Begriffe verwendet hat und mich dann anraunzt, Obwohl er sehr kollegial und kolant ist.

Und dafür muss man in seinem Hinterkopf gewisse Vorstellungen entwickeln, ja sogar Bilder projezieren die von der Realität abweichen. […]

Genau deswegen gibts die Fachsprache. Die Ausdrücksinhalt müssen genau für alle definiert sein, damit man eine reibungslose Kommunikation hat, sonst sind Missverständnisse vorprogrammiert. Und dann wird das Ergebnis falsch, weil eben Missverständnisse auftraten die von keinem entlarvt wurden (Worst Case).

Alles Gute!

Wünsch ich Dir auch 😉

lgmb

[dedlfix]

Tach!

Gibt es einen bestimmte Bezeichnung für Klassen, wobei die Logik in den Klassen bleibt und sie nur einen Eingangspunkt besizten?

Hmm, vielleicht "schlechter Stil". Das was in deinem Beispiel zu sehen ist, ist eine Klasse, die alles in ihrem Konstruktor macht. Man kann eine Instanz erstellen, aber man kann mit ihr nichts anfangen. Sie hat nur die Nebenwirkungen im Konstruktor. Ob das auf interne Methoden verteilt ist oder nicht, spielt dabei keine weitere Rolle. Wozu soll man also Instanzen erstellen können? In dem Fall sollte der Konstruktor private und die Funktionalität über eine public static Funktion erreichbar sein.

Wenn die Funktionalität nicht auf interne Methoden aufgeteilt werden soll, kann man auch ganz auf die Klase verzichten und eine einfache Funktion erstellen.

Falls dein Beispiel jedoch zu sehr gekürzt war, und die Realität konmplexer aussieht, kann man durchaus auch andere Argumente anführen.

dedlfix.

[Rolf B]

Hallo dedlfix,

Wenn die Funktionalität nicht auf interne Methoden aufgeteilt werden soll, kann man auch ganz auf die Klase verzichten und eine einfache Funktion erstellen.

Das lag mir auch auf der Zunge: So eine Klasse nennt man Funktion 😂

Aber der Nutzen liegt genau in dem, was Du nennst: interne Methoden. Da PHP keine lokalen Funktionen kennt (es sei denn man nutzt anonyme Funktionen), ist eine solche Klasse ein mögliches Mittel, um eine Aufgabe in überschaubare Teilfunktionen zu gliedern und so die Übersicht zu behalten.

Das kann man auch mit einer statischen Klasse machen, ja. Eine statische Klasse hat den Nachteil, dass die internen Methoden alle Daten über Parameter erhalten müssen. Das passt zum funktionalen Paradigma, aber ist PHP für funktionale Programmierung optimiert? Wenn man ein Objekt erzeugt, hat man einen Container für Variablen, die von Konstruktor und Helper-Methoden geteilt werden können.

Ob es sinnvoll ist, die Arbeit im Konstruktor zu erledigen, ist eine andere Frage. Es hängt davon ab, was das Ergebnis der Konstruktoraktivitäten ist. Entsteht nur ein einziger Wert oder eine größere Datenstruktur? Werden Werte aus einer externen Quelle eingelesen? Ist das Objekt bei einem Fehler im Konstruktor lebensfähig? Gerade die letzte Frage ist entscheidend. Ein Konstruktor soll eigentlich nur das Objekt initialisieren. Die Arbeit machen die Methoden. Wenn im Konstruktor etwas schiefgeht, kannst Du keinen Fehlercode zurückgeben. Du kannst nur eine Exception werfen, oder Du musst eine $success-Eigenschaft vorsehen. Code wie diesen finde ich aber nicht so schön:

$foo = new FooTool($data1, $data2, ..., $dependency1, $dependency2, ...);
if ($foo->success) {
   $result = $foo->data;
   // etc
}

Vor allem die Vermischung von Arbeitsdaten und Dependencies in den Parametern gefällt mir nicht. Ich würde dem Worker-Schema folgen und der Methode, die die Arbeit macht, einen Namen geben, der auf die Art der verrichteten Arbeit klar hinweist. Gute Namen ersparen 90% der Kommentare. FooWorker und CreateBarData sind natürlich wenig sprechend 😉

$worker = new FooWorker($dependency1, $dependency2, ...);

$success = $worker->CreateBarData($data1, $data2, ...);
if ($success) {
   $result = $worker->data;
   // etc
}

Dependencies gehen in den Konstruktor, das sind Referenzen auf andere Dienste im Programm. Arbeitsdaten gehen als Parameter an die Run-Methode.

Wenn sich für die Run-Methode kein sinnvollerer Name als "Run" findet, ist das Objekt vielleicht besser ein Funktor:

$foo = new BarWorker($dep1, $dep2, ...);
$result = $foo($data1, data2);

Dein "Häää? Wie geht denn das?" beantwortet sich hier (Magic method __invoke).

Das Ergebnis kann man über Eigenschaften bereitstellen. Man kann hier aber auch PHP-Interfaces wie Iterator oder ArrayAccess einsetzen, um einen "natürlicheren" Zugang zu den Daten zu erhalten.

$worker = new FooWorker();
if ($worker->GetPersons("Müller")) {
   foreach ($worker as $person) {      // Nutzt das Iterable-Interface

   }
   // oder
   $person = $worker[4];               // Nutzt das ArrayAccess-Interface
}

Rolf

[MB]

moin,

lokalen Funktionen kennt (es sei denn man nutzt anonyme Funktionen), ist eine solche Klasse ein mögliches Mittel, um eine Aufgabe in überschaubare Teilfunktionen zu gliedern und so die Übersicht zu behalten.

darauf wollte ich hinaus

Ob es sinnvoll ist, die Arbeit im Konstruktor zu erledigen, ist eine andere Frage.

interne Methode wrapComponent() z.B. Ok das ist jetzt nicht das was ich an Code gepostet habe aber so in die richtung.

lgmb

[Rolf B]

Hallo MB,

was dieses wrapComponent tut, ist Aufgabe des Konstruktors. Das ist Initialisierung, nicht Arbeit.

Die Echos und die Aufrufe von getValue und getData eher nicht. Das gehört in eine andere Methode - separation of concerns

Rolf

[MB]

moin,

was dieses wrapComponent tut, ist Aufgabe des Konstruktors. Das ist Initialisierung, nicht Arbeit.

exakt!

Die Echos und die Aufrufe von getValue und getData eher nicht. Das gehört in eine andere Methode - separation of concerns

Sry, das wollte ich noch erwähnen das diese Echos nicht in euren Fokus geraten. Sry dafür 😕.

lgmb

[pl]

moin,

lokalen Funktionen kennt (es sei denn man nutzt anonyme Funktionen), ist eine solche Klasse ein mögliches Mittel, um eine Aufgabe in überschaubare Teilfunktionen zu gliedern und so die Übersicht zu behalten.

darauf wollte ich hinaus

Aha. Da sehe ich eine Alternative mit Namespace zu arbeiten.

Ob es sinnvoll ist, die Arbeit im Konstruktor zu erledigen, ist eine andere Frage.

Wenn Du nur statische Methoden hast sind Namespaces die Alternative zu statischen Klassen.

Auf ein baldiges Wiedersehen hier, MFG

[MB]

moin,

Hmm, vielleicht "schlechter Stil".

Sehe ich ähnlich.

Das was in deinem Beispiel zu sehen ist, ist eine Klasse, die alles in ihrem Konstruktor macht. Man kann eine Instanz erstellen, aber man kann mit ihr nichts anfangen. Sie hat nur die Nebenwirkungen im Konstruktor. Ob das auf interne Methoden verteilt ist oder nicht, spielt dabei keine weitere Rolle.

Vielen Danke. Du nimmst mir die Worte - die nicht vorhanden sind - aus meinem Mund 😀.

Wozu soll man also Instanzen erstellen können?

Fals der Fall Auftritt und ich OOP entwickle (z.B. Java 8).

In dem Fall sollte der Konstruktor private und die Funktionalität über eine public static Funktion erreichbar sein.

Du meinst Sigelton? Wozu?

Wenn die Funktionalität nicht auf interne Methoden aufgeteilt werden soll, kann man auch ganz auf die Klase verzichten und eine einfache Funktion erstellen.

siehe oben. Zitat: "Fals der Fall Auftritt und ich OOP entwickle[…]".

Falls dein Beispiel jedoch zu sehr gekürzt war, und die Realität konmplexer aussieht, kann man durchaus auch andere Argumente anführen.

Wie sähen solche Argumente aus? Ich hab da an FascadePattern gedacht. Aber nur ins Blaue geschossen.

lgmb

[Rolf B]

Hallo MB,

In dem Fall sollte der Konstruktor private und die Funktionalität über eine public static Funktion erreichbar sein.

Du meinst Sigelton? Wozu?

Du meinst Singleton? Nein, das nicht zwangsläufig das Gleiche.

class Foo {
   static function DoSomeWork($a, $b, $c) {
      $foo = new Foo();
      $foo->doThis($c);
      $foo->doThat();
      return $foo;
   }
   private function __construct($a, $b) {
   }
}

Jeder Aufruf von DoSomeWork erzeugt eine neue Foo-Instanz und gibt sie zurück. Kein Singleton zu sehen.

Im Übrigen möchte ich vor Übereifer im Software-Tango warnen: Daphne, you're overengineering again!

Code für die Zukunft zu bauen ist zumeist sinnlos. Bau das, was Du jetzt brauchst. Baue Unittests, um Fehler durch Codeänderungen automatisiert zu erkennen. Und wenn neue Anforderungen kommen, refaktoriere soweit wie nötig. Aber nicht mehr.

Rolf

[MB]

moin,

Du meinst Singleton? Nein, das nicht zwangsläufig das Gleiche. […] Jeder Aufruf von DoSomeWork erzeugt eine neue Foo-Instanz und gibt sie zurück. Kein Singleton zu sehen.

Warum nicht statische Klassen wählen?

Im Übrigen möchte ich vor Übereifer im Software-Tango warnen: Daphne, you're overengineering again!

Danke Dir für die Warnung. @1unitedpower hat mich auch schon gewarnt. Ich halt mich ja auch bedingt dran aber, ziel des Projektes ist…

1. mich durch das Projekt zu profilieren
2. Design Aspekte am Beispiel zu erlernen und anwenden
3. ein vollständiges Projekt zu liefern (abgesehen von der Terminierung was gefühlte ewigkeit in anspruch nimmt).

in sofern ist es schon ok 😉.

lgmb

[pl]

Ähmm,

wie rufst Du die Klasse auf und was machst Du mit der Instanz?

nur einen Eingangspunkt

Was meinst Du damit? Eingangspunkt für was?

MFG