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

Zeus

volkard schrieb:

Zeus schrieb:

Und auf dem Rest gehe ich nicht mehr ein.

geh doch noch auf mein letztes posting ein, das mit UML.
haste da einen ansatz, das zu entkräften?

Kann man OO-Lösung prozduale lösen, im allgemeine Ja.

Zeus

Shade Of Mine schrieb:

OOP und strukturierte programmierung sind 2 unterschiedliche konzepte die nichts miteinander zu tun haben.

C selbst gehört zu den strukturierte Programmierungsprachen, wie gehört das nun zusammen dass ihr behauptet in C OO zu programmieren?

Shade Of Mine

Zeus schrieb:

C selbst gehört zu den strukturierte Programmierungsprachen, wie gehört das nun zusammen dass ihr behauptet in C OO zu programmieren?

du stellst dich etwas lern resistent an.

wir sagen doch die ganze zeit:
eine sprache unterstuetzt gewisse konzepte, manche besser, manche schlechter. der code ist es, der den paradigmen entspricht. ich kann OO code in C schreiben, auch wenn mir C nicht so stark dabei hilft. Genauso wie ich prozedualen code in java schreiben kann.

der einfachheit halber sagt man "C ist strukturierte programmierung" weil es die meisten konzepte dort unterstuetzt und es recht logisch erscheint dann strukturierten code dort zu schreiben. weil OO code dort einfach mehr aufwand bedeutet als in anderen sprachen.

aber ich kann dennoch OO code schreiben. das ist ja ein bewiesener fakt.

OOP ist kein layer um strukturierte programmierung. es ist etwas komplett eigenes, mit eigenen konzepten.

@C++ Interfaces:
tja, C++ kann keine interfaces. ist C++ jetzt Objekt Orientiert? Ich meine Interfaces sind doch das A und O der OOP oder?

Kann man OO-Lösung prozduale lösen, im allgemeine Ja.

lies volkards beitrag nochmal: du hast in UML genau die struktur vorgegeben. du kannst das jetzt nicht anders loesen ohne vom plan abzuweichen. du koenntest es natuerlich komplett anders implementieren - es gibt immer mehrere loesungen zu einem problem - aber dir wird das ganze in UML ja vorgegeben.

In Java wird es uU einfacher sein einen observer zu implementieren als in C - aber es geht. und das UML diagramm schreibt es dir so vor. also machst du es. und es klappt.

net 0

Shade Of Mine schrieb:

Zeus schrieb:

C selbst gehört zu den strukturierte Programmierungsprachen, wie gehört das nun zusammen dass ihr behauptet in C OO zu programmieren?

du stellst dich etwas lern resistent an.
wir sagen doch die ganze zeit:
eine sprache unterstuetzt gewisse konzepte, manche besser, manche schlechter. der code ist es, der den paradigmen entspricht. ich kann OO code in C schreiben, auch wenn mir C nicht so stark dabei hilft. Genauso wie ich prozedualen code in java schreiben kann.

gib's auf. er schnallt's ja doch nicht

Zeus

Shade Of Mine schrieb:

@C++ Interfaces:
tja, C++ kann keine interfaces. ist C++ jetzt Objekt Orientiert? Ich meine Interfaces sind doch das A und O der OOP oder?

Nein Interfaces ist nicht das A und O der OOP

OOP hat ja auch gar kein A.

Zeus

Ich weiss versteh eure Gedankengänge, allerdings akzeptiere ich diese nicht.
Naja was auch immer, viel spass

Shade Of Mine

Zeus schrieb:

Ich weiss versteh eure Gedankengänge, allerdings akzeptiere ich diese nicht.
Naja was auch immer, viel spass

reden wir in 5 jahren nochmal drueber - nachdem du dir lisp, js, etc. angesehen hast.

nimm bis dahin einfach mal hin, dass leute wie volkard oder ruediger etwas mehr erfahrung haben als du.

in ein paar jahren wirst auch du es verstanden haben dass es sich bei OOP nur um objekte dreht und objekte ein abstraktes konzept sind. und dass es eben mehrere auspraegungen gibt wie sich objekte manifestieren koennen.

Zeus

Du, das hab ich schon XD und ich steite mich ja auch nicht um deine Erfahrung :)~

Jester

net schrieb:

ob's standardkonform ist??? aber es sieht so aus...

Ich finde nicht, daß es so aussieht. Du wandelst einen Pointer von einem Typ in einen anderen um. Das ist nie im Leben definiert, was da passiert, portabel ist es damit natürlich auch nicht. Es gibt schlicht keinen Standardkonformen Weg das zu tun.

net 0

Jester schrieb:

net schrieb:

ob's standardkonform ist??? aber es sieht so aus...

Ich finde nicht, daß es so aussieht. Du wandelst einen Pointer von einem Typ in einen anderen um. Das ist nie im Leben definiert, was da passiert, portabel ist es damit natürlich auch nicht. Es gibt schlicht keinen Standardkonformen Weg das zu tun.

okay, das 'aus class mach struct' war dumm gewählt. hätt' ich mal besser zwei classes genommen, wobei bei der einen alles public ist. 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. das 'private/public' hat ja nur während des compiliervorgangs eine bedeutung. später dann, im executable, ist 'private/public' nicht mehr vorhanden...

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