Hallo!

WordWrap gibt's als Eigenschaft nicht an VFP TextBox- oder EditBox-Controls! Wenn in Deiner Frage Absatz := Zeilenumbruch bedeutet, dann musst Du an Position 15 ein CHR(13)+CHR(10) einfügen. Das geht natürlich nur durch zusätzliche Programmierung.

Also: Eigene Editbox-Klasse anlegen und beim Abspeichern oder schon beim Verlassen des Controls den Text gemäß Deiner Anforderung nachformatieren. Wenn es schon beim Tippen passieren soll, dann ist etwas mehr Aufwand notwendig.

Ansonsten kommst Du mit einer eigenen Methode aus, die Du aus dem Valid() oder dem LostFocus() heraus aufrufst. im komplizierteren Szenario solltest Du den InteractiveChange-Event() als Aufrufer Deiner Implementation hernehmen.

Viel Spaß bei der Implementation!

Statische Klassen haben den "Vorteil", dass man sie nicht instanziieren muss. Statische Klassen benutzt man daher hauptsächlich, um Funktionen global zur Verfügung zu stellen, die nicht von gekapselten Daten einer Instanz abhängig sind, weil sie alle benötigten Informationen per Parameterübergebe erhalten.

Beispiel: Wenn Du eine spezielle (z.B. Statistik-) Funktionssammlung aufbauen willst, dann liegt es nahe, dass Du Dir eine statische Klasse "Statistik" baust, in der Deine statischen Statistik-Methoden enthalten sind. Nehmen wir mal an, Du brauchst anfangs mal ein ein paar ganz einfache:

AVG(nExpr)  := arithmetisches Mittel
CNT(iList ) := Anzahl
MAX(iList) := Maximum
MIN(iList) := Minimum
NPV(nExpr1, nExpr2 [, nExpr3]) := Varianz das Durchschnitts
STD(iList) := Standardabweichung
SUM(iList) := Summe 
VAR(nExpr) := Varianz (Standardabweichung zum Quadrat)

dann wäre es Quatsch, jedes Mal, wenn Du eine dieser Funktionen benötigst, ein komplettes Objekt zu instanziieren, nur um dann an dieser Klasseninstanz die von Dir gerade benötigte Funktion abzurufen. Die Funktion bekommt alles was sie zum korrekten Funktionieren braucht ja von Dir als Parameter mitgegeben. Dein Funktionsaufruf ändert auch nicht den Status der Klasse(ninstanz) selbst, da die Funktion den errechneten Wert ja nicht in einer Eigenschaft der Klasse (Klassenfeld) abspeichert, sondern "stumpf" an Dich als Aufrufer zurückgibt!

Wenn Du, wie ich, noch die "Prozedurale Programmierung" miterlebt hättest, würde Dir das vielleicht eher einleuchten:-)

Funktionen/Prozeduren waren (und sind) die Verben in einer Programmiersprache. OOP-OBJEKTE als Instanzen einer Klasse kapseln DATEN (Entitäten) UND VERHALTEN (Verben). Hier ein "Klassiker" für eine nicht-statische Klasse:

KLASSE Auto
 ... viele Eigenschaften ...
   Eigenschaft Tankinhalt
 ... noch mehr Eigenschaften...
... viele Methoden ...
   Methode Betanken(Benzinmenge)
      Tankinhalt = Tankinhalt + Benzinmenge
... noch mehr Methoden
KLASSE Auto END

So, da Du nun in Deiner Anwendung viele Autos gleichzeitig brauchst, wirst Du Dir von Deiner Auto-Klasse Instanzen erzeugen, um mit denen dann rumzufahren usw. Wichtig ist, dass jede Autoinstanz einen eigenen (höchst unterschiedlichen) Tankinhalt haben kann, so dass jede Betanken-Methode an jeder einzelnen Instanz ganz unterschiedlich aufgerufen werden muss.

Versucht man dieses Beispiel jetzt auf eine statische Klasse umzubiegen, dann muss man nicht mehr das Objekt Auto betrachten, sondern versuchen, seine Funktionen/Verben zu synthetisieren. Daraus folgt die statische Klasse:

