OOP: soll man jetzt alles in ne Klasse packen oder watt?
-
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.
-
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?
-
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.
-
Zeus schrieb:
Echt es gibst ein Meachnismus, was die Benutzung von Interface 100% in C++ entspricht.
Zeig ihn mir.
-
*hust*
Neulich ist ja alles was in Vorlesungen präsentiert wird per Definition wahr, aber andererseits erfüllt mein Beispiel ohnehin die Anforderungen.
- Zugriff erfolgt lediglich über eine definierte Schnittstelle und wird auch durch die Sprache selbst sichergestellt
- Jegliche Änderung wirkt sich nicht auf andere Objekte aus, es gibt sowieso nur eins (Da hab ich doch gleich auch das Singleton Pattern miteingebaut, also mein Code muss ja objektorientiert sein
).
Wenn du trotzdem noch keine Kapselung erkennen kannst, hast du es eben einfach nicht verstanden, was aber gar nicht weiter schlimm ist.
-
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?
-
GPC schrieb:
Zeus schrieb:
Echt es gibst ein Meachnismus, was die Benutzung von Interface 100% in C++ entspricht.
Zeig ihn mir.
Ok hab mir ins eigene Bein geschnitten
Gibst wirklich net.
-
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.
-
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?
-
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.
-
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
-
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.
-
Ich weiss versteh eure Gedankengänge, allerdings akzeptiere ich diese nicht.
Naja was auch immer, viel spass
-
Zeus schrieb:
Ich weiss versteh eure Gedankengänge, allerdings akzeptiere ich diese nicht.
Naja was auch immer, viel spassreden 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.
-
Du, das hab ich schon XD und ich steite mich ja auch nicht um deine Erfahrung :)~
-
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.
-
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...
-
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.
-
Bashar schrieb:
Verletzt aber die One-Definition-Rule.
ihr findet doch immer was...