Ab wann ist OOP eigentlich wirklich OOP?
Ja Hallo erst mal,
was ist eigentlich richtiges OOP und ab wann ist es wirklich OOP? Simple Frage mit ganz viel Potential zum Antworten.
Den Sinn dahinter, nämlich die Wiederverwendbarkeit des Quellcodes habe ich insoweit verstanden. Aber wie gestaltet man den Code nun wirklich Objektorientiert und Sauber?
Ist es schon Objektorientiert wenn ich einige Daten (Methoden, Variablen - halt Code) in neuen Klassen auslagere? Wobei es da ja schon gleich anfängt; Wie benenne ich "Sinnvoll" die Klasse?
Und: Was kommt letzten Endes wirklich in die Klasse und was nicht?
Ist es Objektorientiertes Programmieren, wenn ich eine Klasse habe, von der ein Objekt erstelle und damit dann weiter arbeite? Oder ist das nur der Anfang vom OOP?
Ist es Sinnvoll Globale Variablen zu setzen? Sicher, in einigen Fällen schon, aber ich nutze sie, damit ich diese Parameter z.b. nicht jeder Methode übergeben muss.
Um eine Wiederverwendbarkeit des Quellcodes herzustellen, lagere ich auch einiges als Methoden aus. Ein Sprichwort besagt ja: "Don't repeat your self" - gut, das will ich mit dem Auslagern bewirken - mitunter ist dies aber auch nicht möglich, also doch doppelten Code schreiben. Dann ist es oftmals so, wenn ich eine Formsanwendung schreibe, wie greife ich auf Daten zu, wie auf die Formelemente? Beides soll ja schließlich getrennt sein.
Schlußendlich lagere ich paar Daten in Methoden und Klassen aus - gebe die Daten ggf. zurück an die Formsklasse und das war es dann auch schon. Meiner Meinung nach ist das aber kein sauberer, guter Objektorientierter Code, er funktioniert halt nur.
So - ich würde das gerne ändern, weiß aber nicht wie... Wie gesagt, mir fallen nicht mal sinnvolle Klassennamen ein. In einem Spiel ist es einfacher, da gibts dann die Klasse "Game", "Player", "Enemy" und dann halt paar andere noch. Allerdings wie die dann wiederum aufgebaut werden, sodass OOP entsteht, weiß ich nicht und das als FIAE im 2. Lj.
Bitte immer nur ein Thema pro Thread, hier also "Ab wann ist OOP eigentlich wirklich OOP?"
Hi,
zu aller erst könnten viele Deiner Fragen durch das Durcharbeiten von entsprechenden Grundlagen-Büchern wie C# OpenBook 🛈 schon beantwortet werden.
Was OOP ist wird zum Beispiel in Einführung in die Objektorientierung erklärt. Es gibt viele verschiedene Beschreibungen, sogar Diplomarbeiten, die dieses Thema mal mehr mal weniger tief behandeln.
Zum Beispiel PDF: Grundbegriffe der OOP mit Java-Beispiel ( Dipl.-Math. E. Engelhardt ) (War der erste Google-Treffer.
Das müssen wir hier also im Anbetracht der Grundlagen, die wir hier voraussetzen, nicht nochmal durchkauen.
Die anderen Fragen kann man Pauschal nicht beantworten, da es für die verschiedenen Anforderungen, die man Anwendungen stellen kann, eben auch viele verschiedene Lösungsmöglichkeiten gibt. Wenn es pauschale Antworten geben würde, bräuchten wir keine Entwickler mehr - vor allem keine, die sich auf Architekturen spezialisieren.
In den meisten Fällen verlässt man sich auf bestehende Pattern - je nach "Modul" (Datenbank, Ausführungen, CodeStyes) gibt es hier eben auch verschiedene Pattern.
Siehe auch Design Pattern Tutorial
Wie man Klassen und Variablen benennt; da gibt s von Microsoft Richtlinien, an die man sich halten kann. Die meisten Entwickler haben aber ihren eigenen Stil, den Du Dir eben auch aneignen musst.
Siehe auch C# Coding Conventions (C# Programming Guide). Wenn ihr Unternehmensrichtlinien habt, dann musst Du Dich eben an diese halten bzw. an denen orientieren.
Fakt: ==> Mach's Dir so einfach wie möglich. Mach's so eindeutig wie möglich. Mach's so genau wie möglich.
Man kann von Dir im 2. LJ nicht erwarten, dass Du das alles schon perfekt kannst.
Dazu braucht man Jahre und Erfahrung, um ein Gespür und das Wissen zu haben, wie man so etwas annähernd perfekt umsetzt. Und trotzdem wird auch ein erfahrener Entwickler, immer wieder Hürden bezüglich der Architektur bewältigen müssen.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Dieses Buch kann ich empfehlen welches sich explizit mit sauberer OOP beschäftigt. Praxisbuch Objektorientierte Programmierung
Dieses Buch hat auch mir am anfang sehr geholfen Klassen "richtig" zu Strukturiren und einen ordentlichen Programmaufbau anzustreben.
Hallo Diablo,
wie Abt schon sagte ist hier in einem Forum-Post eine ausreichende Antwort zu geben so gut wie unmöglich. Aber wenn du die gegebenen Links durch liest, hast du gute Chancen die Antwort zu verstehen.
Einen Teil deiner Frage kann ich aber Beantworten: Forms + Klassen
Die Form ist in den meisten Fällen (nicht immer) die Präsentation zu einem oder mehreren Objekten, was bedeutet, dass Sie den Zustand der Objekte (aka. Properties) darstellen soll - Positionierung, Formatieren, etc.
Das Problem daran ist meistens aber mitzubekommen wann die Form "veraltet" ist, d.h. sich der Zustand der Objekte geändert hat. Hierzu verwendet .Net das Observer-Pattern im .Net-Framework durch INotifyPropertyChanged dargestellt. Und in Windos-Forms und in der WindowsPrestentationFoundation durch Databinding implementiert/verwendet.
Ob das Verhalten/Methoden der Objekte jetzt von der Form angestossen wird oder anders ist und was für ein Objekt dargestellt wird ist nicht so wichtig.
Gruß
Juy Juka
Hallo Diablo,
vor allem sollten wir gar nicht versuchen, die Fragen alle zu beantworten, weil das sonst ein unübersichlicher Mega-Sammel-Thread wird und die sind nach [Hinweis] Wie poste ich richtig? Punkt 1.2 "Nur ein Thema pro Thread" weder erlaubt noch erwünscht. Deine Fragen sind aber ein Rundumschlag über verschiedenste Aspekte des Softwaredesigns, von denen viele schon im Forum besprochen wurden.
Also beschränken wir uns auf die Frage im Titel: "Ab wann ist OOP eigentlich wirklich OOP?"
Nach Bertrand Meyers Buch "Object-Oriented Software Construction" gibt es sieben Schritte, bis man (wahre) Objektorientierung erreicht hat:
Seven Steps toward Object-Based Happiness
Level 1 (Object-based modular structure): Systems are modularized on the basis of their data structures.
Level 2 (Data abstraction): Objects should be described as implementations of abstract data types.
Level 3 (Automatic memory management): Unused objects should be deallocated by the underlying language system, without programmer intervention.
The next step is the one which, in our opinion, truly distinguishes object-based languages from the rest of the world. [...] True object-oriented programming all but identi es the notion of module with the notion of type. [...] This fusion of two apparently distinct notions is what gives object-based design its distinctive flavor, so disconcerting to programmers used to more classical approaches.
Level 4 (Classes): Every non-simple type is a module, and every high-level module is a type.
Level 5 (Inheritance): A class may be defi ned as an extension or restriction of another.
Level 6 (Polymorphism and binding): Program entities should be permitted to refer to objects of more than one class, and operations should be permitted to have diffe rent realizations in di fferent classes.
Level 7 (Multiple and repeated inheritance): It should be possible to declare a class as heir to more than one class, and more than once to the same class.
Darüber kann man natürlich streiten und nach dieser Definition wäre es in C# gar nicht möglich, auf der höchsten Stufe objektorientiert zu programmieren, weil es dort keine Mehrfachvererbung gibt, aber ich denke im allgemeinen ist es eine gute und hilfreiche Orientierung.
herbivore
Also beschränken wir uns auf die Frage im Titel: "Ab wann ist OOP eigentlich wirklich OOP?"
Da gibt es ja verschiedene Meinungen bzw. Definitionen, wie man im Wikipedia-Artikel zur Objektorientierte Programmierung nachlesen kann. Am besten gefällt mir:
(Objektorientierung) „bezieht sich auf eine Technik oder Programmiersprache welche Objekte, Klassen und Vererbung unterstützt.“
Christian
Weeks of programming can save you hours of planning