Das deutsche Python-Forum

Dann programmier halt irgendwas, mein Gott..., so komplex ist es jetzt auch wieder net.

Zur Ausgangsfrage: ob man OOP üben kann, so wie man etwa Klavier üben kann, weiß ich nicht. Man kann aber die Mechanismen von OOP und deren zugrunde liegende Prinzipien erlernen. Ich empfehle dazu das Buch Head First: Design Patterns vom O'Reilly Verlag. Die Beispiele sind zwar in Java, aber dermaßen einfach, dass man sich das benötigte Vorwissen leicht an einem Wochenende aneignen kann. Design Patterns aind Standardlösungen für immer wiederkehrende Programmier-Probleme in der OOP. In dem genannten Buch werden diese Lösungen in Bezug zu den allgemeinen Prinzipien der OOP gesetzt, weswegen ich dieses Buch für empfehlenswert halte.

pillmuncher hat geschrieben:Ich empfehle dazu das Buch Head First: Design Patterns vom O'Reilly Verlag.

+1 (Hab es mir letztlich Dank Deiner Empfehlung einst gekauft!

)

Gibt auch Leute, die das Buch weniger mögen: Coding Horror

Ich finde seine Argumente allerdings eher schwach.

@Hyperion: Naja, es ist letztendlich nur *ein* Kritikpunkt, nämlich dass der Hinweis, dass man Entwurfsmuster nur Anwenden sollte, wenn man wirklich, also keine unnötige Komplexität in den Code einbaut, erst am Ende und nicht schon am Anfang des Buches steht.

Hm... ok, ich hatte es eher so gesehen, dass er kritisiert, dass Anfänger duch das Buch fälschlicher Weise dazu motiviert werden, Patterns zu benutzen. In dem Buch steht nirgends, dass man solche Übungen in Produktiv-Code durchführen soll. So viel Erkenntnis sollte man einem Programmierer schon zutrauen, oder?

Und "The best way to learn to write simple code is to write simple code!" ist ja auch eher irreführend. Denn was ist schon "simple"? Wir treffen doch ständig auf ``is...else...elif``-Kaskaden, in deren Zweigen oftmals sogar Logik steht. Für einen Anfänger ist das Verständnis dafür "simpel" - aber im Grunde genommen führt das zu keinem wirklich simplen Code. Wenn ich das durch ein Dispatching ersetze, habe ich doch bereits den Command-Pattern angewendet (ggf. ohne es zu wissen).

Natürlich sollte ein Programmieranfänger erst einmal ohne Pattern die grundlegenden Dinge lernen - aber das Buch richtet sich ja auch nicht an blutige Programmieranfänger, sondern an Leute, die durchaus schon OOP-Basiswissen besitzen. Daher fand ich die Kritik überzogen - zumal das Buch ja auf die Problematik eingeht; wer das nicht zu Ende liest, hat ja ohnehin kein so großes Interesse am Lernen und damit auch der Anwendung von Pattern

Jetzt kommt bei mir wieder das alltägliche auf: Was soll ich programmieren? :K

@Hyperion: Nö, so viel Erkenntnis sollte man nicht jedem Programmierer zutrauen. Ich hatte die jedenfalls nicht — als ich neu bei Java war und das GoF-Buch gelesen hatte, habe ich auch erst einmal überall Patterns reingehauen, ob das nun nötig war oder nicht. Und ich war damals noch nicht einmal Programmieranfänger. Ich bin da seiner Meinung, dass die meisten Programmierer neu erlernte Techniken oder Konzepte auch unbedingt irgendwo anwenden wollen. Und zumindest im Java-Umfeld wird man dazu ja auch durch Beispiele ermutigt, wenn man sich die ganzen „overengineered” Bibliotheken anschaut.

@Gary123456: Schon mal in die Aufgaben von den HP Codewars von diesem Jahr geschaut? Da sind Aufgaben in den verschiedensten Schwierigkeitsgraden enthalten.

Hi Gary123456,

- Schiffe versenken gegen den Computer,
- Vokabeltrainer,
- ein Programm, das aus einer Menge von Fotos automatisch eine Webseite bastelt,
- ein "Personal Kanban"-Board,
- ein Programm, das dich automatisch beim Einloggen auf deiner Linux-Maschine an Geburtstage und Jubiläen erinnert

Schiffe versenken und Vokabeltrainer hören sich super an. Ich werde mir auch diese HP Codewars mal ansehen. Vielen Dank!

BlackJack hat geschrieben:Ich bin da seiner Meinung, dass die meisten Programmierer neu erlernte Techniken oder Konzepte auch unbedingt irgendwo anwenden wollen.

Sicher will man das - was ist daran verkehrt? Man muss halt bei Produktiv-Code prüfen, ob der Pattern passt oder nicht. Manchmal stellt man auch erst später fest, dass das unnötig komplex gelöst ist. Dann muss man eben refactorn. Aber im Grunde ist das doch etwas ganz natürliches. Denn auch ohne Pattern lernt der Anfänger (hoffentlich) dazu und wird seinen "alten" Code refactorn oder gar wegwerfen.

Zum Spielen und Experimentieren hingegen kann man doch durchaus "overengineered" Code schreiben.

Im übrigen wendet man Pattern in vielen Sprachen eh täglich an - Events in C# sind ja nichts anderes als der Obserer-Pattern. Der Template-Pattern bei Sortierfunktionalität, der Decorator-Pattern bei Java-Streams, ... Wo liegt also die Grenze? Und kann man diese Techniken nicht besser nutzen, wenn man das Konzept dahinter verstanden hat?

Welche Strategie würdest Du denn einem Anfänger empfehlen? Wann "darf" der Anfänger denn nun Design-Pattern lernen?

