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

[Zeus]

Shade Of Mine schrieb:

Zeus schrieb:

OOP ist mindestens die Zusammenfassung von Daten und Funktionen, mit den Zugriff über Schnittstellen.

das habe ich aber.

ich habe die daten in einer struct und ich habe funktionen die auf diesen daten operieren.

Trotzdem kann jeder uneingeschränkt auf deine Daten zugreifen

Das JavaScript-Beispiel erfüllt es, weil private Eigentschaften möglich ist.

private ist zwingend noetig fuer OOP?
ich habe bereits bewiesen dass private ein illusion ist. sowohl in java als auch in c++ kann ich es umgehen...

Nein du hast ein C++ Werkzeug missbraucht.
Man kann alles umgehen, aber das ist auch nicht der Punkt der Diskussion
Für OOP muss deine Code paar Aspekte erfüllen, wie das nun eine Sprache hand habt ist total egal, deswegen versteh ich nicht warum du dich an die Accessspezifikationen aufhaltest.

btw: javascript kennt ebenfalls kein private. JS kann keine kapselung laut deiner definition. Man simuliert das ganze ueber nested functions die es erst seit js 1.2 gibt.

Du wiedersprichst mir, aber hab schon im post über mir geschrieben

aber gut, was du sagst ist, dass ich in C nicht objekt orientiert programmieren kann?

C,Pascal und Visual Basic bis 6 sind prozeduale Programmiersprachen

findest du es nicht komisch festzulegen ob etwas OO ist indem du ein bestimmtes sprach feature als unabdingbar definierst dass extrem leicht auszuhebeln ist?