STATIC CLASS AutoPflege
... keine varianten Eigenschaften ...
... viele Methoden ...
   Methode Betanken(IAuto, Benzinmenge)
      IAuto.Tankinhalt = IAuto.Tankinhalt + Benzinmenge
   Methode LuftdruckPrüfen(IAuto, SollwertVorne, SollwertHinten)
      IF IAuto.ReifendruckVorneLinks < SollwertVorne
          RETURN -1
     u.s.w..
   Methode LuftdruckErhöhen(IAutoReifen, Sollwert)
      DO WHILE IAutoReifen.Luftdruck < Sollwert
          IAutoReifen.Luftdruck = IAutoReifen.Luftdruck +1
      ENDDO
... noch mehr Methoden
KLASSE AutoPflege END

Beide Ansätze haben ihre Berechtigung. Der statische Ansatz stellt Dir zuzätzlich die Möglichkeit zur Verfügung, nicht nur Autos, sondern auch Motorräder, Boote und Flugzeuge betanken zu können, wenn Du einen generischen Parametertyp "IBetankbares_Fortbewegungsmittel" in Deiner statischen Methode implementierst.

Lange Rede kurzer Sinn: Statische Methoden sind nichts weiter als die objektorientierte Fortführung von Prozeduren und Funktionen aus der guten alten Zeit (mit den OOP-Vorteile wie Vererbung, und Polymorphie!

Hope that helps ;-)

Nun, erst einmal kann kein Computer (bzw. keine Computersprache) was mit Bruchrechnen anfangen. Soviel schon mal vorab. Mag sein, dass es irgendwo im Internet 'ne Java Klassenbibliothek gibt, mit der Du genau das erschlagen kannst. Ich kenne mich mit Java selbst aber nicht gut genug aus, um Dir in der Richtung weiterhelfen zu können.

Deine Aufgabe hab ich so verstanden, dass es Dir ja nun mal nicht reicht, einfach nur

