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

[daHa]

rüdiger schrieb:

@daHa
ich sag nicht, dass die Sprache schuld ist, sondern nur das Zugriffskontrolle sich effektiv nicht durchsetzen lässt.

soll ichs auch skandaloes finden das jemand der den src code hat alles moegliche damit auffuehren kann?

was machst wennst nur a lib mit headern hast wo nur die public drinnen stehn und du zugriffkontrolle umgehen wills/musst?
(ausser sinnvolles wie am besten den ersteller der lib zu kontaktieren und um entsprechende aenderungen zu ersuchen bzw sich um den src code zu bemuehen wenn moeglich)

wenn schon theoretische konstrukte diskutieren deren praxsisrelevater sinn fraglich bis diskussionswuerdig is dann bitte doch eher themen wos so leiwande akademische kunstbegriffe wie deadly diamond of death gibt, das liest sich wesentlich blumiger und macht sich auch bei praesentationen ungemein gut.

[volkard]

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)

[Shade Of Mine]

daHa schrieb:

soll ichs auch skandaloes finden das jemand der den src code hat alles moegliche damit auffuehren kann?

in C++ brauchst du nur die header, nicht den source code...

es geht darum dass einige leute OO Code damit definieren dass die sprache access control bietet. und wir zeigen hier lediglich dass access control in C++ nur syntaktischer zucker ist.

stichwort:
protecting against Murphy (zufall, pech, dumm gelaufen) vs. protecting against Machiavelli (absicht und vorsatz)

access control ist nett fuer die "murphy" situationen aber gegen eine "Machiavelli" situation - da bringt es nichts.

folglich kann OO nicht davon abhaengen ob es access control gibt, denn access control kann umgangen werden - und ist somit nicht verlaesslich.

man muss sich also immer auf den anwender des codes verlassen dass er da nicht rumpfuscht. on man jetzt access control in der sprache hat oder nicht...

[rüdiger]

daHa schrieb:

rüdiger schrieb:

@daHa
ich sag nicht, dass die Sprache schuld ist, sondern nur das Zugriffskontrolle sich effektiv nicht durchsetzen lässt.

soll ichs auch skandaloes finden das jemand der den src code hat alles moegliche damit auffuehren kann?

Nein, aber du könntest dir den Thread durchlesen, damit du wenigstens ansatzweise eine Idee davon hast, worüber hier diskutiert wird...

[daHa]

rüdiger schrieb:

daHa schrieb:

rüdiger schrieb:

@daHa
ich sag nicht, dass die Sprache schuld ist, sondern nur das Zugriffskontrolle sich effektiv nicht durchsetzen lässt.

soll ichs auch skandaloes finden das jemand der den src code hat alles moegliche damit auffuehren kann?

Nein, aber du könntest dir den Thread durchlesen, damit du wenigstens ansatzweise eine Idee davon hast, worüber hier diskutiert wird...

kurzfristig gings wohl auch um das was du geschrieben hast?
mittlerweile wurde der themenbereich zu zugriffskontrolle notwendig fuer oop aber eh wieder auf den punkt gebracht, der zugegebenermassen leicht aus den augen verloren werden kann, was ja auch dir, rüdiger, passiert is, weil wozu sonst zb dein bsp.
also hoff ich doch das du mir das nachsiehst, das ich da kurz ebenfalls den faden verloren hab bzw auf die abschweifungen eingegangen bin.

[THX 1138]

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?

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