Ich kann in Java OOP aushelben, trotzdem gilt die Sprache als der Vertreter von OOP. Objektorientiung findet in Design statt und dieses braucht Mechanismen in der Sprache um es zu unterstützen, sei is durch private datamember (c++/java/c#), __datamember(PHP-like) oder irgendeinen anderen.

zB kann man mit php4 wunderschoene java like OOP betreiben. obwohl es keine access controls gibt. in php5 kann ich die access controls auch total leicht umgehen...

und dennoch definiert sich OO dadurch dass es access controls fuer die daten gibt?

Nun bitte ich dich mal OOP zu erklären, und alle Definitionen dazu und wie es sich von prozeduale Programmierung unterscheidet.

[Gast]

Zeus schrieb:

aber gut, was du sagst ist, dass ich in C nicht objekt orientiert programmieren kann?

C,Pascal und Visual Basic bis 6 sind prozeduale Programmiersprachen

Trotzdem kann ich mit C objektorientiert programmieren. Was willst du uns sagen?

[byto]

findest du es nicht komisch festzulegen ob etwas OO ist indem du ein bestimmtes sprach feature als unabdingbar definierst dass extrem leicht auszuhebeln ist?

Ich kann ein Auto auch mit bloßen Händen schieben. Trotzdem bleibt es ein motorisiertes Fahrzeug.

Ich kann auch mit eine Pistole auf jemanden einprügeln. Trotzdem bleibt es eine Schußwaffe.

...

[Zeus]

TactX schrieb:

Zeus schrieb:

aber gut, was du sagst ist, dass ich in C nicht objekt orientiert programmieren kann?

C,Pascal und Visual Basic bis 6 sind prozeduale Programmiersprachen

Trotzdem kann ich mit C objektorientiert programmieren. Was willst du uns sagen?

Hättest du diese Aussage anhand von VB6 gemacht, müsste ich einlenken, aber mit C kann man keine OOP machen.

[GPC]

*Plonk* Klar kann man mit C OOP programmieren, schau dir nur mal gtk+ an. Polymorphie z.B. ist auch nur ein Pointer auf eine Tabelle mit Funktionszeigern...

[Gast]

Zeus schrieb:

TactX schrieb:

Zeus schrieb:

aber gut, was du sagst ist, dass ich in C nicht objekt orientiert programmieren kann?

C,Pascal und Visual Basic bis 6 sind prozeduale Programmiersprachen

Trotzdem kann ich mit C objektorientiert programmieren. Was willst du uns sagen?

Hättest du diese Aussage anhand von VB6 gemacht, müsste ich einlenken, aber mit C kann man keine OOP machen.

Warum nicht?

[Zeus]

Zeig mir Datenkapselung in C.

Zeus schrieb:

int zahl;

void set(int a)
{
    zahl = a;
}

int get()
{
    return zahl;
}

#include <iostream>
#include "lol.h"
int main()
{
    zahl = 1;
    std::cout << zahl;
	std::cout << "Hello world!" << std::endl;
	return 0;
}

Wenn das so auszieht, dann ist es kein OOP.

[Gast]

GPC schrieb:

*Plonk* Klar kann man mit C OOP programmieren, schau dir nur mal gtk+ an. Polymorphie z.B. ist auch nur ein Pointer auf eine Tabelle mit Funktionszeigern...

Ach du Spielverderber

[clan der oop-ritter]

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

[Zeus]

Das ist ein schlechter witz.

[Gast]

Es gibt wahrscheinlich zigtausend Quellen von OOP mit ANSI C im Netz.

Z.B.: www.planetpdf.com/codecuts/pdfs/ooc.pdf

[net 0]

Zeus schrieb:

Das ist ein schlechter witz.

stell' dir einfach vor die datei 'lol.c' wäre eine klasse und das 'static' sowas wie 'private'

[rüdiger]

http://www.planetpdf.com/codecuts/pdfs/ooc.pdf#search="object oriented programming in c"

@Zeus

#include <iostream>

class foo {
  int i;
  double d;
public:
  foo(int i=10, double d=10.5) : i(i), d(d) { }
};

int main() {
  foo f;
  std::cout << *reinterpret_cast<int*>(&f) << ' '
	    << *reinterpret_cast<double*>(reinterpret_cast<int*>(&f)+1) << '\n';
}

Wo ist deine Zugriffsspezifikation?

@rüdiger
Also ich hab mal gelernt, dass Methoden Funkionen oder Prozeduren sind, die an Objekten gebunden sind.
Und Nachrichten an Objekten geschickt werden.

Sowohl Funktionen und Prozeduren sind keine Methoden.

lass uns das mal genauer betrachten

...dass Methoden Funkionen oder Prozeduren sind... Sowohl Funktionen und Prozeduren sind keine Methoden.

Versteh ich nicht.

übrigens ist

void foo(bar);

nicht weniger an die Klasse bar gebunden, als

class bar {
//...
public:
void foo();
};

[rüdiger]

Zeus schrieb:

Das ist ein schlechter witz.

Wieso?

Hat doch alles was du gefordert hast.

btw. CLOS hat auch kein wirklichen Zugriffsschutz, wenn man keinen Accessor für ein Member definiert, dann kann man immer noch über die Funktion slot-values darauf zugreifen. Dennoch ist CLOS OOP.

[GPC]

TactX schrieb:

GPC schrieb:

*Plonk* Klar kann man mit C OOP programmieren, schau dir nur mal gtk+ an. Polymorphie z.B. ist auch nur ein Pointer auf eine Tabelle mit Funktionszeigern...

Ach du Spielverderber

:p

Am Ende ist auch der OOP-ste C++ Code Assembler, also kann keiner erzählen, dass man eine Technik von oben nicht auch weiter unten umsetzen kann.

[Shade Of Mine]

Gregor schrieb:

...und drehen wir die Diskussion doch mal um: Bisher wurde argumentiert, dass es nicht objektorientiert ist. Was spricht denn dafür, dass es sich um objektorientierte Programmierung handelt? Welche Kriterien werden diesbezüglich erfüllt, welche müssen erfüllt werden?

Eine Zeile kann nicht Objekt Orientiert sein. Soweit stimmen wir hoffentlich ueber ein.

Ein Konzept kann OO sein. einfach nur globale Funktionen zu haben ist erstmal nicht OO. Soweit sollten wir ueberein stimmen.

Betrachten wir aber nun swap(). swap() existiert erstmal garnicht. Es steht nur in der Doku: "um den algorithm sort() verwenden zu koennen muss ein Objekt swap() anbieten".

Nun denn: kein Problem: es ist statische polymorphie, dh ich brauche kein interface ISwapable. Ich koennte es zwar verwenden, aber da eh alles statisch ist, bringt es mir nichts. Es wuerde mir nur in zusammenhang mit reflection etwas bringen - was wieder etwas komplett anderes ist.

nun denn: ich definiere in meinem bitmap Objekt eine methode void swap(Bitmap& other);

alles ist fein. wir nehmen noch ein ISwapable interface dazu:

class Bitmap : public ISwapable {
...
  void swap(Bitmap& other);
};

wir haben jetzt natuerlich das problem dass wir ploetzlich laufzeit polymorphie brauchen:

class Bitmap : public ISwapable {
...
  void swap(Object& other);
};

und schon ist die statische typsicherheit dahin.
mit statischer polymorphie koennen wir aber folgendes machen:

class Bitmap {
...
  void swap(Bitmap& other);
};

dh, ich habe komplette statische typsicherheit. eben statische polymorphie. einfach nur ein anderes konzept als dynamische.

ich kann bei beiden varianten dann folgendes machen:

void foo(ISwapable& a, ISwapable& b) {
  a.swap(b);
}

template<typename T>
void foo(T& a, T& b) {
  a.swap(b);
}

stimmen wir jetzt ueberein dass beide varianten ebenbuertig sind? eine ist statisch, die andere dynamisch.

nun haben wir aber ein syntaktisches problem:

int a=1,b=2;
foo(a,b);

klappt nicht.

das ist doof. ich will naemlich dass das klappt.

also verwende ich einen trick: aus Bitmap::swap mache ich ::swap

class Bitmap {
...
};
void swap(Bitmap& a, Bitmap& b) {
...
}

das konzept ist komplett identisch mit Bitmap::swap. Ich habe nur die syntax geaendert.

das nette ist: ich kann jetzt

void swap(int& a, int& b) {
...
}

machen und mein foo funktioniert ploetzlich auf fuer alle builtins

ein anderes nettes konzept, dass mit Java Interfaces nicht geht, sind default implementierungen:

template<typename T>
void swap(T& a, T& b) {
  T c=a;
  a=b;
  b=c;
}

ich koennte zwar in ISwapable swap() eine defaultimplementierung verpassen, aber was wenn wir statt swap() jetzt einfach etwas neues erfinden:

template<typename T>
void inc(T& a) {
  ++a;
}

und schon habe ich fuer mein Bitmap inc() implementiert (vorausgesetzt es gibt einen ++ operator).

und ich kann inc() jederzeit spezialisieren wenn ich will.

aber es ist und bleibt nichts anderes als wenn ich jetzt ueberall ein IIncable interface implementiere. Nur dass statische polymorphie hier eben nett ist, waehrend bei sowas dynamische polymorphie einfach zu unflexibel ist.

was wir hier haben sind nichts anderes als ein interface fuer statische polymorphie.

ich weiss gregor, dass fuer dich etwas dass nicht existiert (naemlich ein konkretes interface) nicht gueltig ist - aber stell dir diese default implementierungen mit templates als abstrakt vor. dann hast du hier deine interface definition.

statische polymorphie ist eben etwas anderes als dynamische: da kann man nicht 1;1 die selben konzepte und regeln geltend machen.

javascript hat zB keine dynamische polymorphie im herkoemmlichen sinn, es gibt ja keine virtuellen methoden und klassen und interfaces sowieso nicht.

DEvent schrieb:

Komm du mal runter, nur weil du und volkrat und noch ein paar miteinader einer Meinung ist, heist es nicht das sie stimmt.

dann benimm dich wie ein erwachsener und mach mal n bisschen nachforschung bevor du ueber ein thema sprichst von dem du nichts verstehst.

auf deiner hp steht, dass du nur c++, java und c# kennst. na logisch dass du nicht weisst wovon wir hier reden. mag hart klingen, aber schau mal ueber deinen teller rand. hier hast du leute mit weitaus mehr erfahrung was sprach konzepte betrifft, als du sie hast.

Ich finde es komisch das du ein Sprachfeature hackst und dann behauptest das es nich gibt.

behaupte ich nicht.
lies bitte was ich schreibe.

es geht darum dass ein sprach feature nicht bestimmend sein kann ob der code OO ist oder nicht.

denn ich kann in assembler OO programmieren. und da habe ich keine sprachfeatures die mir dabei helfen.

Der Präprozessor ist ein einfacher Textersetzer, hat mit der Sprache C++ nicht viel zu tun. Erst wird alles durch die #defines ersetzt, dann erst kriegt der C++-Compiler den Code, den er kompiliert.

dann mach ich es per casts.
auch gut.

Zeus schrieb:

Ausserdem hab ich schon auf Javasvript aufgezeigt, dass es Datenkapseln kann. Du hingegen kommst wieder und behauptest das Gegenteil davon.

lies bitte was ich schreibe.
und ignorier nicht immer alles was dir nicht in den kram passt.

JS kann kein private oder aehnliches. es gibt 3 arten ein objekt zu definieren und 2 davon koennen keine private elemente simulieren. eine recht neue art objekte zu definieren kann dies simulieren indem sie scopes ausnuetzt.

es ist aber nichts was in der sprache vorgesehen ist und schongarnicht von anfang an dabei war.

in JS verwendet man deshalb auch idR keine private sachen, weil es sich unnatuerlich anfuehlt dort.

man kann es zwar simulieren, aber das kann ich in C genauso mit static.
zugriffskontrolle ist kein feature das JS unterstuetzt. zB gibt es keine moeglichkeit ein protected zu simulieren. private widerspricht auch ziemlich dem JS objekt konzept.

[gurkenesser]

gucktmal, sogar brainfuck kann oop: http://esoteric.sange.fi/brainfuck/bf-source/prog/oobrain.b

nee echt jetz allein dass der trhead hier 13 seiten hat zeigt doch dat ihr nix könnt

[DEvent]

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

Hab grad zu viel intus um auf Shade einzugehen.
Aber der Code oben ist ein Witz.
Wie willst du nun mehrere Objekte erstellen ? Auch wenn du static bei zahl weglässt, kannst du nicht mehrere Objekte habe.

behaupte ich nicht.
lies bitte was ich schreibe.

Du hast geschrieben das es keine Kapselung in C++ gibt, und als Grund hast du deinen Textersetzer genannt #define private public

statische polymorphie ist eben etwas anderes als dynamische: da kann man nicht 1;1 die selben konzepte und regeln geltend machen.

Was du statische Polymorphie nennst, nenne ich prozedurales Programmieren. Denn diese statische Polymorphie gab es schon weitaus länger, bevor irgendjemand überhaupt auf den Begriff OOP kahm.
Nimm den Schlüsselwort namespace weg, was hast du dann? Prozeduren oder Funktionen die global verfügbar sind, die aber als Parameter ein Objekt erwarten.
Sowas habe ich schon mit Pascal und Basic programmiert.

Wenn du nun Prozeduren und Funktionen hast, die statt Objekte einen Datenstrom (Stream) erwarten, nennt du es dann datenstromorientierte Programmierung ?

[rüdiger]

@DEvent
ob wäre das ein Problem.

//foo.h

struct foo;
struct foo *new_foo(int bar);
void delete_foo(struct foo *obj);

//public accessors
int get_bar(struct foo *obj);
void set_bar(struct foo *obj, int i);
int get_baz(struct foo *obj);

//Methoden
void calc_baz(struct foo *obj);

//foo.c
#include <stdlib.h>

struct foo {
  int bar;
  int baz;
  int secret;
};

struct foo *new_foo(int bar) {
  struct foo *obj = malloc(sizeof(struct foo));
  obj->bar = bar;
  obj->secret = 100;
  return obj;
}

void delete_foo(struct foo *obj) {
  free(obj);
}

int get_bar(struct foo *obj) { return obj->bar; }
void set_bar(struct foo *obj, int bar) { obj->bar = bar; }
int get_baz(struct foo *obj) { return obj->baz; }

void calc_baz(struct foo *obj) { obj->baz = obj->secret * obj->bar; }

Braucht kein Genie um das rauszufinden. Was daran ist nicht OO?

Btw. habe ich dir bereits aufgezeigt, dass du das C++ Accessor-System ohne #define umgehen kannst. Aber selbst mit #define wäre es ein legaler Weg, da der C++ Standard das erlaubt.

[DEvent]

Aber selbst mit #define wäre es ein legaler Weg, da der C++ Standard das erlaubt.

Dann ist der C++ Standard noch schlimmer als ich dachte und ich bin froh mit C++ aufgehört zu haben
Aber verflucht noch mal ich wollte eigentlich in eine Disco....