Prozedual bald Tot?
-
Tag,
Ich habe heute mal wieder die Stellenangebote in den Zeitschriften und im I-Net angeschaut.
Fast überall steht etwas wie: Programmieren sie in "OOP" blablabla.Da Frage ich mich ob es Programmiersprachen ohne OOP überhaupt noch lange gibt.
Ich finde es irgendwie übertrieben was die mit OOP machen, ok zugegeben für das ein oder andere Projekt ist es wirklich gut. Aber für jede gleinigkeit schreiben die Firmen so etwas wie "Programmieren sie in OOP".
Ich selbst habe bevor ich mit C++ rumgemacht habe nur Prozedual gearbeitet und fande das auch gut so, ich konnte damit auch alle Probleme lösen und wenn man schön einrückt war der Code auch übersichtlich und "wartbar".
Da frage ich mich warum nun fast jedes Unternehmen Leute mit "OOP" haben wollen.MFG ReduX
-
Ich selbst habe bevor ich mit C++ rumgemacht habe nur Prozedual gearbeitet und fande das auch gut so, ich konnte damit auch alle Probleme lösen und wenn man schön einrückt war der Code auch übersichtlich und "wartbar".
Da man jeden Code einrücken kann, ist das wohl kein Argument.
-
Dir ist wohl nicht ganz klar was wartbar eigentlich bedeutet.
Was wenn das kleine Projekt irgendwann weiterentwickelt wird und plötzlich größere Dimensionen annimmt?
-
Es gibt ja auch Programmiersprachen wo die Einrückung syntaktische Bedeutung hat. Des Weiteren werden wohl deshalb OOP-Kenntnisse verlangt, weil der Code damit meistens besser wartbar und wiederverwendbar ist. Natürlich kann man auch in OOP völlig grausligen Code produzieren den nach 1 Woche kein Mensch versteht, aber man kann es eben auch anders machen. Prozeduale Programmierung wird bei größeren Projekten ganz automatisch fast immer unübersichtlich und schlecht zu warten.
MfG
-
Es gibt noch so viele C Projekte, also erzähl doch bitte nicht sowas.
Solche Stellen sieht man natürlich nicht dort wo die 0815 Business Application-Stellen ausgeschrieben werden.Geh mal zu ner großen Firma wie IBM, die suchen Leute die noch C oder C++ können für ihre ganzen systemnahen Projekte.
-
ReduX schrieb:
Prozedual bald Tot?
Vielleicht. Aber ProzeduRal mit Sicherheit nicht!
-
naja "OOP" programmieren ist nicht alles
es geht darum modular zu programmieren
man kann c++ und java so programmieren dass es sich fast nicht von c unterscheidet im endeffekt oder c so gut programmieren dass es eh gleich gut ist wie oop
allerdings ist es nunmal leichter mit klassen modular zu programmieren als nur mit prozeduren da man da eben leichter in so codehaufen anstatt klar abgetrennte module verfällt
-
Prozedural lebt ewig schrieb:
Es gibt noch so viele C Projekte, also erzähl doch bitte nicht sowas.
man kann auch in c objektorientiert programmieren.
-
also, ich lerne da doch lieber direkt AOP, ich meine wenn es in 80 Jahren kein Code mehr in OOP gibt, lohnt sich doch gar nicht...
-
AOP ergänzt sich prima mit OOP, um technische Querschnittsbelange (Transaktionen, Autorisierung, Exception Handling, Logging, ...) von der Fachlogik wegzukapseln. Gehört in vernünftigen Sprachen zum Alltag. Dass irgendwann aber nur noch in Aspekten programmiert wird? Wird nie passieren...
-
Euch ist schon bewußt, daß auch OOP prozedurale Programmierung ist. Nur dat die Datenkapselung/organisation erweitert/verbessert wurde. Im Klartext: Innerhalb der Methoden wird doch im Prinzip prozedural vorgegangen.
-
Hi,
sicher ist procedural noch lange nicht tot. In der Microcontrollerprogrammierung wird sich das schon noch ne ganze Weile halten.
Auch bei einfachsten Progrämmchen, die nur aus ein paar Kommandozeilenargumenten was berechnen wäre es mit Kanonan auf Spatzen geschossen, wenn man da erst anfängt Klassen zu entwerfen. Das berechnet man und gut ist.
Auch bei bestimmten mathematischen Berechnungen, wo man aus einer Datei Werte rausliest, damit was berechnet und das wieder in ne andere Datei speichert muß es nicht in jedem Fall Sinn machen OOP zu verwenden. Aber spätestens, wenn man das gleiche in ähnlicher Form später noch mal anderswo berechnen will, sollte man sich fragen ob man nicht zu kurz gesprungen ist.
Das ist doch ähnlich wie mit ner Mutter die Kinder zu waschen hat. Bei Kleinstkindern (procedural) muß sie jedes einzelne von Kopf bis Fuß waschen, und das jeden Tag aufs neue.
Wenn die Kinder größer sind (OOP) bringt sie ihnen nur ein einziges mal bei wie man sich selber wäscht, und anschießend braucht sie blos noch zu jedem jeden Tag sagen "Wasch Dich".
Genau so ist es doch bei OOP. Alles was ich mehrfach brauche entwerfe ich einmal mit besonderer Sorgfalt und packe es in ene Kiste (Klasse) und wenn ichs wieder brauche, dann klopfe ich nur noch auf die Kiste.
Außerdem brauche ich mich immer nur mit dem zu beschäftigen, was mich gerade an der Stelle betrifft. Ich habe eine Klasse mit genau definierten Schnittpunkten zur Außenwelt (und zu anderen Klassen) und muß mir um keine sonstigen Abhängigkeiten Gedanken machen. Ich muß nicht erst überlegen, ob ich den Namen Berechne schon mal woanders verwendet habe, sondern nehme einfach das lokale berechne. Ich muß nicht BerechneKegel, BerechneKugel, BerechneWürfel,... auseinanderhalten. Und ich muß in BerechneKugeln nicht darauf achten, daß ich wirklich RadiusKugel nehme. Wenn Du dir das genau anguckst, ist es doch eigentlich schon eine implizite objektorientierte Programmierung, nur eben von Hand ohne Hilfe des Compilers. Mit dem Nachteil eines großen globalen Namensraumes, in dem mir irgendwann die Namen ausgehen und wo ich immer auf Kollisionen mit gleichlautenden Namen achten muß und durch die zusätzliche Spezifizierung ellenlange Namen bekomme.
Außerdem rechnet kein Programm nur zu seinem Selbstzweck. Wie sollen die Daten reinkommen, und wie sollen sie wieder ausgegeben werden. willst Du wirklich noch auf DOS-Ebene im Stile von
printf("Wollen sie weitermachen, tippen sie J oder N ein");
c = getchar( );
mit dem Nutzer kommunizieren?
Die ganzen graphischen Nutzeroberflächen (mit Ausnahme von direkten Win-Apis) sowie auch sämtliche Zugriffstools für Datenbanken, Excelblätter... sind heute objektorientiert gestaltet. Ohne OOP-Grundkenntnisse ist da nichts zu wollen.
Wie man dann konkrete Dinge auswertet/ausrechnet ist dann natürlich jedem selbst überlassen. für einfache Berechnungen lohnt es sich sicher nicht, da erst noch Klassenanzulegen, die rechnet man einfach aus.Im übrigen gibt es auch noch einen zweiten Grund, warum in allen Stellenbeschreibungen von OOP die Rede ist. Stelenausschreibungen sind nicht nur das was sie zu sein scheinen, sondern es sind öffentliche Aushängeschilder und Werbung für die Firma. Und wenn man die wichtige Firma XYZ ist, dann kann man schließlich nicht nur einfach einen Programmierer verlangen. Da muß man schon mal klarstellen, daß da nur die allerbesten für die eigene Firma in Frage kommen. Oder hast Du das nicht schon selbst gesehen, das eine riesige Stellenanzeige in der Zeitung steht, wo ganz ausführlich beschrieben wird was für eine international agierende Logistikfirma man doch ist und welche Bedeutung man im Weltrang hat und daß man nur die besten der besten beschäftigt, ... und irgendwo steht dann, daß man einen Hausmeister sucht oder einen Fahrer für die Sackkarre.
Gruß Mümmel
-
Tyrdal schrieb:
Euch ist schon bewußt, daß auch OOP prozedurale Programmierung ist. Nur dat die Datenkapselung/organisation erweitert/verbessert wurde. Im Klartext: Innerhalb der Methoden wird doch im Prinzip prozedural vorgegangen.
Jetzt verwechselst Du prozedural mit imperativ.
-
Tag,
Mich wundert nur eins, warum ist OpenGL nicht OOP?
Wenn OOP so gut sein soll und man mit OpenGL dann doch größere Projekte erstellt, warum muss man sich da dann mit C rumärgern?MFG ReduX
-
OpenGL 1.0 (1. Juli 1992) da war C++ noch nicht so in und man kam leichter an C Programmierer die richtig Kompetent waren u. gleichzeitig ASM konnten
-
ReduX schrieb:
Tag,
Mich wundert nur eins, warum ist OpenGL nicht OOP?
Wenn OOP so gut sein soll und man mit OpenGL dann doch größere Projekte erstellt, warum muss man sich da dann mit C rumärgern?MFG ReduX
Weil OpenGL Zustandsorientert ist und das in einer Prozeduralen Sprache leichter und besser realisierbar ist.
-
Direct3D beweist das Gegenteil.
-
OGL schrieb:
Weil OpenGL Zustandsorientert ist und das in einer Prozeduralen Sprache leichter und besser realisierbar ist.
Weil objekte keinen Zustand haben können, korrekt?
-
OpenGL ist halt eine richtige low-level API in der man quasi nur ein Objekt hat, die Zustandmaschine. Alle OpenGL Funktionen kann man als Methoden dieses Objektes betrachten und auf dessen Attribute kann man auch gar nicht direkt zugreifen. Man hat also wie bei einem OOP-Objekt nur getter/setter und man schickt Botschaften. Da es nur eine Zustandsmaschine geben kann, macht es auch keinen Sinn von dem Objekt zu erben oder neue Objekte zu erzeugen.
DirectX ist gar nicht mit OpenGL vergleichbar, denn DirectX ist ja weit mehr als nur eine Grafik-API. In DirectX hast du schon eine hoehere Abstraktionsschicht, dort hast du z.B. Mechs, Surfaces, Textures usw.
-
DEvent schrieb:
DirectX ist gar nicht mit OpenGL vergleichbar, denn DirectX ist ja weit mehr als nur eine Grafik-API. In DirectX hast du schon eine hoehere Abstraktionsschicht, dort hast du z.B. Mechs, Surfaces, Textures usw.
Nein, Direct3D ist ein Grafik-API, vergleichbar mit OpenGL. Höhere Mechanismen gibt es allenfalls in Direct3DX.