1:2 + 5:3 = 2,1666666666666666666666666666667 zu codieren (das Resultat wäre schon richtig, allerdings wäre es kein Bruch mehr, sondern eine Fließkommazahl, die Du ja nicht willst. Wenn Dir die Darstellung 5/3 als Zähler-Bruchstrich-Nenner-Schreibweise ausreicht, Du also keinen richtigen (horizontalen) Bruchstrich brauchst, dann bietet sich meiner Meinung an, jeweils den Zähler- und Nenner-Wert paarweise in einem zweidimensionalen Array zu speichern. Damit hättest Du dann schon einmal einen stressfreien Zugriff auf die Wertepaare:

BruchArray[ n, 2] *// mit n := Anzahl der Einzelbrüche im Term mit:

BruchArray[ n, 1] *// Zählerwert von Bruch n

BruchArray[ n, 2] *// Nennerwert von Bruch n

Jetzt nimmst Du die Eingabe auseinander (Dazu schreibst Du Dir einen mickrigen String-Parser, der immer nach Deinem Pseudo-Bruchstrich "/" sucht und links und rechts davon die Zahlen extrahiert und in das Array einträgt. (Die Anzahl der enthaltenen Bruchstriche ("/") ermittelst Du übrigens ganz zu Beginn, um damit Deine Arrays korrekt zu dimensionieren.

Gut, nun fehlt noch der Teil, der die Operatoren ausliest. Dazu solltest Du definieren, welche Operatoren zulässig sind z.B. "+ - * :" - vielleicht auch noch Klammern? Aber Achtung, dann wird so ein kleiner Zeilen-Parser schnell komplizierter!

Jetzt bietet sich an, ein weiteres Operatoren-Array gleich mit zu dimensionieren. Natürlich kann man die gefunden Operatoren auch im BruchArray mit unterbringen, was die Sache aber meiner Meinung nach etwas unleserlicher(unübersichtlicher macht. Ich würde:

OperatorenArray[ n ] *// mit n := Anzahl der Einzelbrüche im Term

einfügen. Dann kannst Du die Arrays wie folgt initialisieren (Achtung: Nachfolgend nur Pseudo-Code! JAVA kann ich nicht wirklich - da musst Du schon selbst versuchen einen fehlerfreien Weg zu finden):

AnzahlBrueche = SucheSlashes( FormelAusdruck ) ;

IF ( AnzahlBrueche > 0 ) {

 BruchArray[ AnzahlBrueche, 2]  = 0 ; 

 OperatorenArray[ AnzahlBrueche ] = "" ;

ELSE

  RETURN "";

}

*// Jetzt den eingegebenen String parsen und die Arrays füllen

Dein Beispiel würde dann wie folgt in den beiden Arrays abgelegt sein:

BruchArray[ 1,1 ] := 1

BruchArray[ 1,2 ] := 2

BruchArray[ 2,1 ] := 5

BruchArray[ 2,2 ] := 3

OperatorenArray[ 1 ] := ""

OperatorenArray[ 2 ] := "+"

AnzahlBrueche := 2

So, und nun kommt das Ding mit dem KGV und dem GGT - aber wie das zu rechnen ist, sollte Dir bekannt sein. Das Schöne an den Arrays ist jetzt, das Du die mit einfachen Schleifen durchlaufen kannst, um ggf. alle möglichen Sonderfälle zu finden und zu normalisieren. Wie z.B. in Deinem Beispiel "5/3", was bekanntlich "nur" ein unechter Bruch ist, da der Nennen größer als der Zähler ist (5/3 == 1 + 2/3) .

Unter http://de.wikipedia.org/wiki/Bruchrechnung findest Du alles, was Du brauchst!

Du solltest auf jeden Fall zuerst alle Sonderformen wie, Stamm- und Zweigbrüche, sowie gemeine, echte, unechte und Schein-Brüche in ihre Normalform umrechnen und erst dann das KGV ermitteln.

Na, ich bin gespannt, ob Dein Bruchrechenprogramm mal funktionieren wird, oder immer nur "zu Bruch geht" ;-)

Viel Erfolg!

HI, also ich kapier' rein gar Nix

Wenn Du keinen guten Grund hast (z.B. Dein Arbeitgeber verlangt es von Dir), dann vergiss ASP.NET ganz schnell. ASP.NET wird aussterben! Warum bleibst Du nicht bei PHP - damit lässt sich ganz wunderbar objektorientierte WEB-Applikationen programmieren!

Vererbung ist eine der Hauptpfeiler der OOP. Um Vererbung gewinnbringend einsetzen zu können, MUSS man wissen, was man tunlichst NICHT mittels Vererbung implementieren sollte! Aussagen wie: "jedes Quellcodefragment in eine eigene Klasse" ist mir zu allgemein und verwirrt einen OOP-Einsteiger mehr, als es ihm nützt.

Basis der OOP sind und bleiben Objekte, die aus Klassen (den Bauplänen dieser Objekte) instantiiert werden. In einem normalen deutschen Satz wäre Dein "User" eine Instanz Deiner (Basis-)Klasse "Spieler" und Dein "CurrentUser" die gerade aktive Instanz aller User-Objekte (also der Spieler, der "eingelogged" und gerade am Zug ist). Was Du erst einmal technisch NICHT durcheinander bringen darfst sind die Namen Deiner Instanz-Variablen (Objektnamen) und die Namen Deiner Klassen. Ich empfehle Dir dort für eine gewisse Deckung zu sorgen.

Ausgangspunkt Deiner KLASSEN-Hierarchie könnte die Superklasse "User" sein. Davon könntest Du dann Deine "Spieler" ableiten. Instantiierst Du später einen Spieler, so bieten sich dann Variablennamen wie "oSpieler1" bis oSpielern" an. Das führende "o" ist dann immer ein Hinweis auf ein konkretes Objekt (eine Klassen-INSTANZ). Und da jede Instanz eine unverwechselbare Identität besitzt, kann diese durch ein hochzählbares Postfix "_x" sichergestellt werden. Der Vorteil dieser Nomenklatur ist, dass Du sofort siehst, aus welcher Klasse welches Objekt instanziiert wurde.

Im nächsten Schritt gilt es zu erkennen, welche Dinge in welcher Klasse implementiert werden sollten! Dies ist die hohe KUNST guten OOP-Designs! Es gibt zwei Typen von OOP-Sprachen: der eine Typ lässt Mehrfachvererbung zu, der andere nicht! Ich gehe davon aus, dass Du in einer Sprache OHNE Mehrfachvererbungsmöglichkeit programmierst, bzw. diese nicht nutzen wirst (wäre für Deinen Einsatzzweck auch gar nicht von Vorteil!). In diesen Fällen gilt: Durch Vererbung in eine abgeleitete Klasse findet eine SPEZIALISIERUNG statt. Nehmen wir mal Deine oben genannten Namen, dann ist das schön zu sehen: User ist Deine allgemeine "Ancestor-class" (Vorfahr-Klasse), wohingegen UserWar, UserEconomy usw. Deine spezialisierten Ableitungen wären, die zwar auch alle Eigenschaften und Fähigkeiten Deiner User Klasse besitzen, diese aber um spezifischen Implementationen erweitern/verfeinern/spezialisieren.

Weiter sehr wichtig ist: Du musst den Unterschied zwischen Erscheinung und Verhalten bei Objekten begreifen. Alle Klassen-Eigenschaften (statischen Felder) definieren das "Aussehen", die Erscheinung (Object-Appearance), die Methoden einer Klasse implementieren das Verhalten (Object-Behaviour). Durch Ableitung von einer Eltern-Klasse in eine Descendant-Class (Nachfahre-Klasse) werden ja bekanntlich alle Eltern-Eigenschaften und Methoden mit weitervererbt. Wenn Du dabei erkennst, dass bestimmte Eigenschaften in fast all Deinen Ableitungen nicht gebraucht werden, oder dass Du Funktionalitäten der Eltern in den abgeleiteten Kindern immer wieder überschreibst, dann ist das ein sicheres Zeichen dafür, dass diese Eigenschaften/Methoden zu früh in der Vererbungshierarchie implementiert wurden, bzw. gar nicht in die jeweilige Klasse gehören!

Ohne die ganze Sache jetzt zu theoretisch werden zu lassen (OOP-Grundlagen sollte man sich schon durch entsprechende Lektüre an anderer Stelle ausreichend zu Gemüte führen:-), sprich: ohne hier noch detailliert über Interfaces und Polimorphismus zu sprechen, lass uns mal kurz auf Dein konkretes Projekt zurück kommen.

Hier (m)ein Vorschlag für einen ersten Klassenhierarchieentwurf:

Person (abstrakte Basisklasse) wir abgeleitet in:

User (immer noch - wenigstens teilweise - abstrakte Superklasse) wir abgeleitet in:

Admin | Moderator | Spieler | usw. (ab hier konkrete Implementationen)

So, wenn Du später dann einen Spieler brauchst kannst Du ihn dann wie folgt instatiieren (Pseudo-Code!)

oUser_1 = New Spieler("Franz Müller")

MyGameEngine.Spieler.Add( oUser_1, SpielerID)

oCurrentUser = oUser_1

Damit sind aber eine Deiner drängendsten Fragen noch nicht beantwortet, nämlich: "Wie verpacke ich die Aspekte War, Economy und Politic"? Deine Namensgebung oben suggeriert, dass es in Deinem Modell User geben soll, die spezialisiert auf Krieg ODER Wirtschaft ODER Politik sind, nicht aber auf Kombinationen davon. Dies scheint aber der Realität zu widersprechen. Hier gibt es eine gute Lösung, nämlich die Einführung von ROLLEN. Die kannst Du als eigenständige Vererbungshierarchie aufbauen und als Interface z.B. mit dem Namen IRoles einführen. Eine Rollen(sammlung) sind dann dynamisch zuladbare Objekte, die spezifisches Verhalten und Aussehen jedem Spieler zur Laufzeit zufügen. In Deiner Standard-User Implementation kannst Du dann über das iRoles-Interface die jeweilig aktiven Rollen abfragen und über diese dann spezielle Funktionen triggern und/oder Stati speichern und abfragen.

Na? Alles klar soweit? ;-)

Hallo Tomita!

Ich befürchte, dass Du gleich etwas viel für Deinen OOP Einstieg vorgenommen hast! OOP ist an und für sich schon ein recht komplexes und anspruchsvolles Paradigma. Dieses dann gleich an einem datengetriebenen selbst erstellten CMS auszuprobieren schreit nach Scheiterm! Nix für Ungut, Du solltest Dir auf jeden Fall erst einmal ein grundsätzliches Verständnis von OOP (in Zusammenhang mit PHP) aneignen. Danach ein paar beispiele downloaden und an ihnen studieren, wie was in Klassen und auf Dateien aufgeteilt wird. Kenntnisse von Design-Patterns wären auch nicht schlecht.

Grundsätzlich solltest Du ein Mehrschichtenmodell (im Web mit zentraler Datenhaltung geht es gar nicht anders) anstreben. Die drei Hauptschichten sind Datenhaltung (also Backend - oder wie man heute sagt: das "Modell"), die mittlere Geschäftsregelschicht (früher der Business-Layer, wird heute der "Controller" genannt) und zuletzt die grafische Benutzerschnittstelle (früher GUI für Graphical User Interface, wird heute "View" genannt).

Danach solltest Du eine Anforderungsanalyse machen: Was gehört in welche Schicht. Diese Anforderungen werden dann immer feiner ausformuliert, bis Du eine eigenständige Klasse dafür erzeugen kannst: so wenig Funktionalitäten mit Daten in einer Klasse kapseln (sonst entsteht schnell das "alleskönnende" Schweizer Armeemesser). Je weniger Funktionalität eine Klasse besitzt, desto besser ist sie später wiederzuverwenden! Da sind wir dann beim zweiten großen Thema der OOP: Wiederverwendbarkeit! Dein oben beschreibenes Vorgehen berücksichtigt solche Aspekte noch nicht. Wiederverwendung ist die Grundlage für eine saubere Aufteilung der Klassen auf Bibliotheken. Dies wiederum ist die Grundlage für den Aufbau entsprechend nützlicher Frameworks - und ohne etwas passendes in der Richtung würde ich Dein Projekt nicht angehen! Zu den bisherigen Betrachtungen kommen dann noch weitere Aspekte (der AOP zum Beispiel), die man vielleicht zuerst und dann gleich generisch implementieren möchte, als da wären: Anwenderverwaltung, Rollen, Sicherheit, Zugriffsrechte, Standard- Layouts und Verhalten. Es gibt jede Menge zu beachten. Du solltest als Einsteiger erst einmal davon ausgehen, dass OOP vergleichgbar ist mit einer Legostein-Presse. Du willst Dir aus vielen tollen Legosteinen ein wunderschönes Märchenschloss bauen. Du hast aber derzeit nur die Presse für Legosteine und weißt ungefähr, wie Du sie bedienen musst. Du hast aber noch keine Steine UND noch keinen Bauplan von Deinem Haus. Diese Dinge musst Du Dir erst einmal aufbauen (oder downloaden:-)

Ich hoffe, Dir etwas weitergeholfen zu haben.

Hallo Tomita,

also in dem Bücherschrank neben meinem Arbeitsplatz stehen folgende Bücher zu PHP: "PHP and MySQL Web Development" ISBN: 0-672-32916-6 "PHP Functions" ISBN: 0-7357-0970-X "PHP-Sicherheit" ISBN: 978-3-89864-535-5 "PHP 5 Kochbuch" ISBN: 3-89721-409-1 "Webdatenbank-Applikationen mit PHP & MySQL" ISBN: 3-89721-176-9 "Wicked Cool PHP" ISBN: 978-1-59327-173-2 "AJAX und PHP" ISBN: 3-446-40920-3 Das heisst zwar nicht, dass ich schon alle gelesen habe, aber wenn Du die hast, dass kannst Du auf jeden Fall das Meiste/Wichtigste jederzeit daheim "offline" (und selbst bei Kerzenschein;-) nachlesen.

OOP ist ja bekanntlich ein Programmierkonzept! Ich würde hier generell zwischen folgenden Ausprägungen unterscheiden: Denen mit Möglichkeit der Mehrfach-Vererbung und denen, wo dies nicht möglich ist (Einfach-Vererbung) Die Sprachen sollte man danach zusätzlich auf jeden Fall noch in weiter in "streng typisierende" und nicht streng typisierte" Sprachen unterscheiden; last but not least dann auch zwischen Kompiler- und Interpreter- Sprachen. Alles in allem Ist das Entwicklungskonzept mit Objekt orientiertem Ansatz in vielen Büchern allgemein beschreiben worden. Ich ziehe praxisnahe OOP vor (sprich: "Learning by Doing"), jedoch kann ich ein Buch über OOP vorbehaltlos empfehlen: "Object-Oriented Software Construction (Book/CD-ROM) (2nd Edition) [Paperback]" von Bertrand Meyer. Folge diesem Link "http://www.amazon.com/Object-Oriented-Software-Construction-Book-CD-ROM/dp/0136291554" und klick einfach mal auf "look inside" dort. Der Mann ist der Vater der OOP Sprache Eiffel. Das ist OOP-Sprache mit Mehrfach-Vererbung, strenger Typisierung und dem sogenannten Design-by-Contract Paradigma, das ich persönlich über alles schätze, trotzdem ich selbst kein Eiffel-Programmierer bin. Man muss die Grundbausteine von OOP verstanden haben, um deren Vorzüge voll nutzen zu können! Deswegen gehört ein allgemein anerkanntes Standardwerk zur OOP auf den Schreibtisch eines jeden ernsthaften OOP-Programmierers - natürlich gelesen :-) !! Natürlich kannst Du Dir, wie ich es getan habe, OOP-Programmierleitfäden auf Basis von PHP zulegen - allerdings erst, wenn Du das Buch von Bertrand Meyer durchgelesen und verstanden hast. :-) PS: Wenn Dir das nötige Kleingeld für das Werk fehlt, kann ich Dir noch folgenden Spar-Tipp geben: Das Buch kannst Du Dir in der Regel über die Leihbücherei am Ort (Stichwort: "Fernleihe") für zwei bis drei Euros besorgen lassen. Da die enthaltene CD nicht nur die komplette Eiffel-Entwicklungsumgebung sondern auch noch einmal das ganze Buch kapitelweise als PDF-Dateisammlung (nicht kopiergeschützt) enthält, sind das gut angelegte Euros :-)

Gutes Gelingen!

Die häufigsten Ursachen sind: 1.) Ladegerät defekt -> Akku leer. Laptop läuft gar nicht mehr. 2.) Akku defekt, aber Ladegerät funktioniert. -> Laptop läuft dann nur noch, wenn er am Stromnetz angeschlossen ist.

