~ DB-/FoxPro Usergroup Treffen 12.09.13 objektorientiert, prozedural,...

• Legende

  • to do / anstehend
  • nächster Schritt
  • zu untersuchen
  • erledigt
  • wichtig
  • verworfen
  • zurückgestell / später
  • postiv gewichtet
  • negativ gewichtet
  • Reihenfolge
  + -

  Ketzerische Meinung:

  dass Objektorientierung als "führendes" Programmier-Paradigma gilt

  bedeutet nicht, dass alles pure OOP sein muss... ("reine Lehre")

  • letztlich geht es für alle Beteiligten um das Preis-/Leistungsverhältnis =für uns Entwickler: Entwicklungs- + Wartungskosten

    Pragmatismus: mach es nicht zu kompliziert!

    (passiert mir immer wieder)

    VFP ist ziemlich gut in OOP und prozedural und SQL (und Spaghetti ;-)

     Mein momentaner Stand zu

  "prozedural + objektorientiert pragmatisch kombinieren"

  • + - Code/Klassen bei mir immer öfter in PRGs und nicht in VCX
    • können als Funktion() aufgerufen werden
    • Einfach zu finden und auszutauschen
    • Versionskontrolle einfacher
    • Properties können "VarX as SomeType" haben -> Intellisense!
    • keine VCX-Defekte
    • OLEPUBLIC + INTERFACE
    • verhindert (zu) grosse Klassenbibliotheken
      • -> tendenziell weniger enge Kopplung
      • -> meistens bessere Wiederverwendbarkeit
    • beliebiger Editor nutzbar
    • ermöglicht Zusammenfassen von Methoden zu einem Thema (Valid/Defaults/...)
    • Beliebig viele Parentklassen gleichzeitig anzeigbar
    • Intellisense funktioniert manchmal nicht
    • kein Einsatz per Drag & Drop
    • kein "View Parent Code"
    • immer nur ein Code-Fenster = nicht mehrere Methoden gleichzeitig anzeigbar
  • + - Klassen ohne UI in PRGs
    • Jeweils eine Klasse in einem PRG
    • Aufruf als Funktion liefert eine Instanz
      • Demo: SaveDir()
    • Objekte, die sich Werte über das Destroy hin merken
      • Demo

  Thema Wartbarkeit

  • + - komplexere Logik führt zu
    • + - immer komplexer werdendem Code
      • Komplexe Logik
      • Spaghetti (meist gewachsen)
      • Kohäsion
    • + -

      Deshalb wachsender "Druck" für: Zerlegen/Refactoring

      • beim Zerlegen immer die Angst/Frage: "tut es noch?" vor allem wenn (zu) spät zerlegt wird

        unverändert lassen verschiebt die Änderung in die Zukunft

        Dann wird es noch teurer

        Bereitschaft zum Refactoring erhöht sich deutlich

        durch: Testbarkeit. Wenn möglich automatisiert

        =ohne großen Aufwand wiederholbar anstreben/umsetzen/beibehalten

  • Abhilfe/Strategien
    • komplexen Code verhindern
    • Kohäsion vermeiden
    • häufiges Refactoring

      • macht man in der Praxis eher/nur wenn ohne großen Aufwand wiederholbare Tests da sind um zu sehen: tut noch so wie vorher

    • ~ generell: Clean Code Development
    • konkreter:

      • Thema heute:

        Objekte als Parameter

        und ggf. als Rückgabewerte

        • SCATTER NAME anstelle von ALIAS() als Parameter
        • (Empty-) Objekte (auch zusammengesetzt)
        • COLLECTION als Rückgabewert
        • und natürlich wieder alles zusammen mit UNIT Tests ;-)
        • scatter name loRecord lcMessage = meinValidator(loRecord)
  • Beispiel Validieren()
    • Einfach nur ein eingebetteter Codeblock (mehr oder weniger komplex)
    • Auslagern - aktuellen Alias() voraussetzen
    • + - sofort eine Klasse daraus machen
      • ermöglicht weitere Methoden wie z.B. "Defaults()"
    • Alias als Argument
    • SCATTER NAME als Argument
    • komplexes Objekt als Argument
    • Rückgabe ist boolean
      • oder doch besser eine Fehlermeldung?
      • oder besser mehrere Meldungen und Errorlevel?
      • Collection als Rückgabewert?
  • Beispiel Outlook Automation
    • Dependency Injection
    • ein gaanz simples Mock Objekt
      • test_outlook.prg
      • test_outlookMock.prg