Ankündigung

Einklappen
Keine Ankündigung bisher.

Video Diskussion: Wieso man extends vermeiden sollte und was gibt es als alternative?

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • BlackScorp
    antwortet
    es geht nicht darum jemanden "Einzuschränken" das final kann man halt immer noch entfernen, wenigstens weiß ich aber dann, dass diese Klasse abgeleitet wurde und andere nicht.

    Arne Drews so funktioniert das aber nicht in kleinen Betrieben. Meistens hast du da ein Proof of Concept welches direkt auch Live Code ist und es wird einfach weiter gemacht. Wir schreiben unsere Projekte nicht permanent um und wenn wir eine Klasse anpassen müssen, dann weiß ich ganz genau dass bei Final ich machen kann was ich will, ohne Final muss ich mir gedanken machen wie ich eine Methode umschreibe ohne alles kaputt zu machen. Damit muss ich nicht bei JEDER klasse aufpassen.

    Klar denkt jede Abteilung an die aktuellen Anforderungen, diese verändern sich mit der Zeit und es gibt immer wieder irgendwas woran man nicht gedacht hat.

    Einen Kommentar schreiben:


  • Anyone
    antwortet
    @BlackScorp:
    Ich verstehe das Problem nicht so ganz. Wenn jemand nicht in der Lage ist, Vererbung richtig und sinngemäß einzusetzen, dann ist das doch seine eigene Unwissenheit. Aber deswegen andere Entwickler einzuschränken, die das sehr wohl beherrschen? Ich weiß ja nicht, ob das so sinnvoll ist.

    Einen Kommentar schreiben:


  • Arne Drews
    antwortet
    Und zukunftssichere Projekte basieren darauf, dass sich das Entwicklerteam/der Entwickler die Gedanken vor der Umsetzung bereits gemacht hat.
    Der Ansatz, sich erst dann Gedanken zu machen, wenn es soweit ist, führt häufig zu völlig überladenen Klassen/Projekten.

    Ich kenne das aus unserer Firma. Wenn neue Produkte entwickelt werden müssen, denkt jede Abteilung logischer Weise erstmal nur an die aktuelle Anforderungen.
    Sehr häufig kommen wir dann ins Spiel und geben zu bedenken, dass weitere Fälle eintreten werden und tlw. auch gar nicht von der Hand zu weisen sind.
    Würden wir das nicht berücksichtigen, wären wir permanent dran, unsere eigene Projekte umzuschreiben, das macht keinen Sinn. Ein Projekt sollte skalierbar aufgebaut sein.

    Einen Kommentar schreiben:


  • BlackScorp
    antwortet
    Zitat von tomBuilder Beitrag anzeigen
    Ich will es mal von einer anderen Seite betrachten, möglicherweise verstehst Du dann was ich meine.
    In einem anderem Thread habe ich Pimple verlinkt, ein brauchbarer Container, welchen man so als final markieren könnte.

    Es ist sicher zu befürchten, das der einoder andere NOOB sonstwas draus ableitet, jedenfalls nicht nur das was gedacht war oder sinnvoll ist.
    Deswegen müsste in Deiner Logik Pimple als final makiert werden.

    Die macher von Pimple haben sich dazu entschieden ein "extending the Container" in die docu aufzunehen was den machern von Slim sicher gefällt, denn der Container bei Slim basiert auf Pimple.

    Die Macher von Pimple nehmen den Entwickler ernst.
    Du bevormundest potentielle Entwickler mit dem final.

    Code zu schreiben, der sich an noobs richtet und diese in die richtige richtung zwingt, kann ein axiom in kursen, niemals aber in real live sein.
    Ich verstehe das völlig und es macht auch Sinn, du könntest ja ein ArrayContainer ein MySQLContainer ein INIFileContainer bauen und die könnten von dem Container abgeleitet werden. Da müssen die Entwickler aber dann Backwardcompability gewährleisten und der Aufwand dafür sollte auch nicht unterschätz werden. Man muss das halt abwäge. Halte ich meine Klasse offen und baue meine methoden so dass diese auch Backwardcompatible sind oder ich mache alles zu und entwickle so dass man garnicht erst ableiten muss.

    Da ich persönlich nicht in die Zukunft sehen kann wie lange ich eine Klasse pflegen muss und auch mir keine Gedanken machen will wie andere meine Klasse benutzen KÖNNTEN deklariere ich einfach alles als final und WENN es zu einer Ableitung kommen muss, dann werde ich informiert und DANN kann ich mir die notwendigen Gedanken über die Zukunft machen. Bei einem musst du halt vorher an alles denken, beim anderen erst wenn der Fall tatsächlich eintritt.

    Einen Kommentar schreiben:


  • tomBuilder
    antwortet
    Ich will es mal von einer anderen Seite betrachten, möglicherweise verstehst Du dann was ich meine.
    In einem anderem Thread habe ich Pimple verlinkt, ein brauchbarer Container, welchen man so als final markieren könnte.

    Es ist sicher zu befürchten, das der einoder andere NOOB sonstwas draus ableitet, jedenfalls nicht nur das was gedacht war oder sinnvoll ist.
    Deswegen müsste in Deiner Logik Pimple als final makiert werden.

    Die macher von Pimple haben sich dazu entschieden ein "extending the Container" in die docu aufzunehen was den machern von Slim sicher gefällt, denn der Container bei Slim basiert auf Pimple.

    Die Macher von Pimple nehmen den Entwickler ernst.
    Du bevormundest potentielle Entwickler mit dem final.

    Code zu schreiben, der sich an noobs richtet und diese in die richtige richtung zwingt, kann ein axiom in kursen, niemals aber in real live sein.

    Einen Kommentar schreiben:


  • BlackScorp
    antwortet
    Zitat von Arne Drews Beitrag anzeigen
    "Andere sehen es auch so" ist glaube ich hier der falsche Weg, um zu fundamentieren, dass man recht hat.
    Man könnte sicher haufenweise Links finden von Leuten, die genau andersrum denken und damit die Sache "widerlegen".

    Die Lösungen zu einer Problemdarstellung können i.d.R. vielfältig sein. Es mag bessere und schlechtere Varianten geben, aber selten nur die eine richtige.
    Ich denke, die meisten hier haben schon verstanden, was Du mit dem Video vermitteln wolltest, nur sind einige halt der Ansicht, dass das ungünstig bis missverständlich rüber gebracht wurde.

    Du solltest nicht versuchen Dich zu rechtfertigen oder sonstiges, sondern die Kritiken für Dich annehmen und selber entscheiden, was Du daraus machst.
    Du fragst hier nach Feedback und ich schätze Dich auch so ein, dass Du dankbar für Feedback auch in Form von Kritik bist.
    Wenn Du aber der Meinung bist, dass die Dinge und vor allem das Konzept und die Beweggründe des Video hier von erfahrenen Mitgliedern falsch verstanden werden, tendiere ich zu behaupten, dass die Zielgruppe - nämlich Anfänger/Einsteiger - das auch tun und Dein Video halbwissend als Argument hernehmen: "So macht man das".

    Ich denke, davor wollen Dich die meisten nur warnen.
    Hast schon Recht, ich wollte auf keinen fall sagen "So macht man das" sondern "Damit habe ich mehr Postive Erfahrung gemacht als mit .. daher emfpehle ich es".

    Meine Zielgruppe möchte ich schon noch irgendwann wechseln auf Einsteiger/Mid Developer nur bis dahin muss ich an meinen Scripten Arbeiten. Ich bin sehr Dankbar für die Kritik, wartet ab, in 5 Jahren wird es ganz anders aussehen

    Ich habe hier auch meine Alten Beiträge gesehen, wo ich meine tolle DB Klasse gepostet habe und nikosch mich anschließend außeinander genommen hat Ist ein tolles Erlebnis sein früheres Ich zu sehen im Forum.

    Einen Kommentar schreiben:


  • Arne Drews
    antwortet
    "Andere sehen es auch so" ist glaube ich hier der falsche Weg, um zu fundamentieren, dass man recht hat.
    Man könnte sicher haufenweise Links finden von Leuten, die genau andersrum denken und damit die Sache "widerlegen".

    Die Lösungen zu einer Problemdarstellung können i.d.R. vielfältig sein. Es mag bessere und schlechtere Varianten geben, aber selten nur die eine richtige.
    Ich denke, die meisten hier haben schon verstanden, was Du mit dem Video vermitteln wolltest, nur sind einige halt der Ansicht, dass das ungünstig bis missverständlich rüber gebracht wurde.

    Du solltest nicht versuchen Dich zu rechtfertigen oder sonstiges, sondern die Kritiken für Dich annehmen und selber entscheiden, was Du daraus machst.
    Du fragst hier nach Feedback und ich schätze Dich auch so ein, dass Du dankbar für Feedback auch in Form von Kritik bist.
    Wenn Du aber der Meinung bist, dass die Dinge und vor allem das Konzept und die Beweggründe des Video hier von erfahrenen Mitgliedern falsch verstanden werden, tendiere ich zu behaupten, dass die Zielgruppe - nämlich Anfänger/Einsteiger - das auch tun und Dein Video halbwissend als Argument hernehmen: "So macht man das".

    Ich denke, davor wollen Dich die meisten nur warnen.

    Einen Kommentar schreiben:


  • tomBuilder
    antwortet
    Zitat von BlackScorp Beitrag anzeigen
    Übrigens bin ich nicht der Einzige der der Meinung ist, man sollte eine Klasse direkt mit final erstellen https://matthiasnoback.nl/2018/09/fi...y-default-why/ Er hat wohl auch schlechte Erfahrung mit extends gemacht
    When I see a class that's not final, it feels to me like it's a very vulnerable class. Its internals are out in the open; people can do with it what they want, not only what its creator has imagined.
    So wie er es schreibt, ist das doch eher ein diffuses gefühl,

    Einen Kommentar schreiben:


  • BlackScorp
    antwortet
    Zitat von tomBuilder Beitrag anzeigen

    Was man sagen will ist in dem Kontext egal, was man sagt nicht; möglicherweise wird du das auch einmal verstehen.
    Ja, ich habe mir schon auf meine Todo Liste aufgeschrieben, dass ich am Ende des Videos eine Zusammenfassung erstelle wo ich dann versuche alles im Kontext küzer zu Erklären. Ich verstehe sehr wohl dass da einiges Unklar ist und dass ich deutlicher darauf achten muss was man sagt.


    Zitat von tomBuilder Beitrag anzeigen
    Dass eine Auflistung von Negativbeispielen daran irgendwas ändert, oder gar irgend eine konkretisierung eines positiv beispiels erahnen lässt,
    halte ich für sehr weit hergeholht.
    wer weiß, ich lasse mich überraschen, vielleicht, eines Tages. Übrigens bin ich nicht der Einzige der der Meinung ist, man sollte eine Klasse direkt mit final erstellen https://matthiasnoback.nl/2018/09/fi...y-default-why/ Er hat wohl auch schlechte Erfahrung mit extends gemacht

    Einen Kommentar schreiben:


  • tomBuilder
    antwortet
    Zitat von BlackScorp Beitrag anzeigen

    ja dann hast du nicht verstanden was ich sagen wollte.
    Was man sagen will ist in dem Kontext egal, was man sagt nicht; möglicherweise wird du das auch einmal verstehen.

    Dass eine Auflistung von Negativbeispielen daran irgendwas ändert, oder gar irgend eine konkretisierung eines positiv beispiels erahnen lässt,
    halte ich für sehr weit hergeholht.

    Einen Kommentar schreiben:


  • BlackScorp
    antwortet
    Zitat von tomBuilder Beitrag anzeigen
    Ich verstehe nicht, wieso Du da jetzt die paypal api als refferenz nutzt und auch nicht was das mit dem thema zu tun hat.
    macht nichts.
    ja dann hast du nicht verstanden was ich sagen wollte. extends wird zu oft falsch benutzt und anhand von PayPal siehst du ein reallife example. Das war das Thema des Videos. Da es zu viele nebenwirkungen hat, nutzt einfach nur Trait, es ist ein kleiner Shortcut.

    Einen Kommentar schreiben:


  • tomBuilder
    antwortet
    Ich verstehe nicht, wieso Du da jetzt die paypal api als refferenz nutzt und auch nicht was das mit dem thema zu tun hat.
    macht nichts.

    Zitat von tomBuilder Beitrag anzeigen
    Gut mach es wie Du magst, meine Meinung habe ich gesagt.

    Einen Kommentar schreiben:


  • Anyone
    antwortet
    Ich persönlich halte nicht viel von der Regel, möglichst viele Klassen als final zu deklarieren. Das ist meiner Meinung nach zu restriktiv. Gerade wenn dies außerhalb deines Enflussbereiches liegt (Fremdbibliothek) und du aber dringend eine Erweiterung für diese Klasse brauchst, dann kann das schon ziemlich nervig sein (und vielleicht sogar die Entwicklung blockieren!). Zudem, sofern das Liskovsche Substitutionsprinzip verstanden worden ist, können Kindklassen auch jederzeit ihre Superklasse ersetzen und legitimatisieren die Vererbung ohnehin und widersprechen dem "alles als final definieren" Gedanken.

    Aber ja, wenn man blindlings einfach darauf los Klassen ableitet, dann ist es auch nicht Sinn und Zweck der Sache.

    Einen Kommentar schreiben:


  • BlackScorp
    antwortet
    Wir reden hier glaub ich an einander vorbei. Häng dich nicht an den Konkreten Beispielen im Video auf.

    Meine Aussage war: extends wird oft nicht sinnvoll eingesetzt. Sogar Profis machen das Falsch, hier als Beispiel Offizielle PayPal API https://github.com/paypal/PayPal-PHP...lib/PayPal/Api jede dieser Klasse wird von PayPalModel abgleitet. Weiso? Weil dadurch haben die Zugriff auf fromArray/toArray plötzlich erhält jede dieser Klasse eine Zweite Responsibility und zwar daten hydration.

    Hier wären die mit einem Trait besser dran gewesen, korrekt wäre es aber eher den Hydrator injezieren. WIeso besser? PayPalModel hat eine zu starke Abhängigkeit,bzw zu viele Klassen sind von ihr abhägngig, dadurch kann man die Klasse schlecht Verändern. Außerdem kriegen dadurch die Klassen eine weitere Verantwortung und dadurch verletzt man Single Responsibility Prinzip.

    Extends ist eben nicht so einfach umzusezten, neben diesem Beispiel, müsste man noch auf Liskovs Substitutions Prinzip achten. Es ist ein Komplexes Thema und man kann mit einem Trait einen Shortcut machen. Auf diesen Shortcut wollte ich hinweisen, ich habe auch gesagt, dass ich meine Klassen sofort mit final initialisiere so dass diese erst garnicht abgeleitet werden.

    Naja und titel passt ja dann nicht. Ich habe ja nicht gesagt, wann sondern wieso, weil es zu kompliziert ist Und "Darum nutze ich KAUM Extends" :P

    Einen Kommentar schreiben:


  • tomBuilder
    antwortet
    Zitat von BlackScorp Beitrag anzeigen
    Ich finds faszinieren, was jeder hier interpretiert hat, das sagt mir dass ich echt schlecht bin, darin meine "Message" deutlich zu zeigen. Werde dran arbeiten. Eure Antworten haben mir echt weitergeholfen
    Das kenne ich

    Also fange ich nochmal neu an.

    Titel, wann man extends vermeiden sollte ?



    Zitat von BlackScorp Beitrag anzeigen

    Habe ich auch nicht gesagt, eine Klasse hat Eigenschaften UND Methoden, und fliegen ist eine Methode/Aktion der Klasse
    nein!

    Ich habe gesagt, fliegen (können) ist keine eigenschaft eines vogels - eines lebewesens.
    wieso soll eine abbildende Klasse methoden haben, welche in der abzubildenden welt nicht zwingend zu dem abgebildeten Object gehören ?

    genauso grenzwertig halte ich es fliegen als trait zu nutzen, für vögel, insekten und fledermäuse (und fische ?).


    deswegen habe ich das mit der nahrung ins spiel gebracht ^^

    es geht dir in den videos ja nicht darum zu zeigen, was du kannst sondern anfängern hilfestellung zu geben.

    in bezug darauf halte ich die so getroffenen aussagen von dir - nicht was man möglichereise falsch verstehen könnte - stellenweise für sehr ungeeignet,
    wie ich bspw. am alternativen titel oben angedeutet habe.

    Einen Kommentar schreiben:

Lädt...
X