Bei Dir sieht es danach aus, als wäre Dein Akku fertig (kaputt). Das ist normal, denn JEDER Akku hat nur eine begrenzte! Anzahl von Ladezyklen (das sind zwar einige tausend, aber wenn Du Deinen Akku nie aus Deinem Laptop raus nimmst, wenn Du mit ihm "stationär" arbeitest (stationär = am Stromnetz via Ladegerät/Kabel angeschlossen), dann zählt jedes Ein/ausschalten als ein kompletter Ladezyklus. Und damit ist Dein Akku so ungefähr nach ein bis zwei Jahren kaputt. Je nachdem wie qualitativ hochwertig das Ding war. Billig-Akkus (aus vergangenen Zeiten) waren da schon nach einem Jahr nicht mehr ladbar. Wie gesagt, das Ganze hat nichts mit dem sogenannten "Memory-Effekt" zu tun, der früher gern bei bestimmten Akku-Typen aufgetreten ist, sondern ist ganz einfach eine Verschleißerscheinung, die jeden Akku früher oder später umbringt! Mein Rat: neuen Akku beschaffen und den dann wirklich nur kurz vor Gebrauch einsetzen und laden. Wo eine Steckdose ist IMMER NUR mit Ladegerät-Strom arbeiten, sprich: Akku RAUS aus Deinem Notebook wo immer es geht!

Der Rest meines ersten Versuchs wurde nach dem Link verschluckt. Daher hier der Rest:-)

 

