OOP Übungen

[/me]

Ihr haltet euch definitv zu lange an "Familie" auf und übertragt es nicht nach "Familienangehöriger".

Ich bin nicht der OP, der um ein Übungsbeispiel gebeten hat. Dass eine Familie aus Familienangehörigen besteht (was damit nicht unbedingt vollständig sein muss) ist so dermaßen trivial, dass ich mich über die entsprechenden Beiträge wundere.

Präzision bedeutet sehr viel bei der Softwareentwicklung und wenn man schon in der Entwurfsphase verwirrende Begrifflichkeiten verwendet, dann ist die Gefahr sehr groß, dass das ganz Projekt im Chaos endet oder noch mal weit zurückgedreht werden muss.

Familie ist hier einfach semantisch falsch und wenn mehrere erfahrene Entwickler darüber stolpern, dann sollte man das als Wink mit einem ganzen Gartenzaun sehen.

[xeike]

Familie ist hier einfach semantisch falsch und wenn mehrere erfahrene Entwickler darüber stolpern, dann sollte man das als Wink mit einem ganzen Gartenzaun sehen.

Es liegt nicht an der Semantik, sondern an der Interpretation. Mit

Code: Alles auswählen

class Person
class Personen
class Familie(Personen)

kann ich das in meinem ersten Posting genannte sehr gut abbilden.

Ach ja: "Familie" ist auch wieder nur eine semantische Interpretation eines realen Sachverhaltes. Ich könnte auch Pruzzel von Brabbel ableiten. Um es deutlicher zu sagen: "Familie" bedeutet hier schlicht und ergreifend einen Ausschnitt bezogen auf Name, Anschrift und Geburtsdatum im Kontext eines Übungsbeispiels.

Xe

[jerch]

"Familie" bedeutet hier schlicht und ergreifend einen Ausschnitt bezogen auf Name, Anschrift und Geburtsdatum im Kontext eines Übungsbeispiels.

Da passt dann wirklich viel rein - Name: Rathaus, Anschrift: Am Markt 1, Geburtsdatum: 01.01.1671

[cofi]

"Familie" bedeutet hier schlicht und ergreifend einen Ausschnitt bezogen auf Name, Anschrift und Geburtsdatum im Kontext eines Übungsbeispiels.

Da passt dann wirklich viel rein - Name: Rathaus, Anschrift: Am Markt 1, Geburtsdatum: 01.01.1671

Das ist dann halt eine Stadt und die Stadtfamilie sind die Buerger

[mcdwerner]

... um nochmal zurück zur Ausgangsfrage zu kommen, ich würde hier noch Frameworks in die Runde werfen, bei denen man gezwungen ist mit Klassen zu arbeiten und die gut dokumentiert sind, z.B.: Django https://www.djangoproject.com/

Ich habe damit 2 kleine Projekte im Heimnetzwerk realisiert und irgendwann kam dann der Punkt an dem ich mich fragte: "Woher zum T... hat das Model <blah> jetzt diese Methode???" edit: "Woher zum T... hat das VON MIR SELBST GESCHRIEBENE Model <blah> jetzt diese Methode???"

Wenn schon mit Kanonen auf Spatzen schiessen, dann will ich die Spatzen aber auch braten und essen können (bzw. dann will ich auch was davon haben

[JonnyDamnnox]

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

[pillmuncher]

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.

[Hyperion]

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.

[BlackJack]

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

[Hyperion]

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

[Gary123456]

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

[BlackJack]

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

[xeike]

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

[Gary123456]

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

[Hyperion]

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.

[JonnyDamnnox]

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ß

[Gary123456]

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

[Gary123456]

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.

[Hyperion]

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.

[Gary123456]

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.