OOP: soll man jetzt alles in ne Klasse packen oder watt?



  • otze schrieb:

    er meint damit übersetzungsfehler.

    diamond=raute/diamant
    silicon=silizium/silicon

    ach so..



  • Shade Of Mine schrieb:

    und wir zeigen hier lediglich dass access control in C++ nur syntaktischer zucker ist.

    Bis jetzt konnte das keiner zeigen.

    class blub
    {
    private:
      int geheim;
    }
    

    Fakt ist: Portabel und standardkonform kommst Du an geheim nicht dran, wenn ich Dich nicht zum friend mache.

    Daß das nur syntaktischer Zucker ist, ist natürlich ohnehin quatsch. Immerhin kann der Compiler damit Fehler finden, die sich sonst erst zur Laufzeit bemerkbar machen würden.



  • Zeus schrieb:

    Tschuldigung dass ich mich zu Wort melde, aber das machst nur du

    Zeus schrieb:

    Ob die Sprache ein Feature bietet zu kapselt oder ein Schlüsselwort bietet ist nebensächlich (ledenfalls für mich, möge andere geben für die wichtig ist.)
    Das Ziel ist, was von OOP verfolgt wird, dass der Programmier gezwungen wird Schnittstelle zu definieren, und die Daten von Außen nicht zu sehen sind.

    @Jester:
    #define private public
    fertig.

    funktioniert ueberall.
    access control auf source code level ist nur da um sich gegen zufaellige fehler zu schuetzen und nicht um einbruchssicher zu sein.

    der schon mehrmals gezeigte cast klappt auch so ziemlich ueberall.

    in der theorie vielleicht UB oder IB, aber in der praxis klappt es.
    es es zeigen soll ist aber, dass der zugriffschutz nicht ausreichend ist um sich auf ihn zu verlassen. man muss sich auf den programmierer verlassen dass er nicht rumpfuscht.

    oder vergessen wir c++ jetzt mal, weil wieder alle komplett das wesentliche aus dem auge verlieren (und wie bei c++ ueblich sich ueber kleinigkeiten streiten) - betrachten wir stattdessen Reflection.

    Reflection hebelt jede form von access control aus.

    somit hat eine sprache die reflection unterstuetzt nur sehr schwachen access control.

    und class based access control ist sowieso viel zu schwach, nur object based access control ist gut. aber das ist ja nun wieder etwas unuebliches und deshalb nicht OO. ich weiss...



  • Ja du versteht mein Zitat nicht lol

    Vergessen? :

    Zeus schrieb:

    clan der oop-ritter schrieb:

    Zeus schrieb:

    Zeig mir Datenkapselung in C.

    // lol.h
    #ifndef LOL_H
    #define LOL_H
    
    int get();
    void set(int i);
    
    #endif
    
    // lol.c
    #include "lol.h"
    
    static int zahl;
    
    int get() {
        return zahl;
    }
    
    void set(int i) {
        zahl = i;
    }
    

    Da hast du deine Kapselung du "OOP-Ritter".

    Sry, das ist Informations Hidding und nicht Kapselung!!!!

    aqivalent mit folgend Code:

    class{
    public:
    int i;
    }
    

    zu

    class{
    private:
    int i;
    }
    

    aber nix OOP.

    Einfach irgendwas in private zu Deklarieren ist immernoch kein OOP. Und ich kann dir nochmehr Deklaraton mit Hilfe von Klassen zeigen, dass kein OOP entspricht.



  • Shade Of Mine schrieb:

    oder vergessen wir c++ jetzt mal, weil wieder alle komplett das wesentliche aus dem auge verlieren (und wie bei c++ ueblich sich ueber kleinigkeiten streiten) - betrachten wir stattdessen Reflection.

    Reflection hebelt jede form von access control aus.

    somit hat eine sprache die reflection unterstuetzt nur sehr schwachen access control.

    Das halte ich für'n Gerücht. 😉



  • Shade Of Mine schrieb:

    access control auf source code level ist nur da um sich gegen zufaellige fehler zu schuetzen und nicht um einbruchssicher zu sein.

    und ist damit kein syntaktischer Zucker, oder?



  • [...] Sry, das ist Informations Hidding und nicht Kapselung!!!!

    aqivalent mit folgend Code: [...]

    Nachdem du es anscheinend immer noch nicht kapieren willst, frag ich mich langsam ernsthaft, ob du auch verstehst, was du schreibst (siehe z.B: Wikipedia für eine Beschreibung von Information Hiding).

    http://en.wikipedia.org/wiki/Information_hiding schrieb:

    In modern programming languages, the principle of information hiding manifests itself in a number of ways, including encapsulation (given the separation of concerns) and polymorphism.

    Von mir aus kannst du ja weiterhin Blödsinn reden, aber bitte spiel dich dabei nicht so auf.



  • Jester schrieb:

    und ist damit kein syntaktischer Zucker, oder?

    Nein, es ist kein syntaktischer Zucker. Es ist aber umgehbar.

    Könnten wir die Diskussion vielleicht auslagern, damit wir uns hier weiter um OOP streiten bzw. das Thema langsam mal begraben können?
    Danke.



  • clan der oop-ritter schrieb:

    [...] Sry, das ist Informations Hidding und nicht Kapselung!!!!

    aqivalent mit folgend Code: [...]

    Nachdem du es anscheinend immer noch nicht kapieren willst, frag ich mich langsam ernsthaft, ob du auch verstehst, was du schreibst (siehe z.B: Wikipedia für eine Beschreibung von Information Hiding).

    http://en.wikipedia.org/wiki/Information_hiding schrieb:

    In modern programming languages, the principle of information hiding manifests itself in a number of ways, including encapsulation (given the separation of concerns) and polymorphism.

    Von mir aus kannst du ja weiterhin Blödsinn reden, aber bitte spiel dich dabei nicht so auf.

    The term encapsulation is often used interchangeably with information hiding, while some make distinctions between the two.

    Du darfst kern selbst Google, worin der Unterschied liegt.
    Ah ne ich Quote was:

    Information Hiding - Informationen gezielt verbergen
    Kapselung - Verhalten eines Verhalten als Einheit

    Manchmal kann es für Sie notwendig sein, bestimmte kritische Infor-
    mationen oder Know-how-intensiven Code für andere Objekte oder
    Programmierer nur begrenzt offen zu legen. Sie wollen Informationen
    oder Daten ganz gezielt vor unerwünschtem Zugriff verbergen.
    Um dies zu erreichen, können Sie die Daten und das Verhalten eines
    Objektes zu einer Einheit zusammenfassen. Dies wird auch als Kapselung
    bezeichnet. Sowohl die Daten als auch Funktionen zur Änderung
    dieser Daten sind im Objekt enthalten. Sie können als Programmierer
    selbst definieren, ob die Daten nur über objekteigene Funktionen geändert
    werden dürfen oder von anderen Objekten frei änderbar und zugreifbar
    sind. Sie definieren damit die Schnittstellen zwischen verschiedenen
    Objekten. Damit können Sie Objektdaten vor unerwünschtem
    Zugriff gezielt schützen. Durch diese Kapselung können Sie Information
    Hiding nutzen.
    Mit der Kapselung und dem Information Hiding können Sie gleichzeitig
    auch die Komplexität von Programmen reduzieren, indem Sie un-
    wichtige Details eines Programms in Modulen, einer Art Blackbox, verstecken.
    Verschiedene Details interessieren den Benutzer dieser Objekte
    dann nicht mehr. Die damit verbundene Abstraktion verschiedener
    Problemstellungen kann zwar auch mit viel Arbeit verbunden sein, die
    jedoch im Nachhinein für Sicherheit und Zeitersparnis sorgt.
    Vollständiges Information Hiding kann auch ein Nachteil sein,
    da Sie dann nie direkt auf Daten zugreifen können (was sich z. B.
    bei schneller oder schlampiger Programmierung zeitsparend auswirken
    könnte) – meist ist dieser standardisierte Zugriff auf Daten jedoch von
    Vorteil, da Sie dadurch Fehler vermeiden und wichtigem Know-how
    einen sinnvollen Schutz bieten können.

    Warum ich das wie die einige darin einen Unterschied mache, weil Kapselung ein OOP Konzept ist, während hier um Forum schon bewiesen würde, dass Information Hidding in C zu realisieren.

    Man muss ja seine Daten verstecken um richtiges OOP betreiben also ist es unumgänglich bei der Kapselung Information Hidding durchzuführen, sonst kann man bei den strukturierent Programmiersprachen bleiben.



  • Jester schrieb:

    und ist damit kein syntaktischer Zucker, oder?

    es ist kein feature das notwendig ist. es bringt selbst keine neuen konzepte mit und erlaubt nicht etwas zu machen was ich ohne nicht auch machen koennte.

    alles was es tut ist dumme kleine fehler zu stoppen.

    @Zeus:
    du hast mehrfach gesagt das ziel von OOP ist es, dass daten von einem objekt privat sind. mit der argumentation hast du C code als nicht OO faehig abgetan.

    aber wir kommen vom hundertsten ins tausendste. es macht so keinen sinn mehr. weil alle nur noch vom wesentlichen ablenken.



  • Zeus schrieb:

    Man muss ja seine Daten verstecken um richtiges OOP betreiben also ist es unumgänglich bei der Kapselung Information Hidding durchzuführen, sonst kann man bei den strukturierent Programmiersprachen bleiben.

    exakt. genau das sagst du.

    ich habe gezeigt dass access control nicht zuverlaessig ist.
    weiters habe ich gezeigt dass es sprachen gibt die kein access control bieten (JS)
    und ich habe access control in C als beispiel gebracht.

    was willst du mehr?
    kapselung hat nichts mit access control zu tun - denn kapselung ist ein vertrag zwischen provider und client nicht in den interna rumzupfuschen. ob die sprache jetzt access control hat oder nicht - ich kann immer irgendwie in den interna rumpfuschen.

    es ist und bleibt ein vertrag an den sich beide seiten halten muessen. access control schuetzt gegen dumme bugs - aber gegen mutwilliges einbrechen in ein objekt schuetzt es nicht.

    btw:
    bestreitest du immer noch dass man in C OO programmieren kann?
    wenn nein, dann kapier ich nicht worauf du hinauswillst, wenn ja, dann stellst du dich ziemlich blind 😉



  • Nein Kapselung = Interne Daten (was in C++ und viele private darstellt) + Schnittstelle
    Graphisch ist ein Objekt eine Kern mit ne Schale.



  • Shade Of Mine oder zeus oder wer auch immer probleme wegen zugriffskontrollumgehung hat (tschuldigung wenn ich da wem jetzt falsch drinnen hab, langsam verlier ich hier den ueberblick wer mit was probleme hat bzw welche sieht, aber nach dem der text schon fertig is..)

    du hast eine lib, header mit nur den public methoden und von dem was unter private vom programmierer hingeschrieben wurde keine ahnung.

    meine persoenliche meinung, und die muss keiner teilen, ist das das effektiv genug is um programmierer vor denen man angst haben muss zugangszukontrollieren, bzw um interne komponentenablaeufe die "geheim" bleiben solln zu verstecken und das der rest der diskussion zum thema umgehung der zugriffskontrolle bei c/c++, der ja nicht zu knapp ist, naja, sag ma halt mal viel zu lesen is und ein bissl marketingblablabla verseucht is(zumindest hab ich schon vor einiger zeit einiges hier gelesenes bei marketingveranstaltungen gehoert)
    weil ob und was sicher is fuer jemand dem der src code zu verfuegung steht is theoretischer nonsens, weil der kann sowieso machen was er will, so wie bei allen anderen sprachen auch.
    auch sich ins knie schiessen oder zeit damit zu verschwenden um wege zu finden wie er den compiler am besten ueberlistet (was meist auch ein schuss ins knie ist).
    das hat jetzt zwar alles nix bis recht wenig direkt damit zu tun ob und oder was oop is oder nicht und wie viel davon eigentlich hirnwixerei ist, aber egal, mir war grad danach das jetzt zu schreiben, und was in dem thread jetzt eigenlich wirklich das thema is weis glaub ich eh keiner grad so genau



  • Zeus schrieb:

    Nein Kapselung = Interne Daten (was in C++ und viele private darstellt) + Schnittstelle
    Graphisch ist ein Objekt eine Kern mit ne Schale.

    kann man in C oo programmieren, ja oder nein?

    daHa schrieb:

    weil ob und was sicher is fuer jemand dem der src code zu verfuegung steht is theoretischer nonsens, weil der kann sowieso machen was er will, so wie bei allen anderen sprachen auch.

    du brauchst in c++ keinen source code. dir reicht die header datei - die ja vorhanden sein muss wenn du die library verwenden willst.

    und da stehen alle interna drinnen.

    wir koennen jetzt auf pimpl setzen und haetten exakt das was wir auch in C haben.



  • unter c kann man durchaus richtig objektorientiert programmieren

    diverse libs und betriebssystemkernel machen das ja zur genüge

    die syntax ist dabei aber etwas unscheon, da man die objektinstanz explizit an die funktionen übergeben muss - das ist besonders bei polimorphie grausam

    normaler call:

    methode(objekt)
    

    polimorpher call:

    objekt->methode(objekt,parameter)
    

    es fehlt halt der ganze syntaktische zucker wie implizite übergabe von this, methodenaufruf am objekt, sowie public/private



  • Shade Of Mine schrieb:

    Jester schrieb:

    und ist damit kein syntaktischer Zucker, oder?

    es ist kein feature das notwendig ist. es bringt selbst keine neuen konzepte mit und erlaubt nicht etwas zu machen was ich ohne nicht auch machen koennte.

    alles was es tut ist dumme kleine fehler zu stoppen.

    Im wesentlichen schon. Trotzdem wehre ich mich dagegen, daß es nur syntaktischer Zucker ist. Syntaktischer Zucker macht nur, daß es schöner aussieht, das hier hilft aber auch Fehler zu vermeiden.



  • ich würde sagen solche sachen wie source-level access-controll sollte man als syntaktischen zucker mit semantischen effekt einordnen, da man sie programmtechnisch umgehen kann



  • Der Einsatz von C schließt Objektorientierung nicht aus

    Eine Werkzeugunterstützung für die Codegenerierung ist zwingend
    notwendig

    Beides aus ne Präsentation Uni Erlangen

    Ich wünsche viel spass 😉



  • r0nny schrieb:

    syntaktischen zucker mit semantischen effekt

    😃 Was nun, Syntax oder Semantik? Semantischer Zucker?



  • Zeus schrieb:

    The term encapsulation is often used interchangeably with information hiding, while some make distinctions between the two.

    Nette Anmerkung, die auch stimmt, bestätigt allerdings nur was ich ohnehin bereits gesagt habe. Informating Hiding muss sich nich zwangsweise nur durch Kapselung erkennbar machen, denn auch z.B: das Arbeiten mit Schnittstellen statt Klassen stellt in gewisser Weise ein Information Hiding dar. Somit sollte auch klar sein, dass Information Hiding ein "abstrakteres" Konzept als Kapselung ist.

    Zeus schrieb:

    Du darfst kern selbst Google, worin der Unterschied liegt.

    Nachdem dein Zitat das in keinster Weise macht, beziehe ich mich dabei einfach auf einen Artikel (bei dem sich auch meine Aussage im ersten Absatz bestätigt).

    http://www.javaworld.com/javaworld/jw-05-2001/jw-0518-encapsulation.html schrieb:

    Encapsulation is a language construct that facilitates the bundling of data with the methods operating on that data. Information hiding is a design principle that strives to shield client classes from the internal workings of a class.

    Zeus schrieb:

    Warum ich das wie die einige darin einen Unterschied mache, weil Kapselung ein OOP Konzept ist, während hier um Forum schon bewiesen würde, dass Information Hidding in C zu realisieren.

    Man muss ja seine Daten verstecken um richtiges OOP betreiben also ist es unumgänglich bei der Kapselung Information Hidding durchzuführen, sonst kann man bei den strukturierent Programmiersprachen bleiben.

    Du verwechselst Kapselung und Information Hiding massivst, denn man kapselt um Informationen zu verstecken und nicht umgekehrt (so wie du anscheinend behauptest). Wie also bereits erwähnt ist Information Hiding ein Konzept, dass Kapselung umfasst, aber eben nicht nur Kapselung.


Anmelden zum Antworten