Natürlich kanst Du Polymorphie auch auf Deine Art anwenden; wichtig ist dann nur, dass man dann von einem gemeinsamen ABSTRAKTEN Basistyp (der das Interface seiner Ableitungen definiert) ausgehend ableitet. Allerdings verschenkst Du Dir damit natürlich die Freiheit "schlankere" Klassen für Deine Funktions-Implementierungen zu nutzen.   PROXY (Platzhalter) ist nach meinem derzeitigen Verständnis komplett verkehrt. Aus der Sicht des "Weiterreichens der Aufgaben", inklusive der dadurch herbeigeführten Spezialisierung (aus Sicht der Programmdynamik/Laufzeitverhalten), käme für mich das "STRATEGIE-Pattern" in Frage. DECORATOR (Verzierung) trifft es ebenfalls nicht sonderlich gut! Ein Decorator macht dem nutzenden Client einfach transparent "ein X für ein U vor" :-) Der Client spricht das Interface der Typinstanz X an (das ist aber die Dekorator-Instanz), die Aufrufe werden entsprechend ge-CAST()-et an den Implementationstyp U weitergegeben.  Weitere Fragen, die sich mir stellen, sind: Wenn jemand Deinem Logger die Nachricht LOG() schickt, machst Du dann ein Broadcast auf alle Mitglieder Deiner Sammlung, sprich *kaskadierst* Du an _alle_, oder hat Deine Logger::Log() Methode eine Signatur (Parameter), über die man *gezielt*einzelne* Spezialisierungen ansprechen _muss_? Dann nämlich IST es definitiv ein Strategie-Pattern, ansonsten würde ich nicht verzweifelt nach einem Pattern weiterkramen:-) Dann ist Deine Konstruktion einfach eine Klasse, die eine SAMMLUNG von Funktions-Delegaten besitzt, die (vielleicht sogar dynamisch?) geladen werden können, um abstrakte Funktionen des Hosts (der gleichzeitig auch noch "Anchester-Class" in der Vererbungshierarchie ist) zu implementieren. Wenn ich das hier so nochmal lese: Es _schreit_ nach der Anwendung eines INTERFACE für Deine Delegaten!   Was Du in Deinem Programm machst, will ich absolut nicht schmälern, aber machmal "verschlimmbessert" man die Dinge nur mit all zu vielen theoretischen Verallgemeinerungen (was pattern nun mal sind! Schau mal, jetzt hast Du und ich so viel darüber geschrieben, aber wirklich schlauer sind wir nicht, oder? ;-)    FF - Viel Vergnügen! Und Erfolg!   PS: php ist 'ne echt coole Sache!

 

