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



  • 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.



  • Die Variante, Funktionen außerhalb von Klassen zu lagern, die hier so massiv als OOP verteidigt wird, ist ja in jedem Fall eine Variante mit globalen Funktionen. Dazu hat ja volkard auch schon was geschrieben...

    volkard schrieb:

    byto schrieb:

    Aber wie groß ist der Anteil solcher Funktionalität in komplexen Softwareprojekten: < 1% oder doch <0.1% ?

    die selbstgeschriebenen globalen funktionen wiegen unter 10kbyte, egal wie groß die software wird.

    volkard schrieb:

    Gregor schrieb:

    Ich bin gerade mit einem kleinen C++Projekt beschäftigt und stelle zumindest bei mir fest, dass der Anteil der globalen Funktionen enorm ist. Hier sind gerade etwa 30/40 kByte globale Funktionen.

    ok, es mögen auch 40kByte werden. aber irgendwie hüpfen dann immer wiedermal ganze gruppen dieser funktionen doch in ne klasse rein. sofern man sich die zeit dazu nimmt, immer wieder mal aufzuräumen.

    Wie darf man denn das jetzt verstehen? Was ist denn jetzt der OOP-Weg, den man in C++ gehen sollte. Einmal wird dafür gestritten, dass es völlig in Ordnung und völlig OOP-like ist, die Funktionen so auszulagern, andererseits sagt volkard selbst, dass man das praktisch nicht macht, wenn man sauberen Code schreibt.

    Hä?! 😉 Könnt Ihr mir mal sagen, welche Meinung Ihr eigentlich vertretet? Ah, ich ahne es schon... Ihr verteidigt das ja als gute OOP-Variante, da C++ aber ne Multiparadigmensprache ist, betreibt Ihr eine Art der Nicht-OO-Programmierung, bei der die Funktionen in den Klassen landen. 😉 🤡



  • Gregor schrieb:

    volkard schrieb:

    ok, es mögen auch 40kByte werden. aber irgendwie hüpfen dann immer wiedermal ganze gruppen dieser funktionen doch in ne klasse rein. sofern man sich die zeit dazu nimmt, immer wieder mal aufzuräumen.

    Wie darf man denn das jetzt verstehen?

    du willst es nicht verstehen, und ich bin des erklärens müde.



  • volkard schrieb:

    und ich bin des erklärens müde.

    Spielverderber! :p



  • Ich will rüdiger, shadow, und etc.
    ne freunde bereiten 😛

    Ich habt ne Objektorientierung in C! aber halt kein OOP.



  • Was ist der Unterschied zwischen Objektorientierung und OOP?



  • Zeus schrieb:

    Ich will rüdiger, shadow, und etc.

    Welchem "shadow"?

    Ich habt ne Objektorientierung in C! aber halt kein OOP.

    hä?



  • Ich will rüdiger, shadow, und etc.
    ne freunde bereiten 😛

    Ich habt ne Objektorientierung in C! aber halt kein OOP.

    Zwar kann Ich ja schlecht für alle sprechen, aber ich wollte lediglich zeigen, dass OOP mehr ist als eine Sammlung von Features der Sprache. C bzw. C++ habe ich schon Jahre lang nicht mehr verwendet, wodurch ich also auch klarstellen will, dass ich C in keinster Weise verteidigen will. Ich wollte lediglich dazu animieren, wie meines Erachtens bereits erwähnt wurde, "über den Tellerrand zu blicken" um die Konzepte der Objektorientierung aus einer etwas anderen Perspektive zu betrachten. Mir erscheint allerdings ihr empfindet es als "Schlechtreden von OOP" wenn man versucht zu zeigen, dass es auch ohne entsprechende Sprachunterstützung bzw. sonstigen alternativen Lösungsansätzen möglich ist.

    Übrigens habe ich selbst genug Freude am Leben.



  • volkard schrieb:

    du willst es nicht verstehen

    QFT

    mir faellt uebrigens etwas auf:
    die harten verfechten von "klassen sind das A und O" haben alle keinerlei erfahrungen in anderen welten wie lisp, javascript und aehnlichen sprachen.

    das sollte zu denken geben. leute wie volkard und ruediger haben sich dagegen schon ne menge anderer sachen angesehen.

    ich will das jetzt einfach nur mal so stehen lassen. und die frage in den raum stellen, ob es neben java vielleicht doch noch mehr gibt das OO ist...


Anmelden zum Antworten