OOP - MySQL Klasse sinnvoll? -> Verwendung in anderer Klasse?

[saftmeister]

Ist das nicht bei jeder Klasse so, die eine statische Methode anbietet? Ist das nicht der Sinn von statischen Klassen-Methoden, von überall aus ansprechbar zu sein, ohne eine Instanzvariablen erzeugen zu müssen?

Verstoßen dann alle Klassen, die eine statische Methode haben gegen OOP? Also auch das Factory-Pattern, die Registry? Was ist mit den Datentypen-Klassen in Java, die vielerorts "valueOf" oder dergleichen anbieten? Verstoßen die dann auch gegen OOP?

EDIT: Und was das Kapseln von Daten angeht: Wenn ich keine statische Methode hätte, sondern mir eine erst eine Instanz erstellen müsste, um an das Datum zu kommen, worin liegt dann - mal abgesehen vom Code - der Unterschied?

<?php

$foo = Foo::getInstance();

// oder

$f = new Foo();
$foo = $f->getFoo();

 

[Hawkster]

Erstmal danke für die vielen Antworten.

Nochma etwas zurück. PDO ersetzt das mysql_*() einfach durch eine Klasse wenn ich das richtig verstehe. Soweit ist mir das auch klar.
Zu dem Singleton will ich mich derzeit noch nicht äußern da ich eine fundamentalere Frage habe:
Die Grundidee von Klassen ist es doch, immer wieder auf anderen Klassen aufzubauen.
Um ein Auto zu bauen brauche ich also Reifen (Basisklasse), Fahrgestell (Basisklasse) usw.
Diese werden am Ende zu einer Klasse "Auto" umfunktioniert. Oder?

Oder ist der Ansatz von Anfangan falsch? Ich kann ja nur immer eine Klasse als extend angeben, aber wie komm ich dann an mein Ziel?

 

[saftmeister]

PDO ersetzt das mysql_*() einfach durch eine Klasse wenn ich das richtig verstehe.

Ähm, jein. Dazu aber mehr, wenn du es wirklich einsetzen willst und Fragen hast.

Die Grundidee von Klassen ist es doch, immer wieder auf anderen Klassen aufzubauen.
Um ein Auto zu bauen brauche ich also Reifen (Basisklasse), Fahrgestell (Basisklasse) usw.
Diese werden am Ende zu einer Klasse "Auto" umfunktioniert. Oder?

Oder ist der Ansatz von Anfangan falsch? Ich kann ja nur immer eine Klasse als extend angeben, aber wie komm ich dann an mein Ziel?

Da es sich bei Reifen, Fahrgestell, Scheiben, etc. um Komponenten von Autoteilen handelt, werden diese als Objekt-Eigenschaft von Auto festgelegt. Es ergibt sich dann so ein Bild:

class Reifen
{
  protected $_hersteller;
  protected $_groesse;
}

class Fahrgestell
{
  protected $_hersteller;
  protected $_modellNummer;
}

class Auto
{
  protected $_hersteller;
  protected $_modell;
  protected $_fahrgestell;
  protected $_reifen;
  protected $_scheiben;

  public function setReifen(Reifen $reifen)
  {
    $this->_reifen = $reifen;
  }

  public function setFahrgestell(Fahrgestell $fahrgestell)
  {
    $this->_fahrgestell = $fahrgestell;
  }
}

Dann kannst du ableiten und z.B. einen Reifen von Bridgestone definieren:

class Bridgestone extends Reifen
{
  public function __construct()
  {
    $this->_hersteller = 'Bridgestone';
  }
}

Das kannst du dann weiter ableiten und verschiedene Reifen von Bridgestone definieren. Das Prinzip bleibt das Gleiche. Interessant wird dann aber folgendes:

class BMW5er extends Auto
{
  public function __construct()
  {
    $this->_hersteller = 'BMW';
    $this->_modell = '5er';
  }
}

$mein5erBMW = new BMW5er();
$mein5erBMW->setReifen( new Bridgestone() );

Prinzip verstanden?

 

[alxy]

Das ist auch eine gute frage, die ich ebreits auf einem anderen Board mal disktuiert habe: Brauchen wir statische Methoden? Der Unterschied bei statischen methoden ist eben, dass nur diese Methode global verfügbar ist, es ist möglich, weitere öffentliche (nicht statische) Methoden zumindest im Hinblick auf den Zugriff (Objektkontext) zu kapseln.