Hallo! Vielleicht kannst Du es noch etwas genauer beschreiben - ich kenne mich zwar in PHP nicht gut aus, aber OOP ist ja grundsätzlich einmal nicht zwingend  sprachabhängig. :-)   Du drückst Dich allerdings auch ein wenig unpräziese aus (mag aber auch an der fortgeschrittenen Stunde - und an mir liegen :-) Du schreibst: "Es gibt eine übergeordnete Logger-Klasse diese stellt ein Interface zur Verfügung" Wie wird dieses "Interface" zur Verfügung gestellt?    Was ich nach dem Lesen Deiner Zeilen verstanden habe sieht wie folgt aus:   1.) Du hast eine Klasse, die ein öffentliches Interface hat. Dieses besteht aus mehreren Methoden (und ggf auch Eigenschaften). Diese Klasse ist keineswegs abstrakt, sondern konkret implementiert, um daraus Deinen HOST (Logger) zu instantiieren. Dessen prominentestes Member ist seine öffentliche LOG() Methode. Gleichzeitig leitest Du jetzt aus dieser Klasse weitere ab, um in denen die Basis-Funktionalität zu erweitern, bzw. zu überschreiben >> aus Logger wird dadurch dann Dein Email-Logger, Dein Filesystem-Logger usw.    Dann schreibst Du: "Die (Sub-)Logger sowie die übergeordnete Klasse verwenden das gleiche Interface". Frage: Wie "VERWENDEN" sie es? Durch Vererbung, oder duch IMPLEMENTIERUNG? Das ist hier die alles entscheidende Kernfrage!! Dein Beispiel "schreit" geradezu nach der Definition und Implementation eines INTERFACE! Deine "(Sub-)Logger", wie Du sie nennst, müssen nämlich gar nicht vom Basis-Logger abgeleitet werden, solange sie nur das generische Interface  z.B. "ILogger" implementieren. Richtig? Ein Interface DEKLARIERT nur die Methoden und deren Signaturen, die dann von allen Klassen, die dieses INTERFACE IMPLEMENTIEREN, mit konkretem Verhalten (sprich Code) ausgefüllt werden müssen! Was absolut okay ist, denn Du musst ja auch in allen Deinen Ableitungen die entsprechenden Methoden überschreiben. Eben die gehören dann in Dein Interface! Damit müssen Deine "Sub-Logger" gar nicht mehr vom "großen Papa" abstammen und können somit von viel schlankeren Typen abgeleitet worden sein! Hauptsache, Dein HOST kann sich darauf verlassen, dass sich seine DELEGATEN korrekt ansprechen lassen. Schau mal hier nach>> http://www.phpbar.de/w/Interface

