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

Bashar

net schrieb:

klar ist das ein fauler trick aber in der praxis wird bestimmt kein c++ compiler aus zwei fast gleichen klassen (mit dem einzigen unterschied dass bei der einen alles public ist) unterschiedliche objekte im speicher erzeugen, so dass der cast immer funzen sollte.

Verletzt aber die One-Definition-Rule.

net 0

Bashar schrieb:

Verletzt aber die One-Definition-Rule.

ihr findet doch immer was...

Zeus

C++ ist nicht umsonst eine Multi-Paradigmasprache, der Entwickler steht in Verantwort das richtige zu machen

man programmiert objektorientiert, wenn man sich beim programmieren an objekten orientiert

Jester

net schrieb:

Bashar schrieb:

Verletzt aber die One-Definition-Rule.

ihr findet doch immer was...

Sag ich doch. :p

rüdiger

Jester schrieb:

net schrieb:

Jester schrieb:

#define private public ist afaik laut Standard verboten. Man darf keine keywords definen. Also fällt der Weg schonmal weg. Das andere was Du geschrieben hast ist natürlich genauso unportabel und undefiniert.

mit type-casts bekommt man aber jedes 'private' weg

Zeig mal bitte eine portable, standardkonforme Lösung um das private wegzukriegen. Ich bin gespannt. (Bitte keine Sonderfälle wie ne template-Funktion in der Klasse oder sowas).

Natürlich ist es nicht portabel binär auf eine Klasse zuzugreifen. Aber ich kann mir auch eine binäre Struktur in C ausdenken, die ich als Klasse benutze. Ändert für mich nichts an dem Punkt.

Aber dann meinetwegen folgender Code. Verstößt ja auch gegen den Zugriffschutz

class foo {
  int i;
public:
  int &bar() { return i; }
};

int main() {
  foo f;
  int &j=f.bar();
  j = 100; //perfekt legales C++ und umgeht die Zugriffskontrolle
}

daHa

dieser sred kann wirklich einiges

letztes schmankerl:

class foo {
private:
int i;
public:
int &bar() { return i; }
};

schuld is natuerlich die sprache, was sonst

Jester

Genau

rüdiger:

Sogar wenn Du die Referenz wegläßt kann man mit diesem "fiesen Trick" ja schon den Wert der Variablen auslesen.

Wo umgehst Du da jetzt *von außen* das private? Daß man von der Klasse aus kann ist klar, sonst wäre die Variable ja nicht benutzbar.

Ich bin gespannt, was noch an Vorschlägen kommt

Objektorientierung hat man nur bei der Verwendung von Vererbung, ansonsten wär es nur objektbasiert (so wie ältere Visual Basic Versionen z.B.)

rüdiger

Okay, war ein schlechtes Beispiel. War gestern wohl zu müde.

Aber btw finde ich nichts im Standard, was Shades #define verbietet. Ein Macro kann so wie ich das sehe jeder identifier sein.

meine Lösung ist so weit ich weiß Implementation-Defined-Behaviour und kein Undefined-Behaviour. Es ist also in Ordnung, ich muss eben nur auf einer anderen Implementierung nicht erwarten, dass das richtige rauskommt. Aber im Grunde ist es kein Thema so etwas für andere Implementierungen anzupassen oder zeig mir eine Implementierung, auf der etwas ähnliches nicht funktioniert.

Aber das führt zu weit von der Diskussion ab, was OOP jetzt ausmacht. Wie Javascript oder CLOS zeigen, ist es egal ob man Zugriffskontrollen hat oder nicht.

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

Shade Of Mine

rüdiger schrieb:

Aber btw finde ich nichts im Standard, was Shades #define verbietet. Ein Macro kann so wie ich das sehe jeder identifier sein.

du darfst keine keywords redefinen. steht irgendwo im standard.

finde das aber relativ uninteressant weil es praktisch immer geht. genau wie man vector vor dem TR1 schon als c-like-array benutzen konnte.

und kapselung != zugriffskontrolle

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