Der Unterschied in deinem beispiel hat nichts mit der Kapselung zu tun, sondern mit der "Austauschbarkeit" (deutsch ist eine schöne Sprache...). Wenn sowas wie Singletone::getInstance(); innerhalb einer klasse steht, musst du wenn du die Singletone Klasse austauschen willst, auf jedenfall auch wieder im "Inneren" der anderen Klasse rumändern. Und das will man ja vermeiden.

 

[saftmeister]

Der Unterschied bei statischen methoden ist eben, dass nur diese Methode global verfügbar ist, es ist möglich, weitere öffentliche (nicht statische) Methoden zumindest im Hinblick auf den Zugriff (Objektkontext) zu kapseln.

Ähm, sorry, das hab ich nicht verstanden. Wenn eine nicht-statische Methode öffentlich ist, ist sie das auch, wenn das Objekt zu dem die Methode gehört, privat ist. Es macht zugriffstechnisch keinen Unterschied ob ich notiere

$a = Klasse::getInstance();
$a->do();

// oder

$a = Fabrik::factory('A');
$a->do();

$a = Registry::get('A');
$a->do();

// oder

$a = new AKlasse();
$a->do();

Der Unterschied in deinem beispiel hat nichts mit der Kapselung zu tun, sondern mit der "Austauschbarkeit" (deutsch ist eine schöne Sprache...). Wenn sowas wie Singletone::getInstance(); innerhalb einer klasse steht, musst du wenn du die Singletone Klasse austauschen willst, auf jedenfall auch wieder im "Inneren" der anderen Klasse rumändern. Und das will man ja vermeiden.

Wenn mein Singleton, oder auch meine Factory eine Instanz zurück gibt, die auf der Grundlage einer Klasse erzeugt wurde, welche ein Interface implementiert, muss ich im anderen Code nichts ändern. Die Schnittstelle bleibt gewahrt.

 

[alxy]

Man kann bei einer Klasse mit statischen Methoden auch noch "normale" Methoden haben, die sich NUR aus dem Objektkontext heraus aufrufen lassen. Das meinte ich damit.

Bei dem zweiten muss ich dir recht geben: Ich war von einem Singeltone ausgegangen, dass neben der Singletone-Logik auch gleich die "Main"-Logik enthält. Also mehr ein Container der sicherstellt, dass von jedem nur eine Instanz da ist.

Was ich grade noch gefunden habe: http://r.je/static-methods-bad-practice.html
Und als Ersatz für das Singletone und um die Einmaligkeit eines Objekts zu garantieren: http://pimple.sensiolabs.org/ und seine Methode "shared".

In diesem Sinne sehe ich keine wirklichen Einsatzgebiete mehr für static (außer die im artikel erwähnten, sehr seltenen) und das Singletone.

 

[saftmeister]

Man kann bei einer Klasse mit statischen Methoden auch noch "normale" Methoden haben, die sich NUR aus dem Objektkontext heraus aufrufen lassen. Das meinte ich damit.

Ok, aber was ist daran gut/schlecht? Das ist ja eigentlich ganz normal. Du kannst sogar soweit gehen, eine statische Methode private sein zu lassen ;-)

Bei dem zweiten muss ich dir recht geben: Ich war von einem Singeltone ausgegangen, dass neben der Singletone-Logik auch gleich die "Main"-Logik enthält. Also mehr ein Container der sicherstellt, dass von jedem nur eine Instanz da ist.

Cool! Und jetzt stell dir vor, das Singleton selbst würde das Interface implementieren und der Typ der inneren statischen Instanzvariable wäre vom Typ Singleton.

Was ich grade noch gefunden habe: http://r.je/static-methods-bad-practice.html
Und als Ersatz für das Singletone und um die Einmaligkeit eines Objekts zu garantieren: http://pimple.sensiolabs.org/ und seine Methode "shared".

In diesem Sinne sehe ich keine wirklichen Einsatzgebiete mehr für static (außer die im artikel erwähnten, sehr seltenen) und das Singletone.

Danke, werde ich mir ansehen.