nicht angemeldet dedlfix
T-Rex
Matthias Apsel
Matthias Apsel
T-Rex
Gunnar Bittersmann
Matthias Apsel
MudGuard
Matti Mäkitalo
dedlfix
Hi,
warum wird in fast jedem Buch, Tutorial usw. wo das Thema OOP behandelt wird über Autos gesprochen. Ein Auto hat Türen, kann nach vorne fahren, Motor einschalten, ausschalten...
Ist das das "Hello World" für OOP?
Ist noch keiner auf die Idee gekommen, ein sinnvolleres Beispiel zu nehmen?
MfG Naps
Hi,
warum wird in fast jedem Buch, Tutorial usw. wo das Thema OOP behandelt wird über Autos gesprochen.
Weil es sich gut eignet, um Vererbung zu veranschaulichen.
Ein Auto hat im Wesentlichen erst mal einen Motor/Antrieb, Räder und Steuerung.
„Alles andere” sind dann optionale Extras, die aus einem Auto zum Beispiel einen Bus, einen LKW, … machen – die „erben” von der Basisklasse „Auto”, und fügen dann weitere Eigenschaften und Spezialisierungen hinzu.
Ist noch keiner auf die Idee gekommen, ein sinnvolleres Beispiel zu nehmen?
Was hättest du anzubieten?
MfG ChrisB
Ist noch keiner auf die Idee gekommen, ein sinnvolleres Beispiel zu nehmen?
Was hättest du anzubieten?
Vielleicht eine Sache die oft benötigt wird aber aus dem "Web-Bereich". Ich merke persönlich immer, dass ich dazu neige, eine Klasse als Container für Funktionen zu verwenden. Wahrscheinlich weil ich noch zu wenig Erfahrung in dem Bereich habe. Und da fällt es mir schwer eine Relation von dem Auto-Beispiel zu einer Problemstellung im Programmieraltag herzustellen.
MfG Naps
Hallo,
Vielleicht eine Sache die oft benötigt wird aber aus dem "Web-Bereich".
Da würde mir nicht viel einfallen, was verschiedene serverseitige und clientseitige Programmiersprachen gemeinsam haben. Datei oder Datensatz vielleicht? Nutzer? Request-Objekt? Model, View, Controller? Netzwerk-Streams? Das ist alles zu konkret, da ist das Auto schon besser.
Ich merke persönlich immer, dass ich dazu neige, eine Klasse als Container für Funktionen zu verwenden.
Eine Klasse *ist* ein Container für Funktionen, die auf einem abgeschlossenen Set an Daten operieren und ggf. eine Schnittstelle zum Zugriff und zur Manipulation dieser Daten anbieten.
Man kann es auch anders sehen, aber das ist gewiss nicht falsch.
Mathias
Hi,
Ich merke persönlich immer, dass ich dazu neige, eine Klasse als Container für Funktionen zu verwenden.
Eine Klasse *ist* ein Container für Funktionen, die auf einem abgeschlossenen Set an Daten operieren und ggf. eine Schnittstelle zum Zugriff und zur Manipulation dieser Daten anbieten.
Man kann es auch anders sehen, aber das ist gewiss nicht falsch.
Zunächst: die Sichtweise ist nicht falsch.
Das Problem ist aber, dass die entstehenden Klassen nicht notwendigerweise sinnzusammenhängend sind. Einfach einen Haufen an Funktionen in eine Klasse reinzuwerfen hilft nicht, das Problem mit OOP besser zu strukturieren.
Daher ist es meist einfacher, vom Objektbegriff (also der Fachlichkeit) auszugehen und daraus die Interaktionen (wie nutze ich meine Objekte) abzuleiten.
Bis die Tage,
Matti
Hallo,
Das Problem ist aber, dass die entstehenden Klassen nicht notwendigerweise sinnzusammenhängend sind. Einfach einen Haufen an Funktionen in eine Klasse reinzuwerfen hilft nicht, das Problem mit OOP besser zu strukturieren.
Wenn ich bloß ein paar Funktionen gruppieren will und es kein abgeschlossenes Objekt mit internem State gibt, dem ich Nachrichten sende, brauche ich natürlich nicht unbedingt eine Klasse. Je nach Sprache gibt es andere Gruppierungtechniken, z.B. ein Namensraum oder ein Module.
Du hast Recht, das Strukturieren in Objekte geht viel weiter. Um Code sinnvoll in Klassen zu strukturieren, muss ich über Wiederverwendbarkeit, Datensichtbarkeit/Schnittstellen und Separation of Concerns nachdenken. Dazu brauche ich ggf. weitere Patterns, die mir helfen (z.B. Model-View-Controller).
Mathias
Wenn ich bloß ein paar Funktionen gruppieren will und es kein abgeschlossenes Objekt mit internem State gibt, dem ich Nachrichten sende, brauche ich natürlich nicht unbedingt eine Klasse.
Wobei: Es gibt durchaus Methodenobjekte als Refactoring-Pattern. Ziemlich praktisch, wie ich finde. Solche Objekte ergänzen freilich eher klassische Objekte.
Mathias
Tach!
Wenn ich bloß ein paar Funktionen gruppieren will und es kein abgeschlossenes Objekt mit internem State gibt, dem ich Nachrichten sende, brauche ich natürlich nicht unbedingt eine Klasse.
Wobei: Es gibt durchaus Methodenobjekte als Refactoring-Pattern. Ziemlich praktisch, wie ich finde. Solche Objekte ergänzen freilich eher klassische Objekte.
Wobei man sich da vorher fragen sollte, warum die Methode so groß ist und ob da nicht sowieso wegen der Single Responsibility eine eigene Klasse (oder mehrere) zu bilden wäre. Solche Auslagerungsklassen scheinen mir das Problem nur auszulagern, anstatt es richtig zu lösen.
(Und wie 1UnitedPower richtig bemerkte sind einige Pattern eher Anti-Pattern als empfehlenswert.)
dedlfix.
Wobei man sich da vorher fragen sollte, warum die Methode so groß ist und ob da nicht sowieso wegen der Single Responsibility eine eigene Klasse (oder mehrere) zu bilden wäre.
Ja, richtig, sollte man.
Solche Auslagerungsklassen scheinen mir das Problem nur auszulagern, anstatt es richtig zu lösen.
Es ist ein mögliches Refactoring-Pattern unter vielen und ergänzt wie gesagt das Anlegen von Klassen/Objekten im herkömmlichen Sinne. Es ist kein Architektur-Pattern, sondern eine Vorgehensweise, um spezifischen Code zu extrahieren, ohne ihm eine starke Bedeutung im Objektmodell zuzuweisen.
Nicht alles lässt sich streng nach dem OOP-Standardmodell strukturieren, und das Standardmodell alleine verhindert keine riesige Klassen mit langen Methoden. Methodenklassen widersprechen sogar klassischer OOP; hier handelt es sich eher um eine komplexe Funktion im Sinne funktionaler Programmierung (Eingabewerte werden auf Ausgabewerte abgebildet, keine Nebenwirkungen).
Grüße,
Mathias
Tach!
warum wird in fast jedem Buch, Tutorial usw. wo das Thema OOP behandelt wird über Autos gesprochen. Ein Auto hat Türen, kann nach vorne fahren, Motor einschalten, ausschalten...
Ist das das "Hello World" für OOP?
Es ist zumindest ein Einstieg, um Laien an das Thema heranzuführen und um ihnen einen Vergleich mit einem bekannten Thema zu geben.
Ist noch keiner auf die Idee gekommen, ein sinnvolleres Beispiel zu nehmen?
Dummerweise sind Real-World-Beispiele wenig geeignet, konkrete Probleme beim Programmieren zu besprechen. Man sollte sich also schnell wieder von solchen Vergleichen lösen. Man programmiert kein ganzes Auto oder ein Restaurant, man hat vielmehr irgendwelche kleinen Details zu beachten und Lösungen für programmiertechnische Aufgabenstellungen zu finden. Wenn man anhand dessen die OOP erklären will, muss man erst einmal die Tätigkeiten beim Programmieren an sich erklären.
Nun kommt es auch noch drauf an, was derjenige OOP-Lehrling bereits kennt. Hat er schon erste oder weitergehende Erfahrungen im prozeduralen Programmieren gesammelt? Datenbankenabfragen vielleicht? Dann könnte man die OOP anhand von DBMS-Abstraktionen erklären. Es gibt ein paar Grundfunktionalitäten und es gibt DBMS-spezifische Dinge. Das sollte für das Erklären von Vererbung und abstrakten Methoden reichen. Um Szenarien für Interfaces kann man das sicher auch ausbauen.
Wenn er nun aber ohne weitere Kenntnisse gleich in das Programmieren mit einer OOP-Sprache einsteigt, dann hat man wenig, auf dem man aufbauen könnte. Die Frage ist dann allerdings, ob man gleich das volle OOP-Programm fährt oder erstmal nur notwendigerweise eine Klasse als Container nimmt und die Programmier-Basics mit einer Geradeaus-Programmierung in der main-Methode erklärt. So fangen zumindest einige Window-Programmierbücher an: mit einer Konsolenanwendung. OOP kommt später. Von Geradeaus-Programmen auf eventgesteuerte GUI-Anwendungen zu kommen ist auch nochmal eine ziemliche Umstellung. Denn dann hat man nicht mehr die generelle Kontrolle über das Programm, das gelegentlich zum Ausführen einer Systemfunktion abtaucht, sondern das läuft quasi die meiste Zeit unter Wasser ab und taucht nur mal für ein paar Eventhandler auf. Und dabei bleibt man ja nicht stehen. Eventhandler sind schlecht test- und austauschbar und zu sehr an die GUI-Objekte gekoppelt. MVVM (Model-View-Viewmodel) steht dann auf dem Plan. Das sind nun keine Dinge mehr, denen ein Autofahrer begegnet. Das sind Probleme die beim Programmieren entstehen, sobald die Projekte größer werden und man dafür überschau- und wartbare Lösungen braucht.
dedlfix.
Auto ist eines der ersten Wörter die man lernt. Autos sieht man jeden Tag. Es ist dementsprechend ein Begriff dem wirklich jedes Kind bekannt ist und unter dem sich jeder etwas vorstellen kann.
Da jeder bei "der Sendung mit der Maus" bestimmt mal ein Autowerk von innen gesehen hat, kann sich jeder auch so grob vorstellen wie ein Auto zusammen gebaut wird. Dass es zudem verschiedene Autoausstattungen bzw. Farben und Formen gibt sieht ja auch jeder auf der Strasse. Somit ist das Auto das Ideale Objekt um Vererbung und Eigenschaften zu "realisieren".
Mir fällt nichts besseres ein. Vielleicht Dinos? Oder Leberwurst? Oder selbstgestrickte Pullover?
Achja die Internetaddressierung erkläre ich auch sehr gerne mit Häusern und Hausnummern. So konnte ich auch bei Laien ein zufriedenes nicken und ein "ah so ist das" entlocken.
Gruß
OdF (Objekt des Forums)
T-Rex
Om nah hoo pez nyeetz, T-Rex!
Mir fällt nichts besseres ein. Vielleicht Dinos? Oder Leberwurst? Oder selbstgestrickte Pullover?
Es gibt viele Beispiele, den Unterschied zwischen Klasse und Objekt resp. Entitätsmenge und Entity zu veranschaulichen. Aber wenn die Methoden ins Spiel kommen sollen, gibts in den aktuellen Schulbüchern nicht mehr so viel.
Matthias
Auto ist eines der ersten Wörter die man lernt. Autos sieht man jeden Tag. Es ist dementsprechend ein Begriff dem wirklich jedes Kind bekannt ist und unter dem sich jeder etwas vorstellen kann.
Das passt. Es ist tatsächlich so, dass man Eigenschaften und Methoden so klasse erklären kann. Auch was eine Klasse ist und was ein abgeleitetes Objekt ist.
Achja die Internetaddressierung erkläre ich auch sehr gerne mit Häusern und Hausnummern. So konnte ich auch bei Laien ein zufriedenes nicken und ein "ah so ist das" entlocken.
Da nahm ich seinerzeit Telefonnummern.
Übrigens für die "Ports" dann ein riesiges Postamt mit Schaltern, an denen jeweils genau ein Dienst angeboten wurde oder wo man - wie sinntragend - Pakete abgeben kann. Und wo einen der Beamte - wenn man sich am falschen Schalter falsch angestellt hat - nur blöd anschaut und vielleicht noch sagt "ich verstehe nicht, was Sie wollen". Das kapiert auch jeder.
Ich mache seit Jahren Schulungen im IT-Bereich.
Om nah hoo pez nyeetz, Jörg Reinholz!
Übrigens für die "Ports" dann ein riesiges Postamt mit Schaltern, an denen jeweils genau ein Dienst angeboten wurde oder wo man - wie sinntragend - Pakete abgeben kann. Und wo einen der Beamte - wenn man sich am falschen Schalter falsch angestellt hat - nur blöd anschaut und vielleicht noch sagt "ich verstehe nicht, was Sie wollen". Das kapiert auch jeder.
Wenn ichs bis dahin nicht vergessen habe, werde ich dich zitieren.
Matthias
Nichts für ungut,
Da nahm ich seinerzeit Telefonnummern.
Übrigens für die "Ports" dann ein riesiges Postamt mit Schaltern, an denen jeweils genau ein Dienst angeboten wurde oder wo man - wie sinntragend - Pakete abgeben kann. Und wo einen der Beamte - wenn man sich am falschen Schalter falsch angestellt hat - nur blöd anschaut und vielleicht noch sagt "ich verstehe nicht, was Sie wollen". Das kapiert auch jeder.Ich mache seit Jahren Schulungen im IT-Bereich.
aber wer nimmt an IT-Schulungen teil und gibt sich dann mit solch banalen Analogien zufrieden? Wenn das alles ist, was die Leute nach einer IT-Schulung über Ports wissen, dann Prost Mahlzeit... zum Lachen finde ich das nicht. Für Kinder und desinteressierte Laien hingegen mag's ausreichen.
Humorlos wie immer
Eine Metapher ist nur so gut wie das Umfeld in der sie benutzt wird. Ich denke wohl kaum das Jörg's Schulung aus dem Satz "Internetaddressierung ist wie Telefonieren - schönen Abend noch" besteht (wobei wenn es so wäre, dann würde ich auch gerne Schulungen halten).
Es kommt doch ganz auf die Erklärung drum herum drauf an. Metaphern werden nur zur besseren Anschauung benutzt. Ich mag Metaphern sehr gerne, sie können komplizierte Dinge sehr einfach darstellen, sagte bereits der Hase zum Igel.
Gruß
der so klug wie ein Genie
T-Rex
Eine Metapher ist nur so gut wie das Umfeld in der sie benutzt wird. Ich denke wohl kaum das Jörg's Schulung aus dem Satz "Internetaddressierung ist wie Telefonieren - schönen Abend noch" besteht (wobei wenn es so wäre, dann würde ich auch gerne Schulungen halten).
wenn er dafür anständig bezahlt werden würde, ein guter Job. Ein sehr guter Job sogar.
Nichts für ungut,
aber wer nimmt an IT-Schulungen teil und gibt sich dann mit solch banalen Analogien zufrieden?
Jeder noch so kompliziert erscheinende Sachverhalt ist, wenn man ihn nur genügend aufklärt, banal.
Eine banale Analogie ist besser als eine unverständliche.
Eine verständliche Analogie muss auf etwas beruhen, womit der Adressat Erfahrung hat. Und die Schilder "Hier nur Briefmarken", "Abholung von Einschreiben" oder "Hier nur Päckchen" kennt zumindest meine Generation noch - aus größeren Postämtern, bei denen die Schalter auch nummeriert waren.
Die Notwendigkeit Strings von Zahlen zu unterscheiden erkläre ich damit, dass man sich das so vorstellen muss, als säße da drin ein unheimlich schneller und unheimlich dummer Typ, der die Aufgaben bekäme und erfüllen müsste ...
Bei einer "Aufgabe" wie
$foo=0561-3177227;
würde der schnell-dumme Typ also prompt -3171716 auf dem "Zettel" $foo notieren. Der ist (anders als unsereiner) eben zu blöd, eine Telefonnummer zu erkennen, rechnet dafür aber sehr viel schneller als unsereiner. Man muss also mit dessen Dummheit rechnen und $foo='0561-3177227'; notieren.
Und falls Du es wissen willst: Klar: bei Leuten, die schon eine Programmiersprache kennen, mache ich das nicht - außer um einen Fehler zu erklären und dabei zu sagen: "Naja. Eigentlich ist der Computer blöd. Aber wir müssen das halt berücksichtigen."
Das ist besser - und höflicher - als dem Teilnehmer nur zu sagen: "Sie müssen den String als solchen notieren!" Dann kommt der sich nämlich dumm vor und "steigt aus".
Ich weiß schon wie ich zu meinen sehr guten Bewertungen komme. Es sind solche Kleinigkeiten und, nachdem ich das schon jahrelang mache, habe ich ein erprobtes Repertoire - zu dem gehört auch das "Auto". (Es sei denn der Teilnehmer kommt mit Motorrad-Helm oder Fahrrad...)
@@Jörg Reinholz:
nuqneH
Bei einer "Aufgabe" wie
$foo=0561-3177227;
würde der schnell-dumme Typ also prompt -3171716 auf dem "Zettel" $foo notieren.
Nein. -3176858.
Der ist (anders als unsereiner) eben zu blöd, eine Telefonnummer zu erkennen, rechnet dafür aber sehr viel schneller als unsereiner.
Und genauer. ;-)
Qapla'
Hallo,
Bei einer "Aufgabe" wie
$foo=0561-3177227;würde der schnell-dumme Typ also prompt -3171716 auf dem "Zettel" $foo notieren.
Und warum nicht -3176666?
gruß
Kalk
Hi!
Bei einer "Aufgabe" wie
$foo=0561-3177227;
würde der schnell-dumme Typ also prompt -3171716 auf dem "Zettel" $foo notieren.
Und warum nicht -3176666?
0561 = 369
\0
Om nah hoo pez nyeetz, Tabellenkalk!
$foo=0561-3177227;
würde der schnell-dumme Typ also prompt -3171716 auf dem "Zettel" $foo notieren.
Und warum nicht -3176666?
u.U. auch 1733.
Matthias
Jörg,
verstehe mich nicht falsch, ich finde es gut, wenn man gut erklären kann. Ich kann das nämlich nicht. Eine, vielleicht etwas indiskrete Frage hätte ich noch, aber mich würde es einfach interessieren: Wie kommt man dazu, Schulungen zu machen? Also nicht warum, sondern wie bist du an die Sache rangegangen?
Humorlos und satt
Wie kommt man dazu, Schulungen zu machen? Also nicht warum, sondern wie bist du an die Sache rangegangen?
Das ist kein Geheimnis. Es ist sogar eine schöne Geschichte.
Es war 1999, historischer Hintergrund: wallende Arbeitslosigkeit.
Ich, der "Ossi", sitze völlig unterfordert und deshalb "demotiviert bis verärgert" zusammen mit 2 Dutzend, je nach Individuum leicht bis stark überforderten Ortsansässigen in einem SGB-III-Kurs (wohl für zukünftige Leiharbeiter bei Amazon oder Mitarbeiter von "Speditionen" welche im Supermarkt Regale einräumen), spiele Tetris, Pinball oder sowas und erkläre dem Kursleiter auf dessen Mahnung zur Mitarbeit hin, dass ich vom Arbeitsamt falsch einsortiert wurde, jahrelang mit Excel gearbeitet und sogar "Makros" programmiert habe und im Kursverlauf wahrscheinlich mehr darüber vergesse als er über Excel weiß (War nicht ganz so, ich habe es gewiss netter ausgedrückt). Der darauf (ich weiß nicht genau ob säuerlich oder im Spaß) "Dann halten Sie doch mal den Kurs!". Hab ich gemacht. "Kam gut".
Am selben Tag oder wenig später: Kleinanzeige auf der Job-Seite einer Zeitung: "IT-Schulungsunternehmen sucht Trainer. Reisebereitschaft(*) ... pla ... blubb" angerufen, hin, Probetraining gehalten, hat gefallen. Danach das Lampenfieber überwunden und mich auf meine Sozialisierung(**) bzw. einen Teil meiner Gene(***) besonnen. Nach den ersten Ovationen meiner Teilnehmer und den Überweisungen aufs Konto hin fest gestellt: "DAS wollte ich Rampensau schon immer machen." Begonnen hatte ich (wie praktisch jeder in dem Gewerbe) mit Office-Kursen, PC-Einsteiger und so. Jetzt mach ich Admin- und Programmierer-Kurse.
(*) Ich hab jetzt eine Bahncard weil mich das Autofahren (endet ja fast immer mit im Stau stehen und/oder nervender Parkplatzsuche) inzwischen ankotzt und dazu verleitet, erst am Tag des Seminars anzureisen.
(**,***) Wir Sachsen reden eh viel und nehmen den Kaffee bei Magenproblemen auch intravenös.
Hi,
Und die Schilder "Hier nur Briefmarken", "Abholung von Einschreiben" oder "Hier nur Päckchen" kennt zumindest meine Generation noch - aus größeren Postämtern, bei denen die Schalter auch nummeriert waren.
Damals waren die Schalter nicht nummeriert, sondern numeriert.
cu,
Andreas
Damals waren die Schalter nicht nummeriert, sondern numeriert.
Vor allem die für Briefmarkensammler ;-)
Jörg Reinholz
Somit ist das Auto das Ideale Objekt um Vererbung und Eigenschaften zu "realisieren".
Also, als mein Auto gestorben ist, hat es mir nichts vererbt. Und ich war doch der nächste Angehörige. Ich habe weder eine Tür noch eine bestimmte Farbe. Naja, vielleicht doch. Ich kann auch die Klappe nicht halten.
Linuchs
Tja manchmal erben wir nichts als schöne Erinnerungen.
Ich bin mir aber sicher dass du die Beerdigungsgebühr zahlen durftest :).
Gruß
Gebührenverweigerer
T-Rex
Ich bin mir aber sicher dass du die Beerdigungsgebühr zahlen durftest :).
Ach, erinnere mich daran nicht. Konnte zur Abmeldung den Kfz-Brief nicht wiederfinden. Da musste das schon tote Auto "wiederbelebt" werden in Form eines kostenpflichtigen Ersatz-Briefes. Das dauerte einige Wochen, in denen ich brav Steuer und Versicherung weiterzahlen musste.
Erst als das Auto auf dem Papier wieder lebte, konnten wir es endgültig totschlagen. Zur Trauerfeier bin ich aber nicht hin, vielleicht hat es auch als Organspender noch gute Dienste getan.
Linuchs
Hihi für sowas gibts die Automafia. Mein letztes Auto war ebenfalls Tod. Sowas von Tod. Fahrzeugschein hatte ich auch nicht mehr. Da kam ein dubioser Mann mit krummer Nase. Er schaute sich das Auto an und meinte dann in schlechtem Deutsch er würde mir dafür noch Geld zahlen. Dann zog er eine Geldrolle aus seiner Jackentasche die so fett war wie eine halb aufgebrauchte Toilettenrolle. Er brauchte ein wenig bis er die ganzen 500 Euro Scheine überblättert hatte um mir dann einen 50 Euroschein in die Hand zu drücken. Ich dann so "was machen sie mit dem Auto?" - er "das wird verkauft." - ich pack den 50 Euro schein weg. "Wie viel verdienen sie noch an dem Auto?". Er zieht noch einen 50 Euroschein aus dem Bündel und guckt mich mit aggressiven Augen an - "genug!". 15 Minuten später war das Auto weg. Ich glaub ich habs letztens bei Galileo gesehen als sie über Sklavenlager ääähhh... ich meine die blühende Wirtschaft in Nigeria berichtet haben.
Gruß
Märchenonkel
T-Rex
Hallo Linuchs!
Also, als mein Auto gestorben ist, hat es mir nichts vererbt. Und ich war doch der nächste Angehörige. Ich habe weder eine Tür noch eine bestimmte Farbe. Naja, vielleicht doch. Ich kann auch die Klappe nicht halten.
Und beim Verzehr bestimmter Hülsenfrüchte wirst auch Du CO2-Ausstoß-Werte haben! ;)
Mit lieben Grüßen
Melvin Cowznofski
Und beim Verzehr bestimmter Hülsenfrüchte wirst auch Du CO2-Ausstoß-Werte haben! ;)
Der CO2-ausstoß ist nicht das größte Problem. Schlimmer sind das Nervengift Schwefelwasserstoff und der "Klimakiller" Methan.
Jörg Reinholz
Hi,
ich nehme keine Autos, ich fahre keine Autos und ich hasse Autos. Ich möchte mit Autos nichts zu tun haben. Ja, tatsächlich, ich hatte vor Jahren mal ein Buch in der Hand, da wurde OOP auch anhand von -tata- Autos erläutert.... Schnell wieder zugemacht, diesen Schinken. (Natürlich war es ein PHP-Buch, was sonst).
warum wird in fast jedem Buch, Tutorial usw. wo das Thema OOP behandelt wird über Autos gesprochen. Ein Auto hat Türen, kann nach vorne fahren, Motor einschalten, ausschalten...
Ist das das "Hello World" für OOP?
Scheint so. Ich find's hinderlich. Warum nicht was konkretes, z.b. eine Art künstliche Kreatur? Hier würde dann auch das Vererben augenscheinlich Sinn ergeben. Oder besser: ein Realworld-Beispiel. Zum Beispiel eine kleine Anwendung? Warum denn nicht gleich eine kleine Anwendung?
Ist noch keiner auf die Idee gekommen, ein sinnvolleres Beispiel zu nehmen?
Doch. In der PHP-Welt vielleicht nicht. Ok, der war gemein.
Om nah hoo pez nyeetz, der Humorlose!
Ist das das "Hello World" für OOP?
Scheint so. Ich find's hinderlich. Warum nicht was konkretes, z.b. eine Art künstliche Kreatur? Hier würde dann auch das Vererben augenscheinlich Sinn ergeben. Oder besser: ein Realworld-Beispiel. Zum Beispiel eine kleine Anwendung? Warum denn nicht gleich eine kleine Anwendung?
Deine Humorlosigkeit impliziert einen enzyklopädischen Schreibstil. Damit qualifizierst du dich als Autor für unser Blog.
„In Zeiten der immer knapper werdenden Rohstoffe möchte auch ich meinen Beitrag leisten und auf das Auto verzichten.“
Matthias
Hi,
was ich mich auch schon seit längerem frage:
Ich habe eine Klasse die eine Verbindung zu meiner DB aufbaut. Wäre hier das Singleton pattern sinnvoll?
Andere Frage ist, wie ich diese DB Instanz in meine anderen Klassen "reinbekomme"?
Extend?
MfG
Naps
Hi,
was ich mich auch schon seit längerem frage:
Ich habe eine Klasse die eine Verbindung zu meiner DB aufbaut. Wäre hier das Singleton pattern sinnvoll?
Nein, absolut nicht.
Andere Frage ist, wie ich diese DB Instanz in meine anderen Klassen "reinbekomme"?
Extend?
Über Dependency Injection. Im einfachsten Fall bedeutet das, dass du bei der Initialisierung der von der DB abhängigen Klassen die DB-Verbindungsklasse im Konstruktur mitgibst. Alternativ kannst du auch ein Framework einsetzen, was dir einen Teil der Arbeit abnimmt - je nach Programmiersprache halt.
Hi,
Ich habe eine Klasse die eine Verbindung zu meiner DB aufbaut. Wäre hier das Singleton pattern sinnvoll?
Eigentlich klingt das nicht nach einem Anwendungsfall für das Singleton-Pattern. Darauf zu verzichten ist zunächst komplizierter, du machst dir aber dadurch das Testen deutlich schwerer.
Andere Frage ist, wie ich diese DB Instanz in meine anderen Klassen "reinbekomme"?
Extend?
Nein, auf keinen Fall. Du solltest nur ableiten, wenn sich die abgeleitete Klasse wie die ursprüngliche verhalten soll.
Dazu formulierst du das ganze am Besten in Prosa.
Jede Klasse sollte in einem Satz formulierbar sein, und zwar ohne die Verwendung des Wortes "und". Dadurch stellst du sicher, dass deine Klasse genau eine Bedeutung hat (das ist das S in SOLID). Wenn du irgendeine Klasse (bsp.: die Auto-Klasse) von einer DatabaseConnectionFactory (wenn ich deine Klasse mal so nennen darf), lautet die Beschreibung auf einmal: "Die Klasse Auto beschreibt ein Auto und kann Datenbank-Verbindungen aufbauen". *piiiiep* ZONK!
Du suchst nach dem Prinzip Dependency Injection. Schau z.B. mal bei PHP The Right Way, da ist es erklärt. Meistens nutzt man in PHP einen Dependency Injection Container, welcher sich um das Instanziieren deiner Objekte kümmert (inkl. derer Abhängigkeiten). Irgendwo vorne greifst du dann auf das erste Objekt zu, welches du brauchst; dieses ist dann durch den DI-Container vollständig aufgebaut.
Bis die Tage,
Matti
> Dazu formulierst du das ganze am Besten in Prosa.
Jede Klasse sollte in einem Satz formulierbar sein, und zwar ohne die Verwendung des Wortes "und". Dadurch stellst du sicher, dass deine Klasse genau eine Bedeutung hat (das ist das S in SOLID). Wenn du irgendeine Klasse (bsp.: die Auto-Klasse) von einer DatabaseConnectionFactory (wenn ich deine Klasse mal so nennen darf), lautet die Beschreibung auf einmal: "Die Klasse Auto beschreibt ein Auto und kann Datenbank-Verbindungen aufbauen". *piiiiep* ZONK!
Ok, aber nehmen wir mal an ich will ein Internes Message System machen (um jetzt doch ein Beispiel zu nennen) wie man es so oft bei diversen Foren sieht. Hier könnte ich 10 "unds" in die Beschreibung der Klasse packen.
Wäre es hier z.B. sinnvoll eine Klasse für alle Aktionen zu einer Nachricht (Speichern, als gelesen markieren, löschen, usw.) und eine Klasse für alle Aktionen für die gesamten Nachrichten (Posteingang, Postausgang, usw.). Oder doch alles in einer Klasse?
Du suchst nach dem Prinzip Dependency Injection. Schau z.B. mal bei PHP The Right Way, da ist es erklärt. Meistens nutzt man in PHP einen Dependency Injection Container, welcher sich um das Instanziieren deiner Objekte kümmert (inkl. derer Abhängigkeiten). Irgendwo vorne greifst du dann auf das erste Objekt zu, welches du brauchst; dieses ist dann durch den DI-Container vollständig aufgebaut.
Perfekt, danke!
MfG Naps
Hi,
Ok, aber nehmen wir mal an ich will ein Internes Message System machen (um jetzt doch ein Beispiel zu nennen) wie man es so oft bei diversen Foren sieht. Hier könnte ich 10 "unds" in die Beschreibung der Klasse packen.
Eine Nachricht ist eine Nachricht. D.h., sie hat einen Absender, einen Empfänger, vielleicht einen Betreff, einen Text. Sendezeit, Lesezeit, Löschzeitpunkt. Für die Beschreibung ausreichend ist, dass es eine private Nachricht zwischen zwei Nutzern des Systems ist.
Wäre es hier z.B. sinnvoll eine Klasse für alle Aktionen zu einer Nachricht (Speichern, als gelesen markieren, löschen, usw.) und eine Klasse für alle Aktionen für die gesamten Nachrichten (Posteingang, Postausgang, usw.). Oder doch alles in einer Klasse?
Erster Denkfehler: warum weiß die Nachricht, welche Aktionen auf ihr möglich sind? Eine Nachricht zu speichern gehört m.E. nicht zu den Dingen, die eine Nachricht können sollte.
Etwas anderes ist es, die Nachricht als gelesen zu markieren. Dies hat meiner Erfahrung nach zwei Teile. (1) Setzen des Zustands in der Nachricht (d.h. Lesezeitpunkt setzen). Dazu würde ich eine Methode in der Nachrichtenklasse schreiben, welche den Lesezeitpunkt setzt. (2) Speichern/Persistieren des neuen Zustands. Gehört m.E. nicht zu den Dingen, die die Nachricht wissen sollte.
Ich nutze derzeit Doctrine als ORM. Teil 1 findet tatsächlich in meiner Entity statt (die aber so geschrieben ist, dass sie, zumindest was den PHP-Teil angeht, nichts von Doctrine weiß). Für Teil 2 schreibe ich einen Transaktionslayer, welcher zwichen Frontend-Code und Business-Code steht. Der Transaktionslayer ist eigentlich nichts weiteres als eine high-level API auf die Business-Use-Cases und tut i.d.R. nichts anderes, als die entsprechende Business-Methode(n) aufzurufen und dann die DB-Transaktion zu beenden (den Entity-Manager zu flushen). Wenn ich es nicht ganz falsch verstanden habe, dann ist es etwa das Pattern, was allgemein als "Boundary" bekannt ist.
Bis die Tage,
Matti
Tach!
Ich habe eine Klasse die eine Verbindung zu meiner DB aufbaut. Wäre hier das Singleton pattern sinnvoll?
Andere Frage ist, wie ich diese DB Instanz in meine anderen Klassen "reinbekomme"?
Gegen Singleton spricht, dass deine "Verbraucher" genau wissen müssen, wie sie an dieses Singleton herankommen. Außerdem ist es nicht so richtig testbar (wenn das für dich von Belang ist). Es gibt ein Prinzip "dont look for things", demzufolge man nicht in der Klasse selbst nach benötigten Dingen schaut, und man als Außenstehender nicht weiß, das die Klasse alles benötigt, sondern ihr alles übergibt (Dependency Injection). Wenn Klassen etwas benötigen, sollten sie Parameter bekommen, die als Interface typisiert sind. Darüber reicht man dann rein, was man denen geben will. Das ist entweder eine Instanz einer produktiven Klasse oder ein Dummy für die Unit-Tests. Außerdem zwingt dich so dein Code, die Reihenfolge beim Initialisieren richtig einzuhalten.
Natürlich zwingt dich keiner, das so zu machen, aber so machen es "die guten". Such mal nach "clean code talks".
dedlfix.
Natürlich zwingt dich keiner, das so zu machen, aber so machen es "die guten". Such mal nach "clean code talks".
Danke für den Link ;)
MfG Naps
hi,
Andere Frage ist, wie ich diese DB Instanz in meine anderen Klassen "reinbekomme"?
Extend?
Wenn Du SQL-Statements inmitten Deines Codes haben willst, mach die DB-Verbindung zu einem Attribute Deiner Klassen. Wenn nicht, arbeite mit Data Abstraction, dem Code isses dann egal, wo die Daten herkommen.
Horst
