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

Hab grad zu viel intus um auf Shade einzugehen.
Aber der Code oben ist ein Witz.

Ich würde dir generell empfehlen, dass du ein wenig nachdenkst, bevor du irgend etwas antwortest (selbst wenn du was intus hast), denn es war lediglich Datenkapselung gefordert.

Zwar ohne die Vorteile von zB Vererbung, [...]

Hast du überhaupt schonmal in Erwägung gezogen, dir die Argumente der anderen auch nur ansatzweise durchzulesen? Im Zuge der Diskussion wurde bereits mehrmals auf ein Dokument verwiesen, dass objektorientierte Programmierung in C genauer beschreibt und so eben auch Vererbung.

obwohl was hindert mich daran zB #include foo.c zu schreiben ?

Genau der selbe Bereich im Verstand, der dir auch bei einem #define private public ein seltsames Gefühl in der Bauchgegend verschafft.

Außerdem lässt sich sowieso eine Verständnisschwäche von OOP erkennen, wenn man auf derartig "konkrete Klassen" wie MenuDatei, MenuBearbeiten, etc.. fixiert ist.

rüdiger

DEvent schrieb:

Doch das ist OOP. Zwar ohne die Vorteile von zB Vererbung, aber im Grunde ist es OOP.

Auch das ist möglich. Aber lies dir mal das Buch "OOP with ANSI C" durch (ein Link auf die PDF wurde hier übrigens 2mal gepostet)

Es hat Datenkapselung, obwohl was hindert mich daran zB #include foo.c zu schreiben ?

