OOP



  • unsigned long schrieb:

    Also mal ehrlich, das was ihr in PHP "Objektorientierte Programmierung" nennt, nenne ich eher ein Armutszeugnis. Misserable und Fehlerhafte Umsetzung, kein friend, keine einheitliche Logik dahinter, Abstraktion ist ein Witz, dazu dieses ewige Abwärtskompatibel bleiben.

    Mal ehrlich: Ich kenne keine OOP Sprache aus dem Stehgreif in dem man den Konstruktor des Vaters explizit aufrufen muss oder das eine abgeleitete Klasse, sich für die Basisklasse hält.

    In Php5 hast du:
    - Vererbung
    - Kapselung
    - und Laufzeitpolymorphie
    Was brauchst du mehr fuer OOP?
    Ausserdem ist friend der Bruch zu OOP, weil es die Kapselung bricht.

    Was meinst du mit "keine einheitliche Logik"?
    Das man den Ctor des Vaters explizit aufrufen muss, ist eine Designfrage der Sprache und nicht eine feste Regel der OOP. Abstraktion hast du in Php5, nicht mehr als in C# oder in Java.

    Mit Php5 kannst du wunderbaren OOP-Code schreiben, das einzige was ich vermisse sind Namespaces. Du musst halt leider globale Funktionen aufrufen, aber das ist ja auch nicht so schlimm.

    Also ich habe ein Web-Projekt als eine eine schoene State-Maschine in php5 geschrieben. Ergibt einen schoenen sauberen Code, der auch leicht erweitern laesst.



  • friend ist doch kein bruch der kapselung

    es fügt lediglich eine funktion zum interface der klasse hinzu

    im übrigen benötigt oop keine kapselung
    das pattern zugriffsschutz ist nicht immer notwendig/erwünscht, auch wenn es hilft einige fehler zur compile/run-time zu finden



  • ronny schrieb:

    friend ist doch kein bruch der kapselung

    es fügt lediglich eine funktion zum interface der klasse hinzu

    im übrigen benötigt oop keine kapselung
    das pattern zugriffsschutz ist nicht immer notwendig/erwünscht, auch wenn es hilft einige fehler zur compile/run-time zu finden

    Du kannst mit friend eine ganze Klasse zur einer anderen "hinzufuegen". Also hat die Klasse B aufeinmal vollen Zugriff auf die Interna der Klasse A. Das, finde ich, ist eine gravierende Verletzung der Kapselung und eben so der Abstraktion.



  • man muss doch dann das ganze explizit in klasse a angeben

    sowas ist durchaus nützlich wenn bestimmte interna einer klasse für die andere benötigt werden, ohne das man dafür ein offenes interface anbieten will



  • ronny schrieb:

    man muss doch dann das ganze explizit in klasse a angeben

    sowas ist durchaus nützlich wenn bestimmte interna einer klasse für die andere benötigt werden, ohne das man dafür ein offenes interface anbieten will

    Genau, und das ist der Bruch zu OOP. Wenn man friend verwendet hat man eh meist einen Designfehler oder ist einfach faul. (C++ fuer operatoren ausgeschlossen, da gehts ja nicht anders und ist IMHO Designschwaeche von C++).



  • Nur was hat oop mit Zugriffsschutz am hut ? imho sind das 2 Konzepte die sich gut miteinander verwenden lassen aber nicht fest aneinander gebunden sind.

    Nur dieser absolutismus immer ...

    im übrigen sind kontrollierte interface-erweiterungen auf andere klassen/funktionen nicht weiter tragisch



  • DEvent schrieb:

    Genau, und das ist der Bruch zu OOP. Wenn man friend verwendet hat man eh meist einen Designfehler oder ist einfach faul.

    quatsch. Die Kapselung bleibt doch weiter erhalten. Man hat nur mehr Möglichkeit sie durchzusetzen.



  • rüdiger schrieb:

    DEvent schrieb:

    Genau, und das ist der Bruch zu OOP. Wenn man friend verwendet hat man eh meist einen Designfehler oder ist einfach faul.

    quatsch. Die Kapselung bleibt doch weiter erhalten. Man hat nur mehr Möglichkeit sie durchzusetzen.

    Na wenn du meinst... Man gibt zwar einer Klasse die volle Kontrolle ueber eine andere Klasse, aber die Kapselung bleibt weiter erhalten jaja. 🤡



  • DEvent schrieb:

    rüdiger schrieb:

    DEvent schrieb:

    Genau, und das ist der Bruch zu OOP. Wenn man friend verwendet hat man eh meist einen Designfehler oder ist einfach faul.

    quatsch. Die Kapselung bleibt doch weiter erhalten. Man hat nur mehr Möglichkeit sie durchzusetzen.

    Na wenn du meinst... Man gibt zwar einer Klasse die volle Kontrolle ueber eine andere Klasse, aber die Kapselung bleibt weiter erhalten jaja. 🤡

    Wer sagt denn, dass die Kapselung nur auf eine Klasse beschränkt sein soll?

    Aber wenn du lieber rumpöbeln willst, als zu argumentieren, dann verzieh dich einfach und raub nicht meine Zeit!



  • http://www.parashift.com/c++-faq-lite/friends.html#faq-14.2

    If they're used properly, they enhance encapsulation.


Anmelden zum Antworten