3. OOP mal wieder

OOP mal wieder

  • S

    Eh ja...
    ca 1.000.000 mal gehört
    ca 500.000 mal gesehen
    ca 100.000 Tutorials gesucht
    knapp die hälfte durchgearbeitet

    Anwennden kann ichs jetzt...
    Allderdings ohne Sinn und Verstand <-- Und beidens dann meistens auch noch als dualcore 2 duo im raid-verbund....
    Und extreme schwächen habe ich auch noch...

    Also wenn jemand lust hat mal ein wenig seiner zeit zu opfern, und auch noch MSN oder ICQ hat, kann er sich ´ja mal hier melden und ich poste MSN oder ICQ addy.

    THX... Wenn ihr nützliche tipps oder ähnliches zu OOP habt ist das natürlich trotzdem erwünscht...
    Besonders erklärungen wann es sinnvoll ist OOP zu nutzen...

    Auch links zu Tutorials die eurer meinung nach gut sind sind natürlich erwünscht....

    MFG Marian

    PS: Den weg zur SuFu habe ich bereits gefunden und auch gesehen das es schon themen on Mass gab zum thema oop... Allderdings nichts zum wirklichen praktischen einsatz

    0
  • S

    Besonders erklärungen wann es sinnvoll ist OOP zu nutzen...

    Das ist mehr oder weniger ne Glaubensfrage, theorhetisch kannst du jedes Programm, dass wenigstens 1 Funktion besitzt objektorientiert schreiben.

    0
  • S

    Und wieso macht man das nicht?
    Bzw wenn mans machen soll? wo ist der forteil es nicht normal zu schrieben...
    Warten lassen sich auch keine programme leicht.
    Und die laufzeit is da auch noch kein thema

    0
  • S

    Ich drücks mal so aus:

    Kleine Programme, werden je nach wohlfühlen entweder althergebracht oder objektorientiert programmiert, wenn du standardklassen verwendest fältl da nicht viel aufwand an, je in Abhängigkeit dazu wo du dich wohler fühlst.

    Große Programme, würde ich sagen Objektorientiert auf jeden Fall, ganz einfach, weil du ne Menge Code dir sparst. Aber die Frage ab wann ist ein Programm groß? Kann ich dir leider nciht beantworten, das liegt im Auge des Betrachters.

    Wenn man von klein auf OOP gelernt hat, ist die tendenz eben da alles mit OOP zu schreiben, wenn man davor noch die Basics hatte, wie gesagt da wo du dich wohler fühlst 🙂

    0
  • B

    Ich machs so:
    Will ich einfach ein paar Variablen bündeln, aber hab (noch) keine speziellen Funktionen, die hauptsächlich auf die Variablen abzielen, nehm ich ein struct.
    Wenn ich Daten habe (eine oder mehrere Variablen), für die ich extra Funktionen hab die (fast) nur was mit diesen Daten machen, dann nehme ich eine class.

    Passiert mir leider auch immer wieder, dass ich alles als Klasse darstellen will 🤡
    Ich denke nicht, dass eine eine generelle Regel gibt oder geben sollte, aber ich würde wirklich nur ungern auf stand-alone-Funktionen verzichten, a lá Java oder C#.

    Aber vielleicht als Richtlinie: Wenn du viele Sachen speziell zu einem Thema hast und es unübersichtlich wird, mach ne Klasse draus.

    0
  • ?

    Wo ist deine ICQ Nummer? Da du wahrscheinlich weiblich bist wollen dich wahrscheinliche viele adden! 😋

    0
  • ?

    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.

    0
  • ?

    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

    0
  • S

    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 stant

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

    0

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

    0
  • S

    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

    0
  • S

    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;
}
    0
  • ?

    Schlecht.

    0
  • S

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

    0
  • S

    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 😉

    0
  • ?

    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

    0
  • S

    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.

    0
  • S

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

    0
  • ?

    Der grundlegende Code ist nicht wirklich geeignet um ihn zu "übersetzen".

    0
  • E

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

    0
  • S

    @Entwickler
    Könntest du das mal machen?
    Mir würde das sehr helfen...
    MFG

    0
Anmelden zum Antworten