hi,

der erste würdige thread im profi forum denn ich bisher lesen konnte (:
die "why accessors are evil" diskusion habe ich schon in diversen foren
verfolgt unnd diskutiert.

von der theroie her ist das absolut valide und meines erachtens auch richtig die set/get orgien zu unterbinden. es gibt einen grundsatz der damit zusammenhängt : "tell, dont ask". es gibt aber (wie immer) einige ausnahmen (bsp ValueObjects) für diesen grundsatz. das zur theroie.

in der praxis aber arbeiten wir mit php - einer scriptsprache die auch noch auf einem webserver läuft und dem prinzip von "share nothing" folgt. das bedeutet für mich einen (manchmal anstregenden) mittelweg zwischen performance und optimaler objektorientierung zu suchen. unsere aufgabe besteht darin schnellstmöglich eine aufgabe zu erledigen und dabei im unterschied zu client applikationen auch noch die gesamte infrastruktur jedesmal neu aufzubauen. das heisst für mich im klartext das ich an einigen stellen meiner applikation bewusst design prinzipien verletze. damit meine ich aber nicht das array problem.. das hat waq schon sehr schön gesagt : das design stimmt da wohl nicht.

mir geht es um (jedenfalls für mich) komplexere themen wie zb einem objekt persistenz layer. du gehst ständig auf dem schmalen grad zwischen physikalisch gegebener rechenleistung und guter objektorientierung. für eine normale webseite mit normalem traffic könnte mann das denke ich aberschon hinbekommen. schwieriger wird es mit high traffic seiten oder webanwendungen. hier zählt vor allem anderen die reaktionszeit für den anwender. ich kenn das sogar von mir selbst - wenn irgend eine seite derbe ablahmt muss der content schon richtig sexy sein damit ich die regelmässig besuche.

ein ganz praktisches problem sind dabei zb interfaces bei php5. interfaces beschreiben einen quasi einen vertrag den jedes implementierte objekt erüllen muss. gute sache (für einige auch eine mehrfach vererbung lite) das... hat aber auch den haken das mann keine konstruktoren in einem interface deklarieren sollte. falls mann das tut kann die klasse dann immer nur ein interface mit einem konstruktor implementieren.. irgendwie nicht ganz so prall imho. das führt dann wieder zu den heiss geliebten accessoren:

alles in allem würde ich momentan sagen : mach es wie es passt aber vergiss das refactoring nicht und schreib immer schön tests (tdd). wenn du dann noch versuchst immer erst mal die einfachen wege zu gehen endet das bei sauberem, fehlerfreierem ( ? ) und vor allem weniger code. hört sich für mich persönlich nach nem guten deal an (;

gruss
Sike