Wie wir gezeigt haben, kannst du auch in anderen Programmiersprachen die Zugriffskontrolle umgehen (selbst wenn du das #define-Beispiel nicht hinnehmen willst, ich habe ein Beispiel ohne #define gezeigt, welches du ja offensichtlich überlesen willst).

Aber das ist ja nicht was Shader als OOP bezeichnet.

Weil?

Aber im Grunde ist es Sinnlos sich mit dir zu unterhalten.

Zeus

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.

Jester

rüdiger schrieb:

Wie wir gezeigt haben, kannst du auch in anderen Programmiersprachen die Zugriffskontrolle umgehen (selbst wenn du das #define-Beispiel nicht hinnehmen willst, ich habe ein Beispiel ohne #define gezeigt, welches du ja offensichtlich überlesen willst).

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

volkard

für die javaprogrammierer folgt hier ein ansatz, der wo nicht so kompliziert sein tut.

ein ahnunghaber nimmt ein problem mit OOA auf.
und ein zweiter ahnunghaber designed das programm mit OOD.
resultat sind ganz einfache anweisungen und viel UML.
dann kommen viele nichtanhnunghaber und codieren das.
die programmierer haben weder die berechtigung noch die möglichkeit,
am design entscheidendes zu ändern. ob die mit relativ wenig arbeit
das in java/c++ oder mit mehr arbeit in c/basic machen, ist egal.
selbst wenn sie ein mit UML entworfenes programm in assembler schreiben (und fast nix anderes macht der compiler am ende), bleibt es objektorientiert.
also kann man nicht an einem sprachmittel festmachen, ob das programm objektorientiert ist.

OOA=objektorientierte analyse
OOD=objektorientiertes design

Zeus

http://www.informatik.uni-bonn.de/III/lehre/vorlesungen/Informationssysteme/WS98/weitere_Themen/OO/FolienAlsHTML/sld004.htm

*hust*

net 0

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

volkard schrieb:

ob die mit relativ wenig arbeit
das in java/c++ oder mit mehr arbeit in c/basic machen, ist egal.
selbst wenn sie ein mit UML entworfenes programm in assembler schreiben (und fast nix anderes macht der compiler am ende), bleibt es objektorientiert.

es gibt auch uml-malprogramme die erzeugen gleich quelltexte, auch in nicht-oo sprachen. da braucht's nocht nicht mal einen, der codes rein hackt...

Jester

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

net 0

Jester schrieb:

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

nö, was ganz einfaches:

// diese klasse gibt's schon
class A
{
 // alles private
 int a;
 int b;      
};

// diese hilfsstruct braucht man für das casting
struct B
{
 // alles public
 int a;
 int b;       
};

...
  A a;
  a.b = 1234;         // geht nicht, weil private
 ((B*)&a)->b = 1234;  // geht
...

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

Zeus

Sorry Leute, aber
Objektorientierte Programmierung ist nicht wenn man eine nicht OOP Sprache an mich nehme und Code schreibt, der augenscheinlich die Definition von OOP erfült.
Den in der Programmierung steht die Sprache in Vordergrund.

Wenn ihr sagt ich hab eine OO-Umsetztung in prozedualen Programmiersprachen (OOP-like), dann würde ich es akzeptieren, denn eine Umsetztung ist wirklich sehr leicht.

OOP bringt Konzepte mit sich, um Beschreibung zu tätigen aus der Realen Welt.
Und bei euren Lösung ist recht technisch, viele Zeiger, funktionen,....

Der Vorteil ist doch die Einfachheit(ich meine damit nicht dass das Konzept einfach zu verstehen ist), wenn man so die Codebeispiele von ANIS C OOP sieht, bleibt aber nix übrig.

net 0

Zeus schrieb:

Denn in der Programmierung steht die Sprache in Vordergrund.

nee, das wär ja schlimm. die sprache ist nur ein werkzeug. wenn du einen teller suppe auslöffelst steht das stillen deines hungers im vordergrund und nicht der löffel

finix

Zeus schrieb:

Sorry Leute, aber
Objektorientierte Programmierung ist nicht wenn man eine nicht OOP Sprache an mich nehme und Code schreibt, der augenscheinlich die Definition von OOP erfült.
Den in der Programmierung steht die Sprache in Vordergrund.

Ach ja. Wie nennst du denn prozeduralen Code der in einer OOP-Sprache geschrieben ist?

Zeus schrieb:

Wenn ihr sagt ich hab eine OO-Umsetztung in prozedualen Programmiersprachen (OOP-like), dann würde ich es akzeptieren, denn eine Umsetztung ist wirklich sehr leicht.

Eine objektorientierte Umsetzung die der objektorientierten Programmierung quasi ähnlich ist, hm?
[/quote]

Shade Of Mine

Zeus schrieb:

Den in der Programmierung steht die Sprache in Vordergrund.

bei mir ist die sprache nur ein tool. ein hilfsmittel um den code zu schreiben.

manche sachen erleichtert sie mir, andere macht sie mir schwerer.

aber die sprache ist nur dumme syntax. nicht mehr.

ich kann in Java strukturiert programmieren und in C objekt orientiert.

Wenn ihr sagt ich hab eine OO-Umsetztung in prozedualen Programmiersprachen (OOP-like), dann würde ich es akzeptieren, denn eine Umsetztung ist wirklich sehr leicht.

OOP-like. was heisst das fuer dich. es ist genau wie OOP? ja, wenn es genauso ist, dann ist es dass ja. Wenn es danach riecht schmeckt und sich so anfuehlt...?

OOP bringt Konzepte mit sich, um Beschreibung zu tätigen aus der Realen Welt.
Und bei euren Lösung ist recht technisch, viele Zeiger, funktionen,....

Deine Loesung hat Klassen, Methoden, vtables,...
auch nicht wirklich viel untechnischer, oder?

lediglich dass C++ deine variante besser unterstuetzt und mehr tools dafuer bietet. in Javascript saehe es umgekehrt aus. da sind deine klassen wahnsinnig kompliziert zu machen...

Der Vorteil ist doch die Einfachheit(ich meine damit nicht dass das Konzept einfach zu verstehen ist), wenn man so die Codebeispiele von ANIS C OOP sieht, bleibt aber nix übrig.

ah, also wenn es kompliziert ist, ist es nicht echt?
template metaprogamming ist also nicht template metaprogramming weil es sau kompliziert ist und lisp es wesentlich leichter anbietet?

eine sprache ist ein werkzeug um dir zu helfen verschiedene konzepte zu verwenden. zB bietet dir C++ templates fuer statische polymorphie (nochmal: ich erfinde das nicht, dass ist ein teil von C++ ein grund warum C++ so maechtig ist - ich diskutiere jetzt sicher nicht darueber ob statische polymorphie auch polymorphie ist oder sonstwas. das ist ein konzept dass es schon lange gibt und C++ zB mit seinen templates unterstuetzt. das euch am bekanntesten beispiel ist sicher der operator+ der fuer zB int und double. das ist statische polymorphie. ocaml verbietet das zB und hat + fuer int+int und +. fuer double+.double - es sind einfach konzepte die es gibt. und nur weil ihr sie nicht kennt, sind sie nicht einfach schlecht. ein op+ fuer string und int mag fragwuerdig sein, aber sogar java kann diese minimale statische polymorphie, weil es manchmal einfach praktisch ist sie zu haben. C++ geht weiter und erlaubt diese polymorphie fuer mehr als nur die mathematischen operatoren.)

eine sprache bietet nun hilfmittel fuer gewisse konzepte. zB bietet C++ keine hilfe fuer Interfaces. Dennoch verwendet man manchmal welche. Aber nicht immer. Denn vieles macht man mit statischer polymorphie. zB das ganze Container Konzept der STL basiert darauf.

Aber obwohl mir C++ keine hilfe fuer interfaces anbietet, kann ich interfaces verwenden. Javascript bietet mir keinerlei hilfe fuer access control - aber ich kann es dennoch irgendwie simulieren. C++ bietet mir keinerlei hilfe fuer multimethods - aber ich kann es dennoch irgendwie simulieren. C bietet mir keinerlei hilfe fuer dynamische polymoprhie - aber ich kann es dennoch irgendwie simulieren.

und wollen wir jetzt code bewerten ob er OO ist, je nachdem wie schwer es war gewisse konzepte zu modellieren?

und @ http://www.informatik.uni-bonn.de/III/lehre/vorlesungen/Informationssysteme/WS98/weitere_Themen/OO/FolienAlsHTML/sld004.htm

javascript hat keine zugriffskontrolle und in C++ und Java kann ich sie recht simpel umgehen. und der rest ist gegeben. In C kann ich uebrigens den zugriff genau wie in JS verbieten indem ich die implementierung verstecke:

struct MyClass {
  void* impl;
};

struct MyClassImpl {
  int a, b;
};

MyClass* make_MyClass(int a, int b) {
  MyClass* c=malloc(sizeof(MyClass));
  MyClassImpl* impl=malloc(sizeof(MyClassImpl));
  impl->a=a; impl->b=b;
  c->impl=impl;
  return c;
}

und schon kann ich nicht mehr auf a und b zugreifen.
wenn jemand sagt dass man ja casten kann: MyClassImpl ist einfach nicht oeffentlich sondern liegt in einer .c datei.

fertig ist die kapselung.

sinnloser aufwand - denn mir persoenlich reicht der vertrag den ich schliesse wenn ich ein objekt erstelle, nicht in den innereien rumzupfuschen.

aber bitte, hier ist access control in C

Zeus

net schrieb:

Zeus schrieb:

Denn in der Programmierung steht die Sprache in Vordergrund.

nee, das wär ja schlimm. die sprache ist nur ein werkzeug. wenn du einen teller suppe auslöffelst steht das stillen deines hungers im vordergrund und nicht der löffel

Für eine Lösung ist die Sprache nur ein Werkzeug.

Zeus schrieb:
Sorry Leute, aber
Objektorientierte Programmierung ist nicht wenn man eine nicht OOP Sprache an mich nehme und Code schreibt, der augenscheinlich die Definition von OOP erfült.
Den in der Programmierung steht die Sprache in Vordergrund.

Ach ja. Wie nennst du denn prozeduralen Code der in einer OOP-Sprache geschrieben ist?

Für mich sind das keine Äquivalenzen.
Ich versuchs mal Veranschlaulichen in dem ich sage Objektorientierte Programmierung ist ein Hülle der prozeduale Programmierung.
Vielleicht macht es dann Click

Zeus

Shade Of Mine schrieb:

Aber obwohl mir C++ keine hilfe fuer interfaces anbietet, kann ich interfaces verwenden.

eh? Kauf dir ein Gutes C++ Buch, dass wird dir Interfaces in C++ zeigen.

Und auf dem Rest gehe ich nicht mehr ein.

Shade Of Mine

Zeus schrieb:

Für mich sind das keine Äquivalenzen.
Ich versuchs mal Veranschlaulichen in dem ich sage Objektorientierte Programmierung ist ein Hülle der prozeduale Programmierung.
Vielleicht macht es dann Click

fuer mich nicht.
Und ich nehme an die meisten OO freaks werden dich dafuer steinigen.

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

man kann sie mischen wo es sinn macht, aber sie sind grundverschieden.

ich denke du stehst noch am anfang was dein OOP verstaendnis betrifft. Das ist ok, es ist noch nie ein meister vom himmel gefallen. Spiel dich aber mal mit dem objekt system in lisp und javascript. und dann implementiere ne OO loesung in C.

ich denke dann wirst du deinen horizont erweitert haben.
OOP ist einfach mehr als Klassen + Funktionen.

Zeus

net schrieb:

Zeus schrieb:

Denn in der Programmierung steht die Sprache in Vordergrund.

nee, das wär ja schlimm. die sprache ist nur ein werkzeug. wenn du einen teller suppe auslöffelst steht das stillen deines hungers im vordergrund und nicht der löffel

Das ist wohl ein eigentor, ich hab doch mein Werkzeug damit ich mein essen kann.
also hab ich
1. Ein Löffel geholt
2. Esse ich die Suppe.

Shade Of Mine

Zeus schrieb:

eh? Kauf dir ein Gutes C++ Buch, dass wird dir Interfaces in C++ zeigen.

Und auf dem Rest gehe ich nicht mehr ein.

ich denke ich kann weitaus besser C++ als du.

sei nicht so arrogant.

C++ unterstuetzt interfaces nicht.
ein interface darf zB keinen code implementieren - in C++ kann ich das aber.
ich kann mit c++ klassen leicht einen deadly diamond of death bauen - der mit java interfaces nicht passiert waere.

etc.

C++ klassen sind keine interfaces.
ich kann sie dafuer missbrauchen - keine frage, aber c++ klassen sind dennoch keine interfaces: sie haben ihre eigenen staerken und schwaechen.

Shade Of Mine

Zeus schrieb:

net schrieb:

Zeus schrieb:

Denn in der Programmierung steht die Sprache in Vordergrund.

nee, das wär ja schlimm. die sprache ist nur ein werkzeug. wenn du einen teller suppe auslöffelst steht das stillen deines hungers im vordergrund und nicht der löffel

Das ist wohl ein eigentor, ich hab doch mein Werkzeug damit ich mein essen kann.
also hab ich
1. Ein Löffel geholt
2. Esse ich die Suppe.

und wenn du die suppe mit einem strohhalm ausdrinkst dann hast du deinen hunger nicht gestillt, richtig?

Zeus

Echt es gibst ein Meachnismus, was die Benutzung von Interface 100% in C++ entspricht.
Du kommst wieder mit C++ kann viel mehr deswegen gibst es nicht.