Sei lieber vorsichtíg! Wenn wírklich eine (auch kleine!) Platte mit Nägeln an Deinem Stativ dran sein sollte, dann hast Du eines der sehr seltenen Fakir-Stative zuhause! Die Kamera wird in diesemFall immer DIREKT AM FAKIR angeschlossen!!!

Ich selbst mag zwar keine Tiere totschießen, weiß aber, dass Wildpflege hierzulande absolut notwendig ist!

Also: ich hab Deine Frage nur deshalb gelesen, weil ich gerdae ein Foto/Film-Stativ geerbt habe, bei dem (blöderweise!) so ein kleiner Eindatz fehlt, an dem jeweils die Foto/Filmkamera festgeschraubt wird. Das Stativ selbst hat dann so einen bequemen Klemmhebelverschluss, mit dessen Hilfe die diversen Kameras blitzschnell aufgeklemmt werden können.

So weit so gut, Wenn aber jemand diesen Einsatz nicht mehr hat (wie ich zum Beispiel - blöderweise:-) und der Hersteller für das entsprechende Modell keine Ersatzteile mehr liefert (weil es den Herrsteller z.B. gar nicht mehr gibt!), dann müsstest Du so ein praktisches Stativ für nen "Appel & nen Ei" bekommen!

Falls ich - als Fotograf - den Einsatz nicht mehr bekommen kann, überlasse ich Dir das ganze Ding gern für weit unter 10 Euro!

