C++ Community

tuFx schrieb:

Es soll zwar kein 3d werden, aber aufwendige 2d Arenen etc.

Ein 3D-Browsergame? Na, da wärst du aber mit Skriptsprachen sehr schlecht bedient

tuFx schrieb:

Mit welchen Programmiersprachen kann man den auch Browsergames machen und sind nicht zu schwer?

Du kannst mit jeder Skriptsprache Browsergames basteln. Theoretisch sogar mit reinem Javascript und einem serverseitigen Backend. Aber das sei dir mal nicht empfohlen

Du kannst ASP.NET benutzen (von mir bevorzugt in Symbiose mit C# ;)), JSP, Perl, Python ... Wie gesagt. Es kommt darauf an, was du kannst und was es gibt. Niemand kann dir hier eine "perfekte Sprache" für dich nennen ...

thordk

unsigned long schrieb:

Mal ehrlich: Ich kenne keine OOP Sprache aus dem Stehgreif in dem man den Konstruktor des Vaters explizit aufrufen muss

java

LeGaN

thordk schrieb:

unsigned long schrieb:

Mal ehrlich: Ich kenne keine OOP Sprache aus dem Stehgreif in dem man den Konstruktor des Vaters explizit aufrufen muss

java

...macht das auch von selber

DEvent

unsigned long schrieb:

Also mal ehrlich, das was ihr in PHP "Objektorientierte Programmierung" nennt, nenne ich eher ein Armutszeugnis. Misserable und Fehlerhafte Umsetzung, kein friend, keine einheitliche Logik dahinter, Abstraktion ist ein Witz, dazu dieses ewige Abwärtskompatibel bleiben.

Mal ehrlich: Ich kenne keine OOP Sprache aus dem Stehgreif in dem man den Konstruktor des Vaters explizit aufrufen muss oder das eine abgeleitete Klasse, sich für die Basisklasse hält.

In Php5 hast du:
- Vererbung
- Kapselung
- und Laufzeitpolymorphie
Was brauchst du mehr fuer OOP?
Ausserdem ist friend der Bruch zu OOP, weil es die Kapselung bricht.

Was meinst du mit "keine einheitliche Logik"?
Das man den Ctor des Vaters explizit aufrufen muss, ist eine Designfrage der Sprache und nicht eine feste Regel der OOP. Abstraktion hast du in Php5, nicht mehr als in C# oder in Java.

Mit Php5 kannst du wunderbaren OOP-Code schreiben, das einzige was ich vermisse sind Namespaces. Du musst halt leider globale Funktionen aufrufen, aber das ist ja auch nicht so schlimm.

Also ich habe ein Web-Projekt als eine eine schoene State-Maschine in php5 geschrieben. Ergibt einen schoenen sauberen Code, der auch leicht erweitern laesst.

ronny

friend ist doch kein bruch der kapselung

es fügt lediglich eine funktion zum interface der klasse hinzu

im übrigen benötigt oop keine kapselung
das pattern zugriffsschutz ist nicht immer notwendig/erwünscht, auch wenn es hilft einige fehler zur compile/run-time zu finden

DEvent

ronny schrieb:

friend ist doch kein bruch der kapselung

es fügt lediglich eine funktion zum interface der klasse hinzu

im übrigen benötigt oop keine kapselung
das pattern zugriffsschutz ist nicht immer notwendig/erwünscht, auch wenn es hilft einige fehler zur compile/run-time zu finden

Du kannst mit friend eine ganze Klasse zur einer anderen "hinzufuegen". Also hat die Klasse B aufeinmal vollen Zugriff auf die Interna der Klasse A. Das, finde ich, ist eine gravierende Verletzung der Kapselung und eben so der Abstraktion.

ronny

man muss doch dann das ganze explizit in klasse a angeben

sowas ist durchaus nützlich wenn bestimmte interna einer klasse für die andere benötigt werden, ohne das man dafür ein offenes interface anbieten will

DEvent

ronny schrieb:

man muss doch dann das ganze explizit in klasse a angeben

sowas ist durchaus nützlich wenn bestimmte interna einer klasse für die andere benötigt werden, ohne das man dafür ein offenes interface anbieten will

Genau, und das ist der Bruch zu OOP. Wenn man friend verwendet hat man eh meist einen Designfehler oder ist einfach faul. (C++ fuer operatoren ausgeschlossen, da gehts ja nicht anders und ist IMHO Designschwaeche von C++).

ronny

Nur was hat oop mit Zugriffsschutz am hut ? imho sind das 2 Konzepte die sich gut miteinander verwenden lassen aber nicht fest aneinander gebunden sind.

Nur dieser absolutismus immer ...

im übrigen sind kontrollierte interface-erweiterungen auf andere klassen/funktionen nicht weiter tragisch

rüdiger

DEvent schrieb:

Genau, und das ist der Bruch zu OOP. Wenn man friend verwendet hat man eh meist einen Designfehler oder ist einfach faul.

quatsch. Die Kapselung bleibt doch weiter erhalten. Man hat nur mehr Möglichkeit sie durchzusetzen.

DEvent

rüdiger schrieb:

DEvent schrieb:

Genau, und das ist der Bruch zu OOP. Wenn man friend verwendet hat man eh meist einen Designfehler oder ist einfach faul.

quatsch. Die Kapselung bleibt doch weiter erhalten. Man hat nur mehr Möglichkeit sie durchzusetzen.

Na wenn du meinst... Man gibt zwar einer Klasse die volle Kontrolle ueber eine andere Klasse, aber die Kapselung bleibt weiter erhalten jaja.

rüdiger

DEvent schrieb:

rüdiger schrieb:

DEvent schrieb:

Genau, und das ist der Bruch zu OOP. Wenn man friend verwendet hat man eh meist einen Designfehler oder ist einfach faul.

quatsch. Die Kapselung bleibt doch weiter erhalten. Man hat nur mehr Möglichkeit sie durchzusetzen.

Na wenn du meinst... Man gibt zwar einer Klasse die volle Kontrolle ueber eine andere Klasse, aber die Kapselung bleibt weiter erhalten jaja.

Wer sagt denn, dass die Kapselung nur auf eine Klasse beschränkt sein soll?

Aber wenn du lieber rumpöbeln willst, als zu argumentieren, dann verzieh dich einfach und raub nicht meine Zeit!

http://www.parashift.com/c++-faq-lite/friends.html#faq-14.2

If they're used properly, they enhance encapsulation.