Aber zum Thema:
In deinem Beispiel ist beides äquivalent, das sagte Markus ja auch schon und (widerwillig) stimme ich dem auch zu.
Abgesehen davon, dass ich mit PreferredCustomer oder so arbeiten würde.

Preferred ist aber ein Status des Objekts. Und wir erinnern uns: Objects are all about state and behaviour.

Und wenn dieser änderbar sein soll, dann kann er nur vom Objekt selbst geändert werden oder von einem anderen Objekt, dass dazu befähigt ist. Ein Kunde macht sich ja nur selten selbst zum Premiumkunden, nicht wahr?

Deshalb sind die meisten der in Beispielen gezeigten Setter böse. Nicht vom technischen Standpunkt aus, sondern vom konzeptionellen; und Letztere entscheidet in einer Geschäftsanwendung.
Im Kommentar zu Timo habe ich ein Beispiel dazu.

Analog zu preferred wäre ein Beispiel, dass dem Kunden ein Punktewert zugewiesen wird und es daraufhin zu einer Aufwertung zum Premiumkunden kommt.
Oder aber ich habe eine explizite Methode z.B. in der Anwendung des Kundenservice, der beliebige Kunden zu Premiumkunden machen kann (z.B. weil es mein Vetter ist).

Es ist in beiden Fällen eine Kapselung der Informationen, die nicht bloß Werte sind, sondern eine explizite Bedeutung haben und oft einiges entweder nach sich ziehen oder Vorbedingungen erfüllt sein müssen.

Ich merke aber langsam auch, dass dies ein viel zu vielschichtiges Thema für einen Blogkommentar ist.

Um z.B. einen Adresse zu ändern, könnte man nur eine neue Straße angeben.
$c->setStreet(…);

Aber man kann auch etwas machen:
$c->changeAddress(…);

Damit kriegst du auf Methodenebene einen in sich abgeschlossenen Vorgang.
Und musst nicht wissen, das man bei einer Adressänderung noch weitere 5 Methoden aufrufen muss, die vielleicht auch noch mehr machen.

Ziehst du von Hausnummer 15 in 17 ändert sich nicht nur deine Hausnummer, sondern es ändert sich deine Adresse!
Weil das “Konzept” Adresse in den meisten Anwendungen (nicht nur Software) als Ganzes betrachtet wird.

Das ist die angesprochene Kapselung von Informationen.

gegen

class Customer
{
private $isPreferred;

public function __construct( )
{
$this->isPreferred = false;
}
}

Oder verstehe ich da was falsch? Dass alle “Pflichtfelder” mit der Initialisierung gefüllt sein sollen, da stimme ich dir voll und ganz zu.

PS: Sorry falls die Beispiele ein wenig hinken.

Das weiß ich schon, das man sich nicht sklavisch daran halten sollte. Allerdings kann man einige Prinzipien zwar umgehen oder als akademisches Zeug abstempeln, nur macht man dann eben kein wirkliches OOP mehr, eher COP (Class Oriented P.), was leider oft die Regel ist.

Und nur weil es in PHP geht, heiß das doch nicht, das man es machen sollte. Nicht alles was machbar ist, ist auch sinnvoll.
Abgesehen davon kann sich das noch ändern, und dann schreibe ich alles um?

Ähm, und wieso sollte das Besprochene in PHP nicht sinnvoll anwendbar sein?
Guckst du…

Wenn es irrelevant ist, ob ein Attribut im Constructor oder bei der Deklaration initialisiert wird, dann ist dieser Wert ebenso irrelevant. Und von denen rede ich nicht.

Vor allem geht um dies hier:

$c = new Customer();
$c->setFirstname(‘John’);
$c->setPreffered(1);
$c->doSomething();
$orm->save($c);

So, was ist das für ein Customer? Einer ohne Nachnamen und Adresse, in welchem Status ist er und warum darf er ein Premiumkunde sein? Hat er alle Eigenschaften bekommen um ihn als Customer im weiteren Verlauf ansprechen und auf seine Eigenschaften zugreifen zu können? Und wieso darf ich ihn speichern in dem Zustand??

Wieso erzeugt man ein Objekt, das noch nicht “fertig” ist?
Will man ernsthaft damit im weiteren Verlauf arbeiten?

Die Umgehung solcher Prinzipien macht vielleicht weniger Mühe, führt aber zu fehleranfälligen und unverständlichem Code und jede Menge Seiteneffekten bei komplexeren Anwendungen.
Die Beispiele hier waren ja Pipifax, mach das aber mal bei einer komplexen Anwendung. Die haut dir das Zeug später um die Ohren, wenn du nicht kapselst, Informationen versteckst und Kernkonzepte und Verhalten nicht explizit gestaltest.

Vielleicht sollte an dieser Stelle das Konzept von C# übernommen werden. Das finde ich immer noch am besten.