Archiv verlassen und diese Seite im Standarddesign anzeigen : Vorstellung meines Programmiertutorials auf Youtube
Hallo,
ich habe ein Programmiertutorial zum Thema Programmierfallen erstellt und auf YouTube veröffentlicht:
https://youtu.be/1U-v84M-1t0
Gibt es noch weitere Themen, wo ihr noch ein Tutorial dieser Art sucht?
Vielen Dank für die Erleuchtung, so Leute bräuchte es viel mehr. Das Video kann ein Jahrzehnt grübeln einsparen.
Dachte das wäre nur bei SPS Simatic so und deshalb nervig, weil z.B. Ausgänge nur einmal belegt werden können.
Jetzt find ich es genial und habs auch verstanden. Ein Irrweg dorthin war Logikmodul LOGO!
Betreff objektorientierte Programmierung ist mir z.B das Herausarbeiten welche Daten (oder Zustände) ich den
Eigenschaften oder Methoden() und set() get() zuordne ein weiterer Hemmschuh.
- - - Aktualisiert - - -
Ja und für welche Problemstellung ist objektorientierte Programmierung unumgänglich?
Ja und für welche Problemstellung ist objektorientierte Programmierung unumgänglich?
gar nichts ist hier unumgänglich, auch C++ wurde ja als Erweiterung von C alleine mit den C-Bordmitteln möglich, also kann man es z.B. auch selber ohne die ++ Erweiterung alleine mit ANSI C (C99) schaffen. Java hat dann C++ nur von Grund auf neu erfunden (ohne historischen C-Ballast, sogar main() ist hier eine OOP-Methode).
OOP (C++, Java, Pascal/Delphi, C#,...) macht aber vieles sehr viel einfacher, wenn man eine große Anzahl gleichartig oder ähnlich funktionierender Funktionsstrukturen hat (=> mehrere Instanzen derselben Basis-Objekts), und wenn einige davon sich nur in wenigen Details von anderen unterscheiden (=> Vererbung).
Beispiele:
- Fensterobjekte mit gleichartigen Grundsteuerungen sowie optionalen Menüs und Gadgets in GUI-Applikationen
- Simulationsspiele mit-zig Spielfiguren, die dort alle gleichartige oder ähnliche Grundeigenschaften und Funktionsfähigkeiten haben (Age of Empires, Civilization, Siedler, Fifa, MarioCart, Lemminge, ...)
- Softwaredriver für mehrere Implementierungen von gleichartigen Hardware-Devices (gleichartige Grundobjekte für verschiedene Displays wie bei Adafruit GFX mit identischer API, mehrere Instanzen derselben Device-Objekte, wenn nicht nur 1, sondern viele davon parallel betrieben werden sollen,...)
Es geht auch hier sicher ohne OOP, aber mit OOP muss man nicht immer wieder das Rad neu erfinden.
White_Fox
21.09.2019, 17:59
Java hat dann C++ nur von Grund auf neu erfunden (ohne historischen C-Ballast, sogar main() ist hier eine OOP-Methode).
Naja, ein paar Designentscheidungen, die sich bei C++ als häufige Fehlerquelle erwiesen haben, wurden schon besser gelöst. Keine Mehrfachvererbung, und Pointer mußte man in Java auch noch niemandem erklären. Oder gar Pointerarythmetikfehler beheben. Oder das Überschreiben fremder Speicherbereiche.
Es geht auch hier sicher ohne OOP, aber mit OOP muss man nicht immer wieder das Rad neu erfinden.
Ganz genauso ist es. Ich möchte noch anfügen, daß sich die Realität objektorientiert oft sehr einfach beschreiben läßt. Und manche sehr komplexe Problemstellung läßt sich objektorientiert wunderbar elegant lösen, wenn man sich mal ein paar Entwurfsmuster ansieht. Das Dekoratormuster ist da so mein Lieblingsbeispiel:
https://www.philipphauer.de/study/se/design-pattern/decorator.php
Man kann sowas natürlich auch prozedural lösen, sogar in Assembler...aber warum will man das, wenn es auch anders geht?
Kurze Frage noch bevor ich mich mich mal versuche.
Es gibt für dieselbe Problemstellung immer nur eine einzig richtige Beschreibung und Entwurfsmuster?
Jeder z.B. C++ Programmierer würde zum selben Ergebnis kommen und es dann "einfach" innerhalb der Methoden etwas anders umsetzen?
- - - Aktualisiert - - -
Ach ja und ist es Plicht sich um Garbage Collector und Exceptions (sieht man selten) explizit zu kümmern?
Bin am Buch "Java in 21 Tagen" kläglich gescheitert. Habe genau 0 verstanden, Java gewählt weil kein GC notwendig.
- - - Aktualisiert - - -
Mein Hello World das ich mir immer aussuche ist meine Waschmaschiene:
34404
Konkrete "Basisgerichte"
Pumpen Abpumpen Heizen Waschen Spülen Schleudern
Konkrete "Beilagen"
Temperatur Umdrehungszahl Optionen ExtraSpülen
Gibt es noch weitere Themen, wo ihr noch ein Tutorial dieser Art sucht?
ja, auch ich finde, dass OOP ein gutes Thema ist für Tutorials.
Allerdings ist die Umsetzung so stark PL-abhängig, dass ein sinnvolles Tutorial PL-spezifisch sein sollte (höchstens eine SEHR kurze Einfühung mit Flowcharts) - andernfalls versteht man nur, wie es grundsätzlich funktionieren KÖNNTE, scheitert aber bereits beim PL-spezifischen Objektdesign und erst recht dann bei der korrekten Implementierung von Methoden und der späteren Instanziierung.
Da hier im Forum wesentlich mehr Leute C++ als irgendwas anderes nutzen dürften (allein schon alle Arduino-Nutzer, aber auch auf dem Pi ist C++ verbreiteter als z.B. Java), würde ich zumindest konkrete Beispiele in C++ empfehlen.
Wichtig fände ich es auch, dass man (zumindest fast) alle Resourcen zum Tutorial in Schriftform downloaden kann (pdfs und Sourcecode, am einfachsten über github!)
White_Fox
23.09.2019, 08:01
Entwurfsmuster an sich kann man schon sehr allgemein erklären, da gibt es nur sehr wenig was programmiersprachenspezifisch ist (z.B. Vererbungsbäume kreuzen erlaubt ja/nein). Aber die meisten OO-Sprachen haben, was ihren Funktionsumfang angehe, doch eine recht große Schnittmenge. Die Bezeichnungen für ein und dasselbe sind vielleicht unterschiedlich.
Ich habe, als ich mich mit OOP befasst habe, mal das Buch Entwurfsmuster von Kopf bis Fuß durchgearbeitet (sehr gutes Buch). Da wurde alles mit Java-Code erklärt mit dem Hinweis, daß alles in C++ genauso funktioniert. Bis auf ein Detail, die in C++ umsetzbar ist, in Java aber nicht wegen der verbotenen Kreuzvererbung.
Da man mit Java auf Mikrocontrollern aber leider nicht allzuweit kommt wäre C++ vielleicht wirklich nicht schlecht, aber besser wäre m.E. wenn das programmiersprachen- und problemunabhängig wäre. Damit können Systematiken besser in den Vordergrund gerückt werden und es artet weniger in stumpfem Nachmachen aus.
Es gibt für dieselbe Problemstellung immer nur eine einzig richtige Beschreibung und Entwurfsmuster?
Jeder z.B. C++ Programmierer würde zum selben Ergebnis kommen und es dann "einfach" innerhalb der Methoden etwas anders umsetzen?
Ist das ein Witz, den ich nur nicht verstehe? Richtiger ist doch viel mehr "Viele Wege führen nach Rom".
Nein kein Witz, dachte bei OOP kommt man wenn es verstanden ist ohne Gefrickel aus.
Die "Schönheit" der Beispiele täuscht wohl.
https://www.forschung-und-lehre.de/forschung/gehoert-schoenheit-in-die-physik-2045/
Nein kein Witz, dachte bei OOP kommt man wenn es verstanden ist ohne Gefrickel aus.
Die "Schönheit" der Beispiele täuscht wohl.
:p
in C++ ist man ebenso frei, seine Programme zuschreiben, wie bei C - eigentlich noch freier, da C nur eine Untermenge von C++ ist. Niemand schreibt vor, welche Variablen isoliert sind oder in einer Struktur stehen oder in einer class, und niemand schreibt vor, was in einer class public oder private oder protected ist, und niemand schreibt vor, welche Funktionen global sind oder in einer class als Methode stehen und dort private, public oder protected, und niemand schreibt vor, ob Funktionen void sind oder Rückgabewerte haben und ob Variablen per value oder per reference übergeben werden.
Um aber die Ratschläge eines Tutorials zu verstehen und auch praktisch umsetzen zu können, ist eine Codierung der Beispiele in der Zielsprache (hier: C++) unumgänglich, denn über 90% der user hier sind ja wahrscheinlich sowohl OOP- als auch C++ -Anfänger, für die C++-Objekt-Kodierung noch völlig unbekannt und absolut verwirrend ist.
Bei OOP steht der Gedanke im Vordergrund, alles in einem Objekt zu verkapseln (Varablen, Methoden), was dieses Objekt für seine volle Funktionsfähigkeit benötigt, und alle Aufgaben des Objekts vom Objekt selber erledigen zu lassen.
"Viele Wege führen nach Rom"
Es ist immer nur ein Weg, der kürzeste.
Es ist immer nur ein Weg, der kürzeste.
das gilt nur in der Euklidischen Geometrie, und nicht immer ist der kürzeste auch der effektivste
(und nach "Weg" steht kein Komma ;) )
White_Fox
23.09.2019, 10:39
Sehr richtig. Es gibt doch verschiedene Anforderungen, die auch jeder unterschiedlich gewichtet.
"Viele Wege führen nach Rom"
Es ist immer nur ein Weg, der kürzeste.
Würdest du die Steilwand denn senkrecht hochklettern, oder die Serpentienen nebenan nehmen? Und unabhängig von deiner Entscheidung, was würdest du einem Rollstuhlfahrer empfehlen?
Ich schreibe aktuell mein erstes, "richtiges" Programm (bin eigentlich HW-Entwickler, kein Programmierer) und benutze das erste Mal das MVC-Pattern. Da schiebe ich extra Objekte hin und her, die nur dafür da sind, Daten zum präsentieren in der GUI zu kapseln. Damit ich eine saubere Trennung zwischen GUI und Datenmodel habe, und die GUI nicht die Möglichkeit hat irgendwelche Nutzdaten überschreiben zu können.
Da kommt natürlich viel Hin- und Herkopiererei zusammen, und auf einem Mikrocontroller würde ich so nicht programmieren. Da mein Programm aber auf normalen PCs/Laptops läuft ist es mir egal ob da jetzt ein paar hunderttausend Taktzyklen mehr bei der Ausführung benötigt werden und ob das Programm jetzt mit 30MB oder 50MB im Speicher rumliegt. Was mir jedoch viel wichtiger ist, ist idiotensichere Codelesbarkeit, eine gute Struktur in der ich mich auch nach einem Jahr wieder zurecht finde, und mich selber vom Scheißebauen abhalten (wie z.B. aus der GUI herraus irgendwelche Daten zu ändern). Denn das kann die Weiterentwicklung eines Programms erheblich behindern bishin zum kompletten Erliegen bringen.
Danke für das Feedback. Tatsächlich ist C++ formal nicht einfach nur eine Erweiterung von C, sondern gilt als eigenständige Programmiersprache. Es gibt Konstrukte, die nur in C funktionieren, aber nicht in C++.
Ich denke auch die Unterschiede von objektbasierter (C) und objektorientierter (C++) Programmierung könnten interessant für einen Beitrag sein.
Das Gesetz von Demeter ist sicher auch Interessant.
Danke für das Feedback. Tatsächlich ist C++ formal nicht einfach nur eine Erweiterung von C, sondern gilt als eigenständige Programmiersprache. Es gibt Konstrukte, die nur in C funktionieren, aber nicht in C++.
Ich denke auch die Unterschiede von objektbasierter (C) und objektorientierter (C++) Programmierung könnten interessant für einen Beitrag sein.
Das Gesetz von Demeter ist sicher auch Interessant.
die Fälle, in denen C-Konstrukte nicht sofort in C++ funktionieren, kann man an 1 Hand abzählen - meist liegt es daran, dass z.B. C gewisse Ungenauigkeiten zulässt, die bei C++ nicht direkt funktionieren, weil es reservierte Keywords sind oder man Statements präzisieren muss, z.B. :
1) new is a keyword in C++ so can't be used as a variable name.
2) C++ doesn't allow automatic pointer conversion.
3) C++ doesn't allow you to call undeclared functions.
4) in C++ struct and typedef have the same scope so the same identifier can't be used for each, in C they are separate.
5) ISO C++ forbids converting a string constant to ‘char*’ )
Das ist aber derart ausgesucht, dass es IMO vernachlässigbar ist.
Tatsächlich ist C++ definierbar als {C plus Objekte plus Stream plus Überladung}, und von daher ist C durchaus eine Untermenge von C++.
C würde ich als prozedural vs. C++ = objektorientiert definieren - C++ lässt aber auch weiterhin rein prozedurales Programmieren zu oder Mischformen (weil es die vormalige C-Syntax samt ihrer Möglichkeiten ebenfalls noch zulässt), anders als andere rein objektorientierte Sprachen wie Java.
Viele meiner prozeduralen C-Programme (mit wiringPi, openVG und pthread auf dem Raspi) lassen sich sowohl mit gcc (C99 oder C11 usw.) als auch - völlig unverändert - mit g++ (C++11/14) kompilieren und starten, und wenn man dann Objekte hinzunimmt, läuft alles nach wie vor mit C++ weiter (aber dann ntl nicht mehr mit ANSI-C).
Da mein Programm aber auf normalen PCs/Laptops läuft ist es mir egal ob da jetzt ein paar hunderttausend Taktzyklen mehr bei der Ausführung benötigt werden und ob das Programm jetzt mit 30MB oder 50MB im Speicher rumliegt.
Das ist die Entwicklung die ich bedauert habe.
Das ist die Entwicklung die ich bedauert habe.
das halte ich angesichts der Vorteile bei Nutzerfreundlichkeit, der Programm-/Ausführungs-Sicherheit, Skalierbarkeit, Flexibilität/Veränderbarkeit und auch aus Wartungsgründen für reichlich überholt und weltfremd.
Warum nutzt man heute wohl auf PCs (Windows, Linux) und Androids objektorientierte Fenster- und Menütechnik als Userinterfaces statt reine Textterminals mit Programmzeilenparameter-Tohuwahobu?
reichlich überholt und weltfremd.
Scheint mir auch so.
Wie mir mein Chef mal gesagt hat wird z.B. bei EIB (https://de.wikipedia.org/wiki/KNX-Standard) das Programmieren nach Mausklicks und die Visualisierung dazu nach Anzahl verwendeter Objekte bezahlt.
Zudem musste ich auch alles ausdrucken, im Schnitt 800 Seiten die von der Software automatisch für den Auftraggeber nachvollziehbar erstellt wurden. Bei Erstellung der Visualisierung wurde ich angehalten es "aufzublasen".
Wenn ich mit einer 50MB Software ankomme klingelt die Kasse.
Scheint mir auch so.
Wie mir mein Chef mal gesagt hat wird z.B. bei EIB (https://de.wikipedia.org/wiki/KNX-Standard) das Programmieren nach Mausklicks und die Visualisierung dazu nach Anzahl verwendeter Objekte bezahlt.
Zudem musste ich auch alles ausdrucken, im Schnitt 800 Seiten die von der Software automatisch für den Auftraggeber nachvollziehbar erstellt wurden. Bei Erstellung der Visualisierung wurde ich angehalten es "aufzublasen".
Wenn ich mit einer 50MB Software ankomme klingelt die Kasse.
ich spreche nicht von Selbstzweck, Missbrauch und Beutelschneiderei, sondern von Funktionilät und optionalen, potentiellen Möglichkeiten.
Das Ausdrucken hat 2 Tage gedauert in der Firma, wurde auch nach Anzahl Seiten bezahlt.
- - - Aktualisiert - - -
Die Beutelschneiderei ist ein Service der Hersteller für die Firmen.
Die ist nicht mehr zu trennen.
Das Ausdrucken hat 2 Tage gedauert in der Firma, wurde auch nach Anzahl Seiten bezahlt.
- - - Aktualisiert - - -
Die Beutelschneiderei ist ein Service der Hersteller für die Firmen.
Die ist nicht mehr zu trennen.
ich sehe dieses Forum vorwiegend für Hobbyuser, die sogar überwiegend Freeware und Public Domain Software/Hardware verwenden, und daher fallen hier Beutelschneiderei und Missbrauch weg, zugunsten von Funktionilät und optionalen, potentiellen Möglichkeiten (siehe Arduino, Borland C++ Builder, Raspberry Pi, openCV, qtcreator, gcc/g++)
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.