OOP mal wieder
-
Noch vor fünf Jahren hätte ich auch der Aussage zugestimmt, daß man halt kleine Projekte ebenso gut in C schreiben kann, größere Sachen dann in C++. Rückblickend war es aber gerade diese Einstellung die dazu geführt hat, daß meine Projekte immer eher eine Art Misch-Masch aus OOP und prozeduralem Denken wurden, was sich immer gerächt hat. (Und ich spreche hier mit gut 25 Jahren Programmiererfahrung)
Ich denke, man sollte C und C++ als zwei unabhängige Sprachen betrachten und sich entscheiden, endweder C oder C++ zu programmieren. Und wenn man sich für C++ entscheidet, sollte man auch konsequent alles in OOP machen. Dabei geht es weniger um die Frage, ob das bei "kleineren" Projekten jetzt sinnvoll ist oder nicht, sondern es geht darum sich an OOP zu gewöhnen, es richtig zu lernen.
Interessanetrweise hat mich gerade ein einjähriger (beruflich bedingter) Ausflug in C# dazu gebracht über meinen C++ Stil nachzudenken. Und auch wenn die folgende Aussage natürlich subjektiv ist, C# hat mich zu einem besseren C++ programmierer gemacht...
Bei der OOP geht es (imho) nicht darum, Klassen zu benutzen. es geht vielmehr darum wie man an Problemlösungen herangeht und wie man seinen Sourcecode organisiert. Das sollte man gerade an kleinen Projekten lernen bevor man anfängt es in großen Projekten anzuwenden.
Nebenbei bemerkt, es ist noch lange kein OOP nur weil man ne Klasse benutzt. OOP hat weniger mit der Sprache zu tuen, sondern mit der Art wie man sie anwendet. Letzeten Endes kann man sogar in good old C ojektorientiert programmieren, wenn auch sehr mühselig weil die Sprache selber das nicht unterstützt. UMgekehrt kann ich selbst in C# procedural Programmieren wenn ich das wollte... Es gibt keine "objektorientierten Sprachen", es gibt nur Spachen die Objektorientierung unterstützen, manche mehr, manche weniger.
-
schue schrieb:
Noch vor fünf Jahren hätte ich auch der Aussage zugestimmt, daß man halt kleine Projekte ebenso gut in C schreiben kann, größere Sachen dann in C++. Rückblickend war es aber gerade diese Einstellung die dazu geführt hat, daß meine Projekte immer eher eine Art Misch-Masch aus OOP und prozeduralem Denken wurden, was sich immer gerächt hat. (Und ich spreche hier mit gut 25 Jahren Programmiererfahrung)
Ich denke, man sollte C und C++ als zwei unabhängige Sprachen betrachten und sich entscheiden, endweder C oder C++ zu programmieren. Und wenn man sich für C++ entscheidet, sollte man auch konsequent alles in OOP machen. Dabei geht es weniger um die Frage, ob das bei "kleineren" Projekten jetzt sinnvoll ist oder nicht, sondern es geht darum sich an OOP zu gewöhnen, es richtig zu lernen.
Interessanetrweise hat mich gerade ein einjähriger (beruflich bedingter) Ausflug in C# dazu gebracht über meinen C++ Stil nachzudenken. Und auch wenn die folgende Aussage natürlich subjektiv ist, C# hat mich zu einem besseren C++ programmierer gemacht...
Bei der OOP geht es (imho) nicht darum, Klassen zu benutzen. es geht vielmehr darum wie man an Problemlösungen herangeht und wie man seinen Sourcecode organisiert. Das sollte man gerade an kleinen Projekten lernen bevor man anfängt es in großen Projekten anzuwenden.
Nebenbei bemerkt, es ist noch lange kein OOP nur weil man ne Klasse benutzt. OOP hat weniger mit der Sprache zu tuen, sondern mit der Art wie man sie anwendet. Letzeten Endes kann man sogar in good old C ojektorientiert programmieren, wenn auch sehr mühselig weil die Sprache selber das nicht unterstützt. UMgekehrt kann ich selbst in C# procedural Programmieren wenn ich das wollte... Es gibt keine "objektorientierten Sprachen", es gibt nur Spachen die Objektorientierung unterstützen, manche mehr, manche weniger.