Ist denn auf einmal alles gut, wenn in dem Buch auf Seite 10 das steht, was erst spät im Buch auftaucht?

Davon abgesehen möchte ich mal Lernende erleben, denen sofort zu Beginn des Buches an den Kopf geworfen wird, dass sie das im folgenden zu lernende bloß nicht sofort anwenden sollen - ich wäre ziemlich wütend auf den Autor oder den Lehrenden

Last but not least: Im Buch werden neben den Pattern ja eben *auch* grundlegende OOP-Prinzipien erklärt und veranschaulicht. Und diese anzuwenden und frühzeitig zu üben ist sicherlich sinnvoll.

Ja ich wusste auch nie was ich programmieren soll. Ich hab immer gedacht WOAH GEIL jetzt programmier ich irgendwas noch nie da gewesenes und werde fantastillionär!!!!11elf1

Dann drei Tage brainstormming und nur Mist kam dabei raus :K
Jetzt Programmier ich einfach alle Programme die ich täglich so benutze, dann erfinde ich zwar das Rad immer wieder neu, aber seine eigenen Programme(wie grauenvoll sie auch sein mögen) zu benutzern, ist schon was feines

:

Webbrowser(mit Pyside, darauf freu ich mich am meisten), email Programm, Texteditor, Musik/Videoplayer, FTP Server, Graphikprogramm usw. oder auch Sachen fürs Handy mit Android ect.(gibts auch in Python)

Gruß

Ich habe noch eine bessere Idee: Mit Hilfe des OS Moduls verschiedene Informationen aus dem System liefern und das in ein Textdokument abspeichern.

Das wäre ja schon ein kleiner Erfolg:

Code: Alles auswählen

import os

for i in os.listdir("C:\\"):
    print "C:\\" + i
for i in os.listdir("C:\\Users"):
    print "C:\\Users\\" + i
for i in os.listdir("C:\\Windows"):
    print "C:\\Windows\\" + i

Jemand schon vom Tool OTL gehört? Jetzt müsste ich nur noch Erstellungsdatum der Files ermitteln (Reicht da das time-Modul?), verschiedene Registrypunkte abchecken und es möglich machen, Dateien zu löschen. Kleiner Code, aber viel Wirkung. Begeisterung.

Abgesehen davon, dass das hier nix mit OOP zu tun hat:

- Verwende RawStrings bei Pfadangaben:

Code: Alles auswählen

r"C:\foo"

- der Name ``i`` ist kein guter Bezeichner! Wieso nicht ``file_name`` oder ``entry``?

- Der ganze Code ist Copy & Paste! Der schreit geradezu danach, durch eine Funktion allgemeiner zu werden:

Code: Alles auswählen

print "C:\\"
for i in os.listdir("C:\\"):
    print i
print
#--- Ende Block 1
print "C:\\Users"
for i in os.listdir("C:\\Users"):
    print i
print
#--- Ende Block 2
print "C:\\Windows"
for i in os.listdir("C:\\Windows"):
    print i 
# Ende Block 3

Schau Dir mal die Blöcke an und überlege, worin sie sich unterscheiden! Dann entwirf eine Funktion, die diese Funktionalität kapselt und rufe diese entsprechend mit den richtigen Parametern drei mal auf.

Danach können wir das dann noch weiter refactorn, indem das dreimalige Aufrufen der Funktion im Code vermieden wird und die Parameter in eine passende Datenstruktur ausgelagert werden.

Ach komm, das habe ich in 2 Minuten gebastelt. Ist doch nicht ernst zu nehmen.

Ich habe den Code editiert und noch kürzer gemacht. Zwar unübersichtlich, ist aber noch lang kein Programm. Das sollte eher ein Mini Demonstrationstools sein, was ich basteln werde.

Ich hoffe, Du verstehst mich.

Aber dennoch:

- Verwende RawStrings bei Pfadangaben:

Davon habe ich noch nie gehört. Ich werde danach mal googlen.

Gary123456 hat geschrieben:Ach komm, das habe ich in 2 Minuten gebastelt. Ist doch nicht ernst zu nehmen.

Doch! Denn *Übung* macht den Meister. Und wenn man bei kleinen Schnipseln "schlampt", dann schleicht sich das auch in längeren Code ein. Man eignet sich also sogar schlechtes oder gar falsches an.

Gary123456 hat geschrieben: Ich habe den Code editiert und noch kürzer gemacht. Zwar unübersichtlich, ist aber noch lang kein Programm.

Nun ist es fast noch schlimmer, da Du Pfade nicht mittels ``os.path.join`` zusammen fügst!

Damit Du mal siehst, wie ich es meinte (ungetestet):

Code: Alles auswählen

import os
import os.path

def show_directory(path):
    for entry in os.listdir(path):
        print os.path.join(path, entry)

for path in (r"C:", r"C:\Users", r"C:\Windows"):
    show_directory(path)

Und nun vergleiche das mal mit Deinem Code...

Nun ist es fast noch schlimmer, da Du Pfade nicht mittels ``os.path.join`` zusammen fügst!

Habe davon noch nix gehört. Dennoch Danke!

Dein Code ging nich. Habe den etwas umgeformt, dass er funkt.

Ich schrieb ja auch ungestet

Habe ihn korrigiert.

Das deutsche Python-Forum

OOP Übungen

Re: OOP Übungen

Re: OOP Übungen

Re: OOP Übungen

Re: OOP Übungen

Re: OOP Übungen

Re: OOP Übungen

Re: OOP Übungen

Re: OOP Übungen

Re: OOP Übungen

Re: OOP Übungen

Re: OOP Übungen

Re: OOP Übungen

Re: OOP Übungen

Re: OOP Übungen

Re: OOP Übungen

Re: OOP Übungen

Re: OOP Übungen

Re: OOP Übungen