"Wenn Du dem User die Möglichkeit gibst, Mist zu bauen, wird er das tun!" war von Anfang an einer meiner Programmiergrundsätze.

Die PHP-Entwickler hatten offensichtlich nur Gutes vor, als sie die Möglichkeit vorsahen, zu instanzierende Klassen auch mit Variablen zu spezifizieren...

Als Folge davon habe ich hier gerade einen Code, in der es zu jedem Kunden eine extra Klasse gibt, etwas das eigentlich auf jeden Fall abstrakt gehalten werden sollte... Antwort des Programmierers: "Naja, funktioniert halt erstmal..."

Manchmal falle ich vom Glauben ab...

Sorry für's Frustablassen.

Als Folge davon habe ich hier gerade einen Code, in der es zu jedem Kunden eine extra Klasse gibt, etwas das eigentlich auf jeden Fall abstrakt gehalten werden sollte... Antwort des Programmierers: "Naja, funktioniert halt erstmal..."

Manchmal falle ich vom Glauben ab...

Was hat das mit Skriptsprachen zu tun? Und der Programmierer hat für jeden Kunden ne eigene Klasse angelegt, oder ne Klasse woraus für jeden Kunden ein Objekt erzeugt wird?

Für jeden Kunden eine Klasse kann man erstmal irgendiwe nachvollziehen. Aber das hätte man mit einer Klasse machen sollen, die alles enthält/enthalten kann und je nach Kunde entspr. gefüllt wird

Was hat das mit Skriptsprachen zu tun?

Skriptsprachen machen es einem immer wieder sehr leicht logische Konzepte aufzubrechen und verleiten einen manchmal regelrecht dazu lieber die Quick&Dirty Lösung umzusetzen, als ein gut geplantes Konzept.

Für jeden Kunden eine Klasse kann man erstmal irgendiwe nachvollziehen.

Kann man? :eek

Dann erkläre mir dochmal, was für einen Sinn es hat, bzw. welcher sinnvolle Anwendungsfall denkbar wäre, wo ich bei 50.000 Kunden auch 50.000 verschiedene Klassen benötige. Das spricht gegen jede Logik, die objektorientierte Programmierung vorgibt.

und jede Class dann noch mal mit Name.Vorname.Geburtsname.class.php nennen und die Suppe kocht über

10.000 Neuanmeldungen => 10.000 neue Classes ... juhuuuu ...

Für dieses Unternehmen will ich als externer Dienstleister Server zur Verfügung stellen !

ich glaube, der threadersteller meint, dass es fuer jede art von kunden eine eigene klasse gibt. sprich: geschäftskunden, privatkunden, ....

das wuerde hingegen sinn machen...

halte php fuer ..naja sagen wir... sch*** , kenn mich deshalb nicht so aus, gibt es

da sowas wie ableiten ?

Dann erkläre mir dochmal, was für einen Sinn es hat, bzw. welcher sinnvolle Anwendungsfall denkbar wäre, wo ich bei 50.000 Kunden auch 50.000 verschiedene Klassen benötige. Das spricht gegen jede Logik, die objektorientierte Programmierung vorgibt.

Ich meinte damit den Ansatz, dass jeder Kunde in einer Klasse steckt (in einer Klasse, nicht einer eigenen). Wie ich dann weiter ausführte ist die Umsetzung der Grundidee dann aber wohl gehörig in die Hose gegangen.

EDIT:

ich glaube, der threadersteller meint, dass es fuer jede art von kunden eine eigene klasse gibt. sprich: geschäftskunden, privatkunden, ....

das wuerde hingegen sinn machen...

Dann würde es mehr Sinn machen, eine Grundklasse Kunden und davon abgeleitet mehrere Kundenklassen.

ich glaube, der threadersteller meint, dass es fuer jede art von kunden eine eigene klasse gibt. sprich: geschäftskunden, privatkunden, ....

das wuerde hingegen sinn machen...

Selbst das ist (meistens) nicht gerade das sauberste Design.

gibt es da sowas wie ableiten ?

Das Vorhandensein einer Klasse erzwingt schon fast die Möglichkeit auch Vererbung verwenden zu können. Ansonsten macht das ganze wenig Sinn.

Ich meinte damit den Ansatz, dass jeder Kunde in einer Klasse steckt (in einer Klasse, nicht einer eigenen).

Dann ist jeder Kunde ein Objekt also eine Instanz einer Klasse und nicht eine Klasse für sich. Das ist ein wichtiger Unterschied, und gehört zu den fundamentalen Dingen, die man an OO verstehen (lernen) muss.

http://www.google.com/search?hl=de&ie=ISO-8859-1&q=tutorial+objektorientierte+programmierung

Dann ist jeder Kunde ein Objekt also eine Instanz einer Klasse und nicht eine Klasse für sich. Das ist ein wichtiger Unterschied, und gehört zu den fundamentalen Dingen, die man an OO verstehen (lernen) muss.

http://www.google.com/search?hl=de&ie=ISO-8859-1&q=tutorial+objektorientierte+programmierung

Was hat das mit Skriptsprachen zu tun? Und der Programmierer hat für jeden Kunden ne eigene Klasse angelegt, oder ne Klasse woraus für jeden Kunden ein Objekt erzeugt wird?

Gut, im Satz danach hab ich das dann wieder nur mit Klasse geschreiben... aber man hätte sich das ja denken können.

aber man hätte sich das ja denken können.

Es gehört für mich auch dazu, wenn man in der IT-Branche arbeitet, dass man sich klar und deutlich ausdrücken kann und in der Lage ist ein Problem präzise zu beschreiben. Damit genau solche Annahmen "Das kann sich ja jeder denken" nicht gemacht werden müssen.

warum rechtfertigst du dich, perdi?

Ich finde eigentlich nicht dass das ein Problem von Skriptsprachen ist. Programmieren muss man nun einmal lernen und auch verstehen. Der selbe Programmierer hätte sicherlich auch in C++ Schwierigkeiten guten Code zu bauen.