mir ging es mit java und c++ ähnlich
-
Okay....
SqwanUF@hotmail.de
282251074 <-- und icq@helfer und alle anderen dies interessierd
Bin aber Männlich...
Habe aber auch schon post bekommen wo Frau Marian ... darauf stantUnd schon mal danke für die tipps...
Waren doch alle iwie hilfreich und leicht verständlich...Vllt kann ja auch mal einer sagen mit welchem projekt er/sie in OOP eingestiegen ist.
-
http://www.amazon.de/Objektorientierte-C++-Anwendungen-Booch-Methode/dp/3827295203
"alt" aber gut.
leihen reicht, gibt es sicher in uni bibliotheken oder gut sortierten stadtbibliotheken.
-
also wir hatten mal folgendes bzw ähnliches prog in der schule.
#include <conio.h> #include <stdio.h> void lauflicht1(); void lauflicht2(); void lauflicht3(); void main() { char a; a=getch(); switch(a) { case 'a': lauflicht1(); break; case 'b': lauflicht2(); break; case 'c': lauflicht3(); break; default: printf("Hammer net"); break; } } void lauflicht1() { printf("A"); } void lauflicht2() { printf("B"); } void lauflicht3() { printf("C"); }die lauflicht sind erstmal weg...
erstens sind se dann kürzer und zweitens brauchten wir dafür die conioex.h und die hat nicht jeder...vllt kann ja dieses prog mal einer alls kleines BSP oop schreiben...
ich versuche das dann mal auf alles umzusetzen...
Vllt hilft mir das weiter
-
Ich hoffe ich habs jetzt nicht allzu umständlich gelöst:
//-----------------------------------Header------------------------------------- #include<iostream> #include<conio.h> using namespace std; //-----------------------------------Klasse------------------------------------- class Clichter { public: void machlicht(); void input(); Clichter(); ~Clichter(); private: char lichtart; }; //----------------------------------Methoden------------------------------------ Clichter::Clichter() { lichtart='x'; } Clichter::~Clichter() { }; void Clichter::input() { cout << "Lichtart: "; cin >> lichtart; } void Clichter::machlicht() { switch(lichtart) { case 'a': cout << "A"; break; case 'b': cout << "B"; break; case 'c': cout << "C"; break; default: cout << "Licht nicht verfügbar"; break; } } //---------------------------------Hauptprogramm-------------------------------- int main() { Clichter leuchte1; leuchte1.input(); leuchte1.machlicht(); getch(); return 0; }
-
Schlecht.
-
Ich kann nicht beurteilen obs schlecht ist...
Aber vllt machst du es besser...
Den meckern kann selbst ich obwohl ich von vielen sachen keinen plan habe@Shilka
Muss ich glade mal durcharbeiten und rumtesten...
-
Das hat nichts mit glade zu tun, objektorientiere Programmierung benötigt nicht zwangsläufig ein WinAPI. Es hat nicht mit irgendeiner Art von Grafikinitialiisierung zu tun. Sicher, es wird dafür verwendet, aber dieses Programm ist zum Beispiel OOP rein in der Commandline