In diesem Sinne!
 Waidmann's heil ;-)

Du fängst an, zusammen mit ihr abzunehmen!! Ich glaube nicht, dass dass DU unheimlich schlank bist! Also, fangt BEIDE an abzunehmen!

Die RICHTIGE Antwort: Was willst Du für einen Status bei eBay? Was willst Du dort sein? 1.) Willst Du "Der SUPER" Verkäufer sein? (Mit Millionen Verkäufen): Nimm alles einfach zurück - Geld spiel keine Rolle - alles zu Deinen Lasten/Kosten! 2.) Willst Du "Der VERSTÄNDNISVOLLE" (privat)Verkäufer sein?: Nimm Ware zurück und verlange die Rückzahlung der eBay-Gebühren. 3.) Willst Du "Der HARTE" eBayer sein?: verlange die vollständige Bezahlung (wenn nötig durch Deinen Anwalt!) 4.) Willst Du so sein "Wie Du und Ich"? Dann besorg Dir die Telefonnummer Deines Käufers (oder gib ihm Deine), damit ihr Euer Problem ein für alle Mal aus der Welt schaffen könnt!

FF (viel vergnügen;-)

Hallo Patrick! Ich bin mir ziemlich sicher, dass niemand hier Deine Frage auch nur ansatzweise WIRKLICH verstehen wird!

Ich weiß 100%-tig, dass Deutsch 'ne echt besch... schwere Sprache ist! Deshalb bin ich heute froh, dass ich die seit meiner Geburt unfreiwillig lernen musste ;-) Ganz egal was genau Du meinst:

Es gibt ein super tolles JAVA-Tool (Hilfsprogramm), dass Du 30 Tage lang als Vollversion kostenlos testen kannst, dass unglaublich viele Refactorings (Umbauten/Neugestaltungen) für JAVA Entwickler beherrscht! Vielleicht hilft Dir dieser Link weiter:

http://www.jetbrains.com/idea/

Die Seite ist komplett auf Englisch - aber vielleicht ist Dir das ja sogar lieber!

"VFD" -> Viel Freude Damit