Ankündigung

Einklappen
Keine Ankündigung bisher.

OOP mit Funktionen?

Einklappen

Neue Werbung 2019

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

  • OOP mit Funktionen?

    Hallo Leute,

    ich wollte mal ein wenig Diskutieren/Philosophieren über OOP in PHP.

    Ich habe ja ein Projekt wo ich alles nur mit Funktionen umsetze damit ich halt Beispiele einem Anfänger zeigen kann. Dabei ist mir aufgefallen dass ich im Grunde alles machen kann, was ich sonst mit OOP auch mache ausgenommen sind nur

    * Typehints
    * Setter Getter
    * Autoloading
    * Exceptions

    Die Syntax ist halt etwas anders. Die Fragen die ich mir jetzt stelle ist, sind meine Projekte zu banal dass ich keine besonderen OOP Funktionen benötige? Oder ist OOP eigentlich nur ein Syntax Sugar für schnellere Lesbarkeit?

    Ich habe mir mal die Wiki Seite angeschaut um heraus zu finden was OOP wirklich ausmacht, im vergleich zu Funktionen und konnte jetzt nichts konkretes finden.

    Laut der Defintion auf der Seite https://de.wikipedia.org/wiki/Objekt...Programmierung stehen folgende Punkte:

    1. Everything is an object
    Das trifft ja in PHP auch nicht zu, wir nutzen kein String object wie es zb in C# der Fall ist.

    2. Objects communicate by sending and receiving messages (in terms of objects)
    Trifft in PHP auch nicht zu, nicht jeder hat ein Messaging Objekt, meistens returned man null/true/false/error message oder ruft ne Methode vom Objekt auf. Ausnahmen sind Exceptions. Aber Exceptions ist halt nur ein Art wie objekte Kommunizieren.

    3. Objects have their own memory (in terms of objects)
    Haben Funktionen auch, ich kann innerhalb einer Funktion eine Variable definieren oder sogar anonyme Funktion und dann in PHP ähnliches machen wie es JavaScript macht.

    4. Every object is an instance of a class (which must be an object)
    Ja nun, javascript Objekte sind ja auch nur Closures die intern anonyme Funktionen haben

    5. The class holds the shared behavior for its instances (in the form of objects in a program list)
    Keine Ahnung wie ich das Interpretieren soll

    6. To eval a program list, control is passed to the first object and the remainder is treated as its message
    Verstehe ich auch nicht.

    Danach gab es ja Anpassung zu der Defintion

    “OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.”

    ja wunderbar, innerhalb von Funktionen kann ich prozesse Definieren in Form von Closures und messages kann ich auch nutzen indem ich Funktionen in Funktionen aufrufe und via Static die Variablen in der Funktion befülle. Late Binding mach ich mit call_user_func ich kann durchaus ein String für eine Funktion zusammensetzen und diese dann je nach dem aufrufen. (Vorausgesetzt ich habe es korrekt verstanden https://de.wikipedia.org/wiki/Polymo...Programmierung) )

    Also letztendlich sieht für mich es so aus als ob OOP einfach nur Syntax Sugar ist und kann durchaus alles in Funktionen umsetzen.

    was sagt ihr? Was macht jetzt OOP wirklich aus außer Syntax? Lesbarkeit? Wiederverwendung?

    Ich will nur ein vernüftigen Weg finden wie ich mit hilfe von Funktionen einen Anfänger an OOP heranführe und es nicht so Stumpf wie in der Schule angehe. Meine Idee ist, ich definieren Funktionen um ein Problem zu beheben und dann kann ich dann auf die Funktion eingehen und sagen "In OOP machst du das so und so". Nur kann es ja sein dass ich irgendwas überhaupt nicht bedacht habe, dass OOP doch nicht so leicht mit Funktionen umsetzbar wäre.

    Bin auf eure Antworten gespannt
    apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

  • #2
    Ich halt mich da an stackoverflow
    https://stackoverflow.com/questions/...ed-programming

    Kommentar


    • #3
      Moin,

      also zuerst muss ich sagen, dass du den Interpretationsspielraum für die einzelnen Punkte aus der Definition imo sehr weit ausdehnst [1]. Ohne dazu viel schreiben zu wollen sticht besonders 3. ins Auge; bei 1. und 4. sehe ich die Relevanz nicht ob einzelne Sprachen mit denen man objektorientiert programmieren kann auch jeden der Punkte abdecken im wahrsten Sinne oder per workarounds abdecken.
      Bei 2. ist das meines Verständnisses nach nicht so zu deuten, dass bei jedem Methodenaufruf Objekte mitgeschickt werden sollen, sondern dass bereits die Aufrufe an sich als Nachrichten zwischen den Objekten zu betrachten
      sind. (In Coders at Work gibt es ein sehr umfangreiches Interview mit Dan Ingalls in dem auch nochmal darauf eingegangen wurde; es sollten nicht Objekte und Klassen sondern die Nachrichten im Mittelpunkt stehen)


      Zweitens gehe ich immer noch nicht mit der Annahme konform, dass Funktionen einfacher als OOP sind. Es ist einfach ein völlig anderer Entwicklungsansatz mit anderen Stärken, anderen Problemen und anderen Patterns um mit den Problemen umzugehen.

      Drittens,
      Also letztendlich sieht für mich es so aus als ob OOP einfach nur Syntax Sugar ist und kann durchaus alles in Funktionen umsetzen.
      Ja, denke ich auch.
      Wobei eben das Problem im Fokus stehen sollte und nicht wie man mit Funktionen eine OOP-Lösung möglichst detailgetreu nachbauen kann. Je nach Problem kann der Funktionen- oder der OOP-Ansatz angenehmer sein.

      Ich will nur ein vernüftigen Weg finden wie ich mit hilfe von Funktionen einen Anfänger an OOP heranführe und es nicht so Stumpf wie in der Schule angehe.
      Aber das sind doch völlig verschiedene Dinge^^'
      Wenn du jemandem OOP beibringen willst, bring ihm halt OOP bei. Aber ich sehe nicht, wie du z.B. von deinem Functions only Projekt (https://github.com/BlackScorpGames/w.../functions.php) den Schwenk auf "Und so würde man es mit einem Repository machen" hinbekommst - die Implementierungen wären doch vollkommen unterschiedlich.


      [1]
      Z.B.
      “OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.”
      ja wunderbar, innerhalb von Funktionen kann ich prozesse Definieren in Form von Closures und messages kann ich auch nutzen indem ich Funktionen in Funktionen aufrufe und via Static die Variablen in der Funktion befülle.
      Das ist für mich halt wie... "Mein Kanu braucht kein Paddel, ich kann ja auch Pedale, Kurbelwelle, Schaufelrad und Lenkrad einbauen." Es geht... ist aber halt was anderes und in diesem Fall bedeutend umständlicher.
      [COLOR=#A9A9A9]Relax, you're doing fine.[/COLOR]
      [URL="http://php.net/"]RTFM[/URL] | [URL="http://php-de.github.io/"]php.de Wissenssammlung[/URL] | [URL="http://use-the-index-luke.com/de"]Datenbankindizes[/URL] | [URL="https://www.php.de/forum/webentwicklung/datenbanken/111631-bild-aus-datenbank-auslesen?p=1209079#post1209079"]Dateien in der DB?[/URL]

      Kommentar


      • #4
        Zitat von VPh Beitrag anzeigen
        Moin,

        also zuerst muss ich sagen, dass du den Interpretationsspielraum für die einzelnen Punkte aus der Definition imo sehr weit ausdehnst. Ohne dazu viel schreiben zu wollen sticht besonders 3. ins Auge; bei 1. und 4. sehe ich die Relevanz nicht ob einzelne Sprachen mit denen man objektorientiert programmieren kann auch jeden der Punkte abdecken im wahrsten Sinne oder per workarounds abdecken.
        Stimmt
        Zitat von VPh Beitrag anzeigen
        Bei 2. ist das meines Verständnisses nach nicht so zu deuten, dass bei jedem Methodenaufruf Objekte mitgeschickt werden sollen, sondern dass bereits die Aufrufe an sich als Nachrichten zwischen den Objekten zu betrachten sind.
        Ok, ich habe das halt so verstanden, dass jede "Nachricht" ein String als ein Objekt ausgetauscht werden soll. Wenn du in C# return "SOme Message"; machst kriegst du ja ein StringObjekt zurück, in PHP nicht. Aber dann verstehe ich diese Aufzähung nicht, wahrscheinlich ist es eh nicht mehr Relevant weil jede Programmier Sprache per se alle Punkte abdeckt nur zu damaligen Zeitpunkt als die Punkte aufstellt waren, war es nicht so.

        Zitat von VPh Beitrag anzeigen
        Zweitens gehe ich immer noch nicht mit der Annahme konform, dass Funktionen einfacher als OOP sind. Es ist einfach ein völlig anderer Entwicklungsansatz mit anderen Stärken, anderen Problemen und anderen Patterns um mit den Problemen umzugehen.
        Ich weiß nicht ob es direkt einfacher ist. Ich finde es zb Praktisch, Basis Objekte zu erzeugen und dann mit gettern/settern arbeiten statt wie bisher im Projekt mit Arrays. Gut viellecht meinst du mit "einfach" bezüglich lesbarkeit und verstehen was der Code tun soll nicht einfach im Sinne von einfacher zu tippen.

        Zitat von VPh Beitrag anzeigen
        Wobei eben das Problem im Fokus stehen sollte und nicht wie man mit Funktionen eine OOP-Lösung möglichst detailgetreu nachbauen kann. Je nach Problem kann der Funktionen- oder der OOP-Ansatz angenehmer sein.
        Das ist interessant, vielleicht sollte man ein Mix machen. Also Basis Objekte erstellen um nicht mit arrays zu arbeiten und um Typehints zu nutzen und Autoload und Exceptions aber den Rest dann mit Funktionen abbilden ..

        Zitat von VPh Beitrag anzeigen
        Aber das sind doch völlig verschiedene Dinge^^'
        Wenn du jemandem OOP beibringen willst, bring ihm halt OOP bei.
        Naja der Hintergrund war, in der Schule hatte ich so viele OOP Stunden, es ist halt einfach zu verstehen dass es Objekte gibt und wie man die definiert, Ich habe alten Code von mir Angesehen, da waren Gottobjekte wie "Page" oder "Core" oder "Framework" was alles konnte. Oder die Typische DB::getInstance(); Ich möchte ein Weg einschlage wo ich sage "Ok das hier ist ein Problem, so löst du das Problem" und alles mit Funktionen aufzeigen. Dann aber "Die Syntax ist aber sehr Kompliziert, und so machst du das mit OOP"

        Quasi nicht sagen, wie es in Wiki beschrieben ist "Die OOP kann, wie auch andere Programmierparadigmen, verwendet werden, Probleme aus der realen Welt abzubilden." Sondern sagen OOP ist eine einfachere Syntax um dein Problem zu lösen. Es hat mich halt mehrere Jahre gekostet um zu verstehen was OOP ist.

        Zitat von VPh Beitrag anzeigen
        Aber ich sehe nicht, wie du z.B. von deinem Functions only Projekt (https://github.com/BlackScorpGames/w.../functions.php) den Schwenk auf "Und so würde man es mit einem Repository machen" hinbekommst - die Implementierungen wären doch vollkommen unterschiedlich.
        Naja ein Ansatz könnte sein dass ich statt die Datei "functions.php" einfach "CharacterRepository.php" bennen und die Funktionen dort zusammenfasse. Dort sollte dann nur CRUD Funktionen drin sein. Und dann daraus kann ich dann sagen. "Ok ich packe jetzt eine Klasse drumherum und schon haben wir ein Repository"

        Mit der Ursprungsfrage wollte ich herausfinden ob ich mich komplett geirrt habe oder nicht, aber da du der Meinung bist dass OOP auch nur eine Syntax ist, dann scheine ich ja nicht ganz daneben zu liegen.

        tomBuilder
        ja da wird generell unterschieden was besser bzw was wozu da ist. Ich will eher OOP Lehren aber auf Funktionen aufbauen. Aktuell könnte ich mir sogar vorstellen, weniger OOP in meinen eigenen Projekten umsetzen Denn es ist durchaus manchmal sehr Komplex wie meine Klasse aufgebaut sind wo man sich dann fragt. Muss das so sein?
        apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

        Kommentar


        • #5
          Man kann Projekte in PHP auch komplett mit Funktionen bauen, so wie WordPress es auch zum größten Teil ist. Allerdings ist dies, meiner Meinung, ein Horror wenn man sich dort mal reinarbeiten muss. Bei einem objektorientierten Projekt, finde ich es deutlich übersichtlicher.

          Kommentar


          • #6
            Zitat von Zeichen32 Beitrag anzeigen
            Man kann Projekte in PHP auch komplett mit Funktionen bauen, so wie WordPress es auch zum größten Teil ist. Allerdings ist dies, meiner Meinung, ein Horror wenn man sich dort mal reinarbeiten muss. Bei einem objektorientierten Projekt, finde ich es deutlich übersichtlicher.
            Findest du? Also ich habe mir Symfony und Laravel des öffters angesehen, und da ist es auch oft nicht klar von welcher Instanz wurde jetzt ein Objekt erzeugt, man muss sich sogar teilweise größere Abhängigkeiten merken damit du weiß wie du an die besondere Stelle im Code kommst oder was da ausgeführt wird. In Laravel durch die Fasaden wird auch noch mehr versteckt wo man sich ab einen gewissen Zeitpunkt nur noch denkt "Ach what ever, ist mir egal was da im Hintergrund passiert"
            apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

            Kommentar


            • #7
              Ich habe ja ein Projekt wo ich alles nur mit Funktionen umsetze damit ich halt Beispiele einem Anfänger zeigen kann. Dabei ist mir aufgefallen dass ich im Grunde alles machen kann, was ich sonst mit OOP auch mache...
              Warum wundert dich das? Du kannst auch alles mit Spaghetticode ganz ohne Funkionen schreiben, funktioniert auch und letzten Endes wird es auch dahingehend übersetzt, wenn man sich mal Maschinencode ansieht.

              Kommentar


              • #8
                Zitat von BlackScorp Beitrag anzeigen
                Die Syntax ist halt etwas anders. Die Fragen die ich mir jetzt stelle ist, sind meine Projekte zu banal dass ich keine besonderen OOP Funktionen benötige? Oder ist OOP eigentlich nur ein Syntax Sugar für schnellere Lesbarkeit?
                OOP ist nicht mit einem Knall entstanden, sondern haben sich mit aus anderen Konzepten entwickelt. Das sich diese Konzepte in OOP wiederfinden lassen und auch OOP wieder auf diese Konzepte zurückgeführt werden kann, ist nicht allzu verwunderlich.

                Zitat von BlackScorp Beitrag anzeigen
                Ich habe mir mal die Wiki Seite angeschaut um heraus zu finden was OOP wirklich ausmacht, im vergleich zu Funktionen und konnte jetzt nichts konkretes finden.
                encapsulation, inheritance, polymophism?!

                Zitat von BlackScorp Beitrag anzeigen
                2. Objects communicate by sending and receiving messages (in terms of objects)
                Trifft in PHP auch nicht zu, nicht jeder hat ein Messaging Objekt, meistens returned man null/true/false/error message oder ruft ne Methode vom Objekt auf. Ausnahmen sind Exceptions. Aber Exceptions ist halt nur ein Art wie objekte Kommunizieren.
                Du verstehst Nachricht in dem Kontext falsch. Das sind einfach nur Methoden aufrufe. Du sendest "$object" die Nachricht "->hallo()".

                Zitat von BlackScorp Beitrag anzeigen
                3. Objects have their own memory (in terms of objects)
                Haben Funktionen auch, ich kann innerhalb einer Funktion eine Variable definieren oder sogar anonyme Funktion und dann in PHP ähnliches machen wie es JavaScript macht.
                Eine Funktion hat i.d.R. kein Speicher.
                Ohne Speicher:
                function incrementCounter() [ return $i++; }
                Mit Speicher:
                function incrementCounter() [ static $i = 0; return $i++; }

                Die Variante ohne Speicher macht natürlich kein Sinn, die Variante mit Speicher ist durch den globalen Scope gefährlich und unflexibel. Es kann immer nur einen Counter in der Antwendung geben, wird das nicht beachtet hast du böse Seiteneffekte und wenn deine Counter nicht nur hochzählen soll hast du gleich das nächste Problem.
                Du wirst jetzt also anfangen den State rauszusiehen und bei jedem Aufrufen mitgeben.

                function incrementCounter(&$i) { $i++; }
                function decrementCounter(&$i) { $i--; }

                Kommt dann schon irgendwie bekannt vor?! Es fehlt noch die encapsulation. Der State kann in der Form auch von außen geändert werden. (was du ohne OOP Support der Sprache nicht verhindern kannst)

                Und das nächste "Problem" ist, du kannst in der Form die funktionalität nicht ändern. Willst du jetzt z.B. auch ein Counter haben, der den state des Counters automatisch in einer Datei speichert, hättest du in der Form ein Problem. Die Funktion incrementCounter() ist fest, da kannst du nix dran ändern. Du musst also den Quelltext ändern um das zu erreichen. Um das zu vermeiden, baust du jetzt noch in den state "Late Binding mach ich mit call_user_func" ein. Statt incrementCounter() rufst du jetzt call_user_func($state['incrementCounter'], $state) auf.

                Kommt irgendwie bekannt vor?!

                Zitat von BlackScorp Beitrag anzeigen
                Also letztendlich sieht für mich es so aus als ob OOP einfach nur Syntax Sugar ist und kann durchaus alles in Funktionen umsetzen.
                Der OOP Support ist kein Syntax Sugar, sondern ermöglicht erst OOP solide umzusetzen. Sowas wie "call_user_func($state['incrementCounter'], $state)" in C knallt erst zur Laufzeit, ein counter.incrementCounter() wird dir in C++ schon beim Compilieren um die Ohren fliegen.

                Zitat von BlackScorp Beitrag anzeigen
                Die Fragen die ich mir jetzt stelle ist, sind meine Projekte zu banal dass ich keine besonderen OOP Funktionen benötige?
                Wer behauptet das für jedes Problem die volle Palette OOP gebraucht wird oder eingesetzt werden muss? Auch ist in OOP auch nicht alles Gold was glänzt. State und behavior zu koppeln bringt teilweise auch unschöne Probleme mit sich.

                Kommentar


                • #9
                  Zitat von protestix Beitrag anzeigen
                  Warum wundert dich das? Du kannst auch alles mit Spaghetticode ganz ohne Funkionen schreiben, funktioniert auch und letzten Endes wird es auch dahingehend übersetzt, wenn man sich mal Maschinencode ansieht.
                  Naja, ich meine das wirklich, du kannst ja private Variablen innerhalb einer Funktion defnieren

                  PHP-Code:
                  function myClass()
                  {
                       
                  $var1  0;

                      return [
                          
                  'setVar1' => function ($value) use (&$var1) {

                              
                  $var1 $value;

                          },
                          
                  'getVar1' => function () use (&$var1) {
                              return 
                  $var1;
                          }
                      ];
                  }

                  $myClass myClass();

                  $myClass['setVar1'](10);

                  echo 
                  $myClass['getVar1']()."<br/>";

                  $myClass2 myClass();
                  $myClass2['setVar1'](20);

                  echo 
                  $myClass2['getVar1'](); 
                  IDE ist da nicht sonderlich hilfreich aber du siehst, du hast instanzen du hast private und public Eigenschaften. Sieht aus wie OOP nur bisschen andere Syntax.
                  apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

                  Kommentar


                  • #10
                    Zitat von BlackScorp Beitrag anzeigen

                    Findest du? Also ich habe mir Symfony und Laravel des öffters angesehen, und da ist es auch oft nicht klar von welcher Instanz wurde jetzt ein Objekt erzeugt, man muss sich sogar teilweise größere Abhängigkeiten merken damit du weiß wie du an die besondere Stelle im Code kommst oder was da ausgeführt wird. In Laravel durch die Fasaden wird auch noch mehr versteckt wo man sich ab einen gewissen Zeitpunkt nur noch denkt "Ach what ever, ist mir egal was da im Hintergrund passiert"
                    Also ich bin mit dem Symfony Code richtig zufrieden. Vieles ist genau so oder ähnlich umgesetzt wie ich es gemacht hätte und folgt entsprechenden Pattern, so finde ich ist es immer relativ einfach mit dem Code umzugehen. Über Laravel kann ich nicht viel sagen, da ich bis auf in October CMS noch nicht so viel mit Laravel zutun hatte. Aber soweit ich weiß, basiert das Framework auch auf den Symfony Komponenten.

                    Kommentar


                    • #11
                      erc
                      encapsulation, inheritance, polymophism?!

                      encapsulation und polymophism lassen sich schon mit reinen Funktionen abbilden, siehe #9 inheritance nicht, aber ich vermeide es ja eh
                      apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

                      Kommentar


                      • #12
                        Zitat von Zeichen32 Beitrag anzeigen

                        Also ich bin mit dem Symfony Code richtig zufrieden. Vieles ist genau so oder ähnlich umgesetzt wie ich es gemacht hätte und folgt entsprechenden Pattern, so finde ich ist es immer relativ einfach mit dem Code umzugehen. Über Laravel kann ich nicht viel sagen, da ich bis auf in October CMS noch nicht so viel mit Laravel zutun hatte. Aber soweit ich weiß, basiert das Framework auch auf den Symfony Komponenten.
                        Naja hier ein Beispiel https://github.com/symfony/symfony/b...lient.php#L128 profiler kann hier was auch immer sein, du musst schon wissen, was gibt es denn für Profiler, wo lese ich nach was denn in den Container INjeziert wurde. Also wenn Service Locator eingesetzt wird, wird schon einiges in OOP Komplexer und du musst dir dann die Struktur merken.

                        Ich sage nicht dass Symfony schlecht ist, ich sage nur dass OOP schon auch sehr unübersichtlich werden kann.
                        apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

                        Kommentar


                        • #13
                          Zitat von BlackScorp Beitrag anzeigen

                          Naja hier ein Beispiel https://github.com/symfony/symfony/b...lient.php#L128 profiler kann hier was auch immer sein, du musst schon wissen, was gibt es denn für Profiler, wo lese ich nach was denn in den Container INjeziert wurde. Also wenn Service Locator eingesetzt wird, wird schon einiges in OOP Komplexer und du musst dir dann die Struktur merken.

                          Ich sage nicht dass Symfony schlecht ist, ich sage nur dass OOP schon auch sehr unübersichtlich werden kann.
                          Das stimmt, die Klasse ist aber auch "@deprecated since Symfony 4.3" und der direkte Zugriff auf den Container gilt als "Bad Practice" und wird aktuell aktive aus dem Core entfernt und durch Constructor Injection ausgetauscht.

                          Kommentar


                          • #14
                            Zitat von BlackScorp Beitrag anzeigen
                            erc
                            encapsulation, inheritance, polymophism?!

                            encapsulation und polymophism lassen sich schon mit reinen Funktionen abbilden, siehe #9 inheritance nicht, aber ich vermeide es ja eh
                            Auch Vererbung lässt sich nachbauen. (btw: traits sind Vererbung...) Das spielt aber keine Rolle. Es sind die Konzepte die OOP ausmachen. Eine Sprache die OOP Support mit bringt, macht es dir einfacher diese Konzepte zu nutzen.

                            Zitat von BlackScorp Beitrag anzeigen
                            Ich sage nicht dass Symfony schlecht ist, ich sage nur dass OOP schon auch sehr unübersichtlich werden kann.
                            Das ist kein Problem von OOP, sondern ein Problem der Abstraktion.


                            Kommentar


                            • #15
                              Zitat von erc Beitrag anzeigen

                              Auch Vererbung lässt sich nachbauen. (btw: traits sind Vererbung...) Das spielt aber keine Rolle. Es sind die Konzepte die OOP ausmachen. Eine Sprache die OOP Support mit bringt, macht es dir einfacher diese Konzepte zu nutzen.
                              Ja das ist mir klar, nur der Weg wie ich OOP gelernt habe, finde ich völlig falsch.

                              Es hieß "So beschreibt ihr Objekte und damit könnt ihr Hierarchien im Code abbilden und das dient dazu um Reale Welt abzubilden" -> Daraus entstehen dann God Objekte, Singletons und weitere Antipattern.

                              Dann wird gesagt "Ach übrigens, jetzt wo ihr wisst wie man Klassen schreibt, das sind übrigens Design Pattern" damit hat man weitere Dinge gelernt und versucht diese nutzen ohne wirklich zu wissen wozu.

                              Und dann nach dem man krankhaft versucht alle möglichen design pattern anzuwenden, stellt man fest YAGNI.

                              Vielleicht kann man das ja andersherum machen? Frei nach dem Motto

                              So sehen Funktionen aus, mit solchen Funktionen kann man Problem X lösen, die Lösung heißt pattern A und zum Schluss "So kann man das dann schöner schreiben".

                              Oder meint ihr dass die Syntax der Funktionen viel zu unübersichtlich für Anfäger wird und deshalb sollte man direkt mit Klassen anfangen?


                              Also quasi man sagt nicht, "Hier habt ihr ein Hammer es gibt folgende Arten von Hammer" sondern "Wir haben das Problem dass hier ein Nagel rausguckt, wir brauchen etwas um es reinzuhauen, ein Stein zb. übrigens geht es mit einem Hammer"
                              apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

                              Kommentar

                              Lädt...
                              X