-
Das ist wirklich schlecht.
Nur alles was vorher ohne Klassen da stand jetzt in Klassen zu packen hat nichts mit OOP zu tun.
http://en.wikipedia.org/wiki/State_pattern
-
Objektorientiert = Mit Objekten arbeiten
Imho ist es vllt nicht der schönste Lösungsansatz, aber ich wollte, dass es nach aussenhin noch verständlich bleibt. Wenn du einen besseren Vorschlag hast lass hören, aber irgendwie seh ich hier nur kritik und keine alternativ Variante.
-
Und da bin ich wieder bei meinem ausgangsproblem...
Alles was ohne Klassen ist in klassen schreiben finde ich in jedem tut...
Nur leider/zum Glück/wie auch immer scheint das nicht so zu sein...Allerdings kann/hat hier niemand einen richtigen quellcode gepostet...
Das würde vllt einiges Klarer machen...
wäre nett wenn denn einer der es in richtigerem/besserem/oder wie auch immer oop kann mal so posten könnte...
-
Der grundlegende Code ist nicht wirklich geeignet um ihn zu "übersetzen".
-
--- schrieb:
Der grundlegende Code ist nicht wirklich geeignet um ihn zu "übersetzen".
Achja - Weil du das sagst ist das so?
Man nimmt eine Klasse Lauflicht, den Konstruktor private und das switch setzt man als Factory Pattern um.
Inwiefern das dann ein sinnvolles Programm ist, ist eine andere Frage.
-
@Entwickler
Könntest du das mal machen?
Mir würde das sehr helfen...
MFG
-
Sqwan, zäun das pferd nicht von hinten auf.
das schreiben einer klasse ist einfach und du sagtest, du kannst es.
beschäftige dich jetzt mit dem programmierkonzept, also: was ist objektorientiertes design. und das unabhängig von einer konkreten sprache.viel spaß beim forschen.
-
Sqwan schrieb:
@Entwickler
Könntest du das mal machen?
Mir würde das sehr helfen...
MFGeigentlich hatte ich mir überlegt vlt. noch euin bsp. zu bringen, aber...
-
och, man kann das lauftlicht progrämmchen schon mal OO auffassen und gucken, was dabei rauskommt.
es gibt ein licht. was ist das? ein gegenstand, der leuchten kann (nen buchstaben ausgibt). er selbst kann eigentlich nur leuchten, er kann sich wahrscheinlich nicht selbst anknipsen und schon gar nicht wird er den benutzer fragen, ob er leuchten soll.
das licht ist also schlicht ein datencontainer, der über sich selbst weiss, wie er heisst (in welcher farbe er leuchtet) und das auch preisgeben kann.
class Licht { private: string name; public: Licht(string name); string getName(); };aber wie leuchtet so ein licht? muss wohl in einer fassung sitzen und diese fassung wird durch irgendwas kontrolliert. da es sich um ein lauflicht handeln soll und je nach eingabe ein anderes licht aktiviert wird, handelt es sich dabei höchst wahrscheinlich um ein einzelnes gerät, welches alle lichter steuert und dazu auch über das vorhanden sein der lichter bescheid weiss. nennen wir ihn mal lichtkasten. um diesen lichtkasten "füllen" zu und mit ihm interagieren zu können, spendieren wir ihm methoden, um lichter hinzuzufügen, deren anzahl abzufragen und ein licht gezielt umzuschalten.
class Lichtkasten { private: vector<Licht> lichter; public: void addLicht(Licht licht); int lichtCount(); void toggleLicht(int index); };für "benutzerfreundlichkeit" wäre es womöglich noch schön, an das jeweilige licht direkt heranzukommen. oder die lichter mittels namen ansprechen zu können. das kommt je auf die verwendung an. dieser lichtkasten hier kann anonym durch seine lichter schalten.
nun gibt es lichter und einen lichtkasten, der diese kontrollieren kann. super, wie soll er nun angesprochen werden? automatisch oder per benutzereingaben? laut beispielprogrämmchen mittels benutzereingaben. also können wir uns eine klasse basteln, die benutzereingaben handhabt und dadurch den lichtkasten steuert.
class BenutzerInterface { public: void setControls(Lichtkasten kasten); bool getUserInput(); };getUserInput() ist hier so konzipiert, dass es solange true liefert, wie der benutzer gültige eingaben tätigt.
wie man das ganze nun zusammenklebt bleibt jedem selbst überlassen. c++ typisch kann man für so ein kleines programm alles in der main() zusammenkleben und dann ausführen.
int main() { Lichtkasten lk; lk.addLicht(Licht("A")); lk.addLicht(Licht("B")); lk.addLicht(Licht("C")); BenutzerInterface ic; ic.setControls(lk); while(ic.getUserInput()); }"wahre" OO jünger streiten sich übrigens darüber, ob in der main "soviel" code stehen darf. oder ob das nicht schon wieder nicht OO ist. aber als grundsätzliches beispiel für einen OO ansatz fand ich das nu gar nich so schlecht

-
Ok... das bsp finde ich sehr sehr gut...
Allerdings verstehe ich nicht was dieses vector macht...
vllt kann das noch mal kurz einer erklären...
Google sacht mir da so nen zeuch mit 3 diminensionalem raum im koordinatensystem
-
Sqwan schrieb:
Google sacht mir da so nen zeuch mit 3 diminensionalem raum im koordinatensystem
Das ist ein Vektor im mathematischen Sinne, hier ist es einfach ein Array aus der Std-Bibliothek
