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

[Zeus]

Shade Of Mine schrieb:

es geht darum dass einige leute OO Code damit definieren dass die sprache access control bietet..

Tschuldigung dass ich mich zu Wort melde, aber das machst nur du, ich glaub ich kann auch für andere reden(deEvent, gregor), dass Kapselung etwas zu tun hat, wenn man Ausdrücken kann das jene Daten in Beziehung zu diese Funktion stehen. Deswegen ist Information Hidding auch kein OOP.

Aber naja ich versteck mich gleich mal wieder, bevor mich paar Kugeln treffen ;o

[otze]

1310-Logik schrieb:

volkard schrieb:

daHa schrieb:

akademische kunstbegriffe wie deadly diamond of death gibt, das liest sich wesentlich blumiger und macht sich auch bei praesentationen ungemein gut.

und vor allem in übersetzungen, wo auf einmal diamanten statt rauten auftauchen. (nur eine weitere steigerung der silikonchips)

Hää? Was haben denn Silikon(!?!)chips mit Diamanten zu tun, ausser das die Elemente in der gleichen Hauptgruppe stehn? Oder was meinst Du damit?

er meint damit übersetzungsfehler.

diamond=raute/diamant
silicon=silizium/silicon

[THX 1138]

otze schrieb:

er meint damit übersetzungsfehler.

diamond=raute/diamant
silicon=silizium/silicon

ach so..

[Jester]

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.

[Shade Of Mine]

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

[Zeus]

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.

[Gregor]

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.

[Jester]

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?

[clan der oop-ritter]

[...] 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.

[rüdiger]

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.

[Zeus]

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.

[Shade Of Mine]

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.

[Shade Of Mine]

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

[Zeus]

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

[daHa]

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

[Shade Of Mine]

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.

[ronny]

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

[Jester]

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.

[ronny]

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

[Zeus]

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