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

  • #16
    Oder ist OOP eigentlich nur ein Syntax Sugar für schnellere Lesbarkeit?
    IMHO: ja, so isses (aber OOP bringt etwas mehr mit, als nur verbesserte Lesbarkeit).

    OO ist ein Konzept, aber ein Computer bzw. eine CPU kann mit Konzepten nix anfangen.
    In der Maschinensprache gibt es nur die Subroutine, vergleichbar mit einer Funktion... tatsächlich ist eine Funktion nur eine Herleitung einer Assembler-Subroutine.
    Betrachtet man z.B. die (sehr maschinen-nahe) Sprache C, ist sie also im Grunde auch nur Syntax Sugar für Assembler, dessen Mnemonic nur ein Syntax Sugar für den Binärcode ist.

    Das OO in Programmiersprachen ist nur getrickst, wenn man es aus der Warte einer CPU betrachetet: ein Regelwerk, umgesetzt mit den Mitteln, die der Prozessor zur Verfügung stellt, gegossen in ein eigenes Stück Software welches die Regeln festlegt und überwacht (die Laufzeitumgebung).

    Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

    Kommentar


    • #17
      Alles klar, dann habe ich alles verstanden und kann schon den Weg gehen dass ich mit Funktionen erst die OOP Paradigmen umsetze und anschließend den Klassen Weg zeige.
      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


      • #18
        Ich bin gerade auf diesen Thread gestoßen und gebe mal meinen Senf dazu:

        Eine Funktion hat i.d.R. kein Speicher.
        Hat sie - Der nennt sich Stack. Die Konstruktion mit static ist meines Wissens nach ein Feature von PHP, das ich sonst noch nirgends gesehen habe und das das Konzept einer Funktion ad absurdum führt.

        Das trifft ja in PHP auch nicht zu, wir nutzen kein String object wie es zb in C# der Fall ist.
        Das hat in diesem Kontext nichts mit Datentypen zu tun, sondern mit den Entitäten. Mit OOP erstellst Du eine Repräsentation der realen Welt - Und dort sind alles Objekte. Ob ein String ein Scalar ist oder ein Objekt, spielt hier keine Rolle.

        Nur Funktionen zu benutzen bedeutet nicht Spaghetti-Code.

        BlackScorp Schau Dir mal funktionale Programmierung an. Das geht in die Richtung, die Du suchst, glaube ich. Das Problem hier ist, dass PHP dafür nicht geeignet ist (Kein Typehinting für Funktions-Deklarationen, teure Rekursion usw.). Wenn Du es aber mal verwendet hast, z. B. mit Scala, f# oder Erlang, wirst Du erkennen, dass es gegenüber OOP in mancher Hinsicht Vorteile mit sich bringt.

        OOP ist aber nicht schlechter oder besser - Es ist vor allem geeignet, wenn die Applikation Entity-zentriert ist. Allerdings wird kaum irgendwo die reine Lehre von OOP verwendet, sondern das Anemic Domain Model. Dort hat man sogenannte Services, die das Verhalten beinhalten, während die Objekte die Daten beinhalten. Diese Trennung widerspricht OOP. Und hier ist funktionale Programmierung von Vorteil.

        Bsp "OOP":

        PHP-Code:
        interface UserRepoInterface {
            public function 
        findById(integer $id): User;
        }

        class 
        UserRepo implements USerRepoInterface
        {
            public function 
        findById(integer $id): User
            
        {
                
        // ...
            
        }
        }


        class 
        Controller {

            
        /**
             * @var UserRepo
             */
            
        private $userRepo;

            public function 
        __construct(UserRepo $userRepo)
            {
                
        $this->userRepo $userRepo;
            }

            public function 
        handle(Request $request)
            {
                return 
        $this->userRepo->findById($request->get('id'));
            }
        }
        $controller = new Controller(new UserRepo());
        // ...
        $router->register('GET''/user:id'$controller->handle); 
        Bsp funktionale Programmierung (In Go, da PHP sehr ungeeignet ist. Die Syntax sollte halbwegs verständlich sein. Allerdings ist auch Go nur bedingt für FP geeignet.):
        Code:
        //...
        func FindUserById(id int) User {...}
        //...
        
        func NewHandle(findUserById func(id int) User) func(request Request) User {
            return func(request Request) User {
                return findUserById(request->get("id"));
            };
        }
        
        router.Register("GET", "/user/:id", NewHandler(FindUserById));
        Das ist natürlich sehr vereinfacht und auch syntaktisch vermutlich nicht korrekt, veranschaulicht aber das Prinzip. Neben der Reduzierung des Codes und der besseren Übersicht lässt es sich auch viel leichter testen, weil man nun keine Mocks mehr für das Repository braucht, sondern einfach eine passende Funktion injizieren kann.

        Das "Problem" mit OOP ist, dass es so weit verbreitet ist, da es überall gelehrt wird und in Sprachen wie PHP und Java verwendet wird. Java wird in der Regel an Schulen und Universitäten gelehrt, wodurch es viele kennen.

        Ein weiterer Vorteil von FP ist, dass States reduziert werden, da Funktionen diesen per se nicht haben. Eine Funktion wird aufgerufen, sie wird ausgeführt, etwas wird zurückgegeben. Es kann keinerlei Seiteneffekte geben. Arbeitet mal mit einer Sprache, die Nebenläufigkeit bietet und nutzt diese, dann wisst ihr, was ich meine.

        Funktionale Programmierung ist nicht einfach aber man mag mal über Tellerrand schauen und sich funktionale Sprachen anschauen (Haskell, Erlang, F# usw.) Dadurch eröffnen sich ganz neue Horizonte.

        Kommentar


        • #19
          Zitat von xm22 Beitrag anzeigen
          Die Konstruktion mit static ist meines Wissens nach ein Feature von PHP, das ich sonst noch nirgends gesehen habe und das das Konzept einer Funktion ad absurdum führt.
          Ja genau desswegen fühlt sich dann FP in PHP an wie als ob es OOP wäre
          Zitat von xm22 Beitrag anzeigen
          Das ist natürlich sehr vereinfacht und auch syntaktisch vermutlich nicht korrekt, veranschaulicht aber das Prinzip. Neben der Reduzierung des Codes und der besseren Übersicht lässt es sich auch viel leichter testen, weil man nun keine Mocks mehr für das Repository braucht, sondern einfach eine passende Funktion injizieren kann.
          Ich mocke sowieso meine Repositories nie über ein Framework sondern erstelle halt richtig eine Mock Klasse die ich dann vor dem Test mit Test Entities befülle. Alles manuell

          Zitat von xm22 Beitrag anzeigen
          Das "Problem" mit OOP ist, dass es so weit verbreitet ist, da es überall gelehrt wird und in Sprachen wie PHP und Java verwendet wird. Java wird in der Regel an Schulen und Universitäten gelehrt, wodurch es viele kennen.
          Darauf will ich hinaus, ich finde, als mir OOP beigebracht wurde, habe ich es total falsch interpretiert, weil mir nicht gesagt wurde, welche Probleme ich lösen kann sondern welche Möglichkeiten gibt es und du suchst dir dann die Richtige aus, ohne irgendwelche hilfe.

          Ich habe bekannte die gerade auch Java im Studium einsetzen und wenn ich die frage wieso die getter und setter nutzen und nicht einfach alles auf public setze, sagen die dann "Weil der Prof es so gesagt hat". Also war mein Gedanke. Wir haben in PHP static innerhalb einer Funktion, also können wir mit Funktion erst mal simpel alles Programmieren und dann durch die Probleme auf OOP übergehen, bzw dazugeben. Es ist halt nicht einfach so eine Idee konkret umzusetzen und dann noch als Video zu verpacken desswegen wollte ich ein bisschen Brainstorming hier betreiben. Aber es scheint tatsächlich wohl alles so zu sein wie ich es mir vorgestellt habe, eure Antworten bestätigen mein Verdacht.
          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


          • #20
            Zitat von xm22 Beitrag anzeigen
            Hat sie - Der nennt sich Stack. Die Konstruktion mit static ist meines Wissens nach ein Feature von PHP, das ich sonst noch nirgends gesehen habe und das das Konzept einer Funktion ad absurdum führt.
            Hinweis: C & C++ unterstützen ebenfalls local statics. Daher vermutlich auch das Feature in PHP

            Zum Thema: PHP macht den Umgang mit Funktionen sehr umständlich und "verbose". Wenn du Lust auf Funktionen hast, dann empfehle ich einen Ausflug in die Welt von Functional Programming und mal einen Blick auf Haskell und ggf. Scala zu werfen.
            [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

            Kommentar


            • #21
              Was ich geschrieben habe

              Kommentar


              • #22
                Ich geh mal garnicht auf das bereits geschreibene ein, weil ich grad lesefaul bin und zeige wie ich OOP verstehe.

                Für mich definierte Vorteile aus der Praxis:
                • Aufbau komplexer und in sich geschlossene / gekapselte Strukturen mit klaren Schnittstellen nach Außen
                • Übergabe von Parametern in dynamischer Menge im Gegensatz zu einer Funktionssignatur
                • Aufbau spezialisierter eigenständiger Entitäten / eigener Typen ( z.b. Einfaches wie Int8 oder String256 )
                • Aufbau mehrschichtiger Abstraktionsebenen
                • Wiederverwendbarkeit von Bibliothekskomponenten
                • Gemeinssamkeitseigenschaften von Klassen über Interfaces definierbar machen
                • Instanzbildung von Listen mit Elementen, die sich auch nur leicht unterscheiden
                • Klassifizierbarkeit von Strukturen , Objekten und Vorgängen bzw auch Domänen
                • komplexe Objekte in Parameterübergaben
                • Polymorphie
                • Testbarkeit
                • gute Lesbarkeit
                • hohe Plastizität bei gleichzeitig stabiler Struktur
                • Aufteilen der Implementierungsarbeit auf unterschiedliche Zuständigkeiten
                bitcoin.de <- Meine Freelancerwährung

                Kommentar


                • #23
                  Zitat von Alpha Beitrag anzeigen
                  Ich geh mal garnicht auf das bereits geschreibene ein, weil ich grad lesefaul bin und zeige wie ich OOP verstehe.

                  Für mich definierte Vorteile aus der Praxis:
                  • Aufbau komplexer und in sich geschlossene / gekapselte Strukturen mit klaren Schnittstellen nach Außen
                  • Übergabe von Parametern in dynamischer Menge im Gegensatz zu einer Funktionssignatur
                  • Aufbau spezialisierter eigenständiger Entitäten / eigener Typen ( z.b. Einfaches wie Int8 oder String256 )
                  • Aufbau mehrschichtiger Abstraktionsebenen
                  • Wiederverwendbarkeit von Bibliothekskomponenten
                  • Gemeinssamkeitseigenschaften von Klassen über Interfaces definierbar machen
                  • Instanzbildung von Listen mit Elementen, die sich auch nur leicht unterscheiden
                  • Klassifizierbarkeit von Strukturen , Objekten und Vorgängen bzw auch Domänen
                  • komplexe Objekte in Parameterübergaben
                  • Polymorphie
                  • Testbarkeit
                  • gute Lesbarkeit
                  • hohe Plastizität bei gleichzeitig stabiler Struktur
                  • Aufteilen der Implementierungsarbeit auf unterschiedliche Zuständigkeiten
                  Genau und weil du in PHP innerhalb einer Anonymen Funktion anonyme Funktionen definieren kannst und auch statische Variablen haben kannst die pro Funktion exestieren, kannst du eben fast alles aus der Liste abbilden. Also bis auf Typehints, Interfaces und Extends. Extends verwende ich ja generell wenig, dann bleiben dann nur die ersteren Übrig. Und daher hatte ich dann die Ursprüngliche Frage, was wenn man über Funktionen die Idee hinter OOP lehrt statt direkt mit OOP konstrukt anzufangen und alles einem Anfänger überlassen der eventuell erst Jahre später versteht was eigentlich OOP ist. Alle waren dakor
                  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


                  • #24
                    Und daher hatte ich dann die Ursprüngliche Frage, was wenn man über Funktionen die Idee hinter OOP lehrt statt direkt mit OOP konstrukt anzufangen und alles einem Anfänger überlassen der eventuell erst Jahre später versteht was eigentlich OOP ist. Alle waren dakor
                    Ich habs eher so in Erinnerung, dass alle gesagt haben: "Ja, man könnte mit Funktionen OOP nachbilden" (Kann man auch per rein prozedural runter programmiertem Code, musst nur includes richtig setzen, dann brauchst du nicht einmal mehr Funktionen)

                    Ich persönlich halte es für Unsinn und hoffe, dass ich nicht auf Entwickler treffe die mit
                    innerhalb einer Anonymen Funktion anonyme Funktionen definieren kannst und auch statische Variablen haben kannst die pro Funktion exestieren
                    rumpfuschen und versuchen etwas nachzubilden was schon gut in die Sprache integriert wurde.

                    Ich halte den Ansatz jemandem so OOP beizubringen immer noch für groben Unsinn. Das Argument "Mir wurde OOP falsch beigebracht also bringen ich es per Funktionen bei"... das macht für mich so wenig Sinn, dass mir ehrlich gesagt die Worte fehlen.
                    [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


                    • #25
                      Zitat von VPh Beitrag anzeigen
                      Ich halte den Ansatz jemandem so OOP beizubringen immer noch für groben Unsinn. Das Argument "Mir wurde OOP falsch beigebracht also bringen ich es per Funktionen bei"... das macht für mich so wenig Sinn, dass mir ehrlich gesagt die Worte fehlen.
                      Wir werden sehen, es muss doch ein Grund geben wieso viele ein God Object Pattern einsetzen und weitere anti pattern, ich glaube das liegt daran dass am Anfang zu "viel" Informationen gegeben werden werden so dass man es direkt falsch einsetzt, mit Funktionen kann man das beschränken.

                      Ich kann mich halt damals auch gut erinnern, "Alles muss OOP sein" und habe auch eine Datenbank Klasse gemacht, aber wozu? Es gibt PDO es ist bereits eine Klasse. Nun die Instanz anzulegen ist halt nervig und man muss öffters eine Klasse anlegen, weil ich es nicht besser wusste, erstellte ich ein Multiton (fast ein Singleton nur ohne private __clone())

                      Die Gedankengänge sind da am Anfang halt falsch, vielleicht kann man es optimieren

                      Übrigens Anonyme Funktionen innerhalb anonymer Funktionen, darauf ist JavaScript aufgebaut, es gibt welche die Kotzen desswegen und andere wiederum finden es völlig OK. Ich möchte einfach neue Wege ausprobieren.
                      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


                      • #26
                        Alpha
                        Ich geh mal garnicht auf das bereits geschreibene ein, weil ich grad lesefaul bin
                        Nicht gerade ein guter Ansatz um einer Diskussion beizutreten Ich gehe mal auf Deine Punkte ein, weil das teils ziemlich verquer scheint:

                        Die meisten Dinge, die Du genannt hast, sind keine Alleinstellungsmerkmale von OOP bzw. sie kommen nicht durch OOP zustande. Du wirfst da auch Aspekte unterschiedlicher Level zusammen, die teils gar nichts mit OOP zu tun haben.

                        Bsp. aus Deiner Liste, die OOP kennezeichnen:

                        * Aufbau komplexer und in sich geschlossene / gekapselte Strukturen mit klaren Schnittstellen nach Außen (so halb und halb)
                        * Polymorphie

                        Der Rest hat nichts damit zu tun, was OOP von anderen Paradigmen unterscheidet.

                        VPh

                        innerhalb einer Anonymen Funktion anonyme Funktionen definieren kannst und auch statische Variablen haben kannst die pro Funktion exestieren
                        Das ist gar nicht so unsinnig und in der funktionalen Programmierung sogar ziemlich verbreitet (map/reduce z. B. als Beispiel für ersteres und memorized functions für letzteres).

                        Ich halte den Ansatz jemandem so OOP beizubringen immer noch für groben Unsinn. Das Argument "Mir wurde OOP falsch beigebracht also bringen ich es per Funktionen bei"... das macht für mich so wenig Sinn, dass mir ehrlich gesagt die Worte fehlen.
                        Ganz so weit würde ich nicht gehen, aber man sollte auf jeden Fall 1. das eine vom anderen trennen und 2. OOP nicht mit Funktionen nachbauen wollen - Das ist in der Tat widersinnig.

                        BlackScorp
                        Übrigens Anonyme Funktionen innerhalb anonymer Funktionen, darauf ist JavaScript aufgebaut, es gibt welche die Kotzen desswegen
                        Wenn man es erst mal richtig angewandt hat, kriegt man das "Kotzen", weil es in php so schlecht implementiert ist

                        Wir werden sehen, es muss doch ein Grund geben wieso viele ein God Object Pattern einsetzen und weitere anti pattern
                        Ich denke (Falls Du das nicht meinst), dass die Idee des Objektgraphen und wie man ihn aufbaut den meisten am Anfang nicht klar ist.


                        Ich kann mich halt damals auch gut erinnern, "Alles muss OOP sein" und habe auch eine Datenbank Klasse gemacht, aber wozu? Es gibt PDO es ist bereits eine Klasse.
                        Das ist insofern durchaus berechtigt um sich nicht von der PDO-Implementierung abhängig zu machen. Allerdings bin ich mittlerweile der Meinung, dass Abstraktionsschichten oftmals überflüssig sind. Da kommt dann das Argument:"Ja, aber wenn man später mal nicht mehr eine Datenbank, sondern einen Webservice oderwasauchimmer verwendet, kann man weiterhin die Abstraktion benutzen" - Meiner Meinung nach Quatsch. 1. passiert das in den seltensten Fällen und 2. muss man dann eh so viel umschreiben, dass das das geringste Problem ist.

                        Ich möchte einfach neue Wege ausprobieren.
                        Absolut d'accord. Und selbst, wenn man es anfangs vielleicht falsch macht, kommt man am Ende doch wieder auf den richtigen Weg

                        Kommentar


                        • #27
                          Ich habe einige Jahre überwiegend mit Funktionen und Spaghetti-Code gearbeitet und irgendwann mal mit OOP angefangen, obwohl ich mir konkret gar nicht so viel davon versprochen hatte. Die vorherrschende Meinung war halt, dass man ohne OOP zu den gestrigen Deppen gehört.

                          Heute freue ich mich allerdings, dass ich viel besser durch meinen Code durchblicke und nicht mehr 100 Funktionen mit jedem Seitenaufruf lazy loade, obwohl ich nur drei brauche.

                          Das große Plus sehe ich bei der Code-Struktur. Der Nachteil ist vlt., dass man vor lauter Konzepten wie Design-Patterns, Vererbung, Interfaces, Abstraktionen etc. gar nicht mehr erkennt, wie man all das zusammen und sinnvoll verwenden soll.
                          [B]Es ist schon alles gesagt. Nur noch nicht von allen.[/B]

                          Kommentar


                          • #28
                            Zitat von drsoong Beitrag anzeigen
                            Ich habe einige Jahre überwiegend mit Funktionen und Spaghetti-Code gearbeitet und irgendwann mal mit OOP angefangen, obwohl ich mir konkret gar nicht so viel davon versprochen hatte. Die vorherrschende Meinung war halt, dass man ohne OOP zu den gestrigen Deppen gehört.

                            Heute freue ich mich allerdings, dass ich viel besser durch meinen Code durchblicke und nicht mehr 100 Funktionen mit jedem Seitenaufruf lazy loade, obwohl ich nur drei brauche.

                            Das große Plus sehe ich bei der Code-Struktur. Der Nachteil ist vlt., dass man vor lauter Konzepten wie Design-Patterns, Vererbung, Interfaces, Abstraktionen etc. gar nicht mehr erkennt, wie man all das zusammen und sinnvoll verwenden soll.
                            Eigentlich helfen Desing-Pattern ja gerade dabei den Code übersichtlich zu halten, da wenn konsequent angewandt, jede Software nach den selben Design-Pattern aufgebaut ist und dadurch der Einstieg leichter fällt.
                            Das selbe gilt auch für Frameworks. Bei uns in der Firma basieren die meisten Projekte auf Symfony. Auch wenn ich ein Projekt noch nie gesehen habe, ist die Einarbeitungszeit für mich aber relativ überschaubar, da ich durch den Einsatz von Symfony, immer weiß wo ich was finde.

                            Kommentar


                            • #29
                              Zitat von BlackScorp Beitrag anzeigen
                              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.
                              Dazu habe ich vor kurzem die PHP-Extension scalar-objects unter https://github.com/blar/scalar-objects getestet. Zwar sind die Skalare immer noch keine Objekte, lassen sich aber ähnlich verwenden.

                              PHP-Code:
                              $string = ['a''b''c''d''e']->join(',');
                              $array 'a,b,c,d,e'->split(','); 

                              Kommentar


                              • #30
                                Die Frage ist halt, ob man das braucht, wenn es dafür schon Funktionen gibt (implode, explode) . Es _muss_ nicht alles ein Objekt sein nur um der OO willen.

                                Kommentar

                                Lädt...
                                X