Page 1 of 4 1 2 3 ... LastLast
Results 1 to 15 of 58

Thread: Simplify your Delphi Code using some OO techniques and lots of Refactoring

  1. #1
    Senior Member
    Join Date
    Jul 2008
    Location
    Ertvelde, Belgi?½
    Posts
    158

    Simplify your Delphi Code using some OO techniques and lots of Refactoring

    Beste,

    Uit mijn ervaring met Delphi zie ik dat het heel vaak gebruikt wordt als een RAD tool, en maar al te weinig als een echte OO Programmeertaal. Als consultant zie ik immers maar al te vaak dat veel code geschreven wordt in allerhande event handlers, op plaatsen waar het soms niet thuishoort.

    Het is vaak niet zo eenvoudig om het verschil te leggen tussen een RAD tool (Rapid Application Development) en een echte OO tool, want er is wel degelijk een verschil (vind ik).

    Daarom heb ik een tweetal weken terug een serie artikels gestart rond dat specifieke onderwerp. De artikels staan op onze home page en zijn in het Engels, maar ik dacht dat het misschien interessant was voor de lezers van NLDelphi. Je kan de desbetreffende links hier terugvinden :

    Simplify your Delphi Code using some OO techniques (Part 1)
    Simplify your Delphi Code using some OO techniques (Part 2)

    Mochten jullie hier iets aan hebben, laat het gerust even weten en dan post ik de nodige updates / nieuwe links hier ook.



    Groeten,



    Stefaan
    Last edited by Marcel; 06-Feb-12 at 09:38.

  2. #2
    Gebruik je nu bit.ly om links naar je eigen homepage te maskeren? Als je wilt, wil ik wel helpen met vertalen van de artikelen zodat ze hier geplaatst kunnen worden hoor.

    Zonder gekheid, deze artikelen zijn vrij beknopt, en ik denk dat je over dit onderwerp boeken vol zou kunnen schrijven. Toch slaan ze de spijker wel op de kop en ik denk dat met name beginnende programmeurs veel hebben aan dit soort artikelen.

    Overigens ben ik het zelf niet helemaal eens met het 'eerst opschrijven, dan proggen'. Een andere techniek die ik zelf veel gebruik noem ik maar 'Top-down' implementeren.

    Ik begin dan gewoon met tikken. Niet alles onder elkaar, maar al direct met procedure of functie-aanroepen naar functies die ik later implementeer. Bij het implementeren van die functies deel ik dan alles ook weer in in procedures, net zo lang tot ik op een detail kom dat het uitgeschreven wordt in code. Op die manier begin je met een heel globaal stuk code dat de hoofdstappen beschrijft, haast alsof je pseudo-code schrijft of een PSD. En die stappen herhaal je tot een steeds fijner niveau, tot alles af en werkend is.

    Die manier werkt vast niet altijd lekker, en is ook zeker niet handig wanneer je anderen naar een concept wilt laten kijken, maar zodra er duidelijk is wat er moet gebeuren, en je je raamwerk hebt opgebouwd, werkt het erg lekker en snel om op deze manier steeds verder de details in te vullen. Het alternatief is dat je op chronologische volgorde de details uitwerkt, maar daarvoor moet je al veel vroeger uit gaan tekenen wat je wilt gaan doen. Je bent dan veel meer tijd kwijt aan dat uittekenen, terwijl dat vaak voor een groot deel ook uit pseudo-code bestaat.
    1+1=b

  3. #3
    Senior Member
    Join Date
    Jul 2008
    Location
    Ertvelde, Belgi?½
    Posts
    158
    Beste,

    Nope, had de links via Twitter reeds geplaatst en daar gebruik ik bv Bit.ly

    Ik zou de artikelen ook kunnen vertalen, dat is op zich het probleem niet. De twee artikels die er staan zijn het begin van een serie. Bedoeling is om steeds een stapje verder te gaan en uit te leggen waarom.

    Uw manier van werken is niet slecht hoor, maar vaak merk ik dan dat mensen inderdaad routines schrijven van pagina's en dat nooit meer refactoren. Uw aanpak is prima, mits je bereid bent om af en toe eens een aantal zaken anders aan te pakken en te refactoren.

    Groeten,


    Stefaan

  4. #4
    Dat is inderdaad een risico. Zolang ik nog ergens mee bezig ben ben ik niet bang om te refactoren, graag zelfs.
    En het is ook een risico als je nog geen goed beeld hebt van wat je gaat doen. Als je beginner bent, of wanneer je een complex probleem moet aanpakken is het niet de beste manier van werken, maar als je een hoop code moet schrijven die voor het niveau waarop je werkt relatief eenvoudig is, dan bespaar je je een hoop werk.
    1+1=b

  5. #5
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Zoals ik zei op je site, Stefaan, vind ik je artikel een goede basis om iets uit te leggen. Maar had dan iets gepakt wat je meerdere keren gebruikt. Dat is naar mijn weten (ik vind het een duur woord) refactoring een logische keuze. Om een class unit te maken en deze maar twee keer op te roepen (voor het openen en sluiten) vind ik nogal onnodig en op dat moment onoverzichtelijk.

    (In het Nederlands is het toch wat makkelijker te uiten, merk ik )
    Delphi is great. Lazarus is more powerfull

  6. #6
    Senior Member
    Join Date
    Jul 2008
    Location
    Ertvelde, Belgi?½
    Posts
    158
    John,

    Zoals ik ook al via de site zei, zal je het uiteindelijk ook meerdere keren gebruiken. Denk maar bv aan het bewaren van form settings, het bewaren van grid columns, app settings ...

    Ik nam gewoon Application Settings omdat het iets eenvoudiger uit te leggen is.

    Je zal die code 2 keer gebruiken ... 2 keer in iedere app die je maakt, 2 keer voor iedere form waar je height / width en ander zaken wenst bij te houden, ... En zo begint het.

    Ja, het is de moeite niet voor 2 keer ... en plots heb je het een 3de keer nodig, bwa nog een copy paste meer ... en een 4 de en een 5 de keer nodig. En dan is er plots een probleem omwille van het feit dat je niet meer de registry wenst te gebruiken maar bv een INI file omwille van Cross-Platform compliance, en dan begint de fun.

    In mijn opzet, heb je iets meer tijd gespendeerd in het begin, maar de eerder vermelde aanpassing dient maar op 1 plaats te gebeuren. In de traditionele denkwijze kon je nu alle apss / forms / ... aflopen waar je die code staan hebt, krijg je bug reports die opnieuw geopend bent omdat je ergnes iets vergeten bent, ...

    In mijn opzet heb ik die class, en kan ik die eenvoudig opnieuw gebruiken in een andere applicatie, terwijl ik toch code reuse heb en op een OO manier aan het werken ben.

    Bij mij is Code Reuse dus iets totaal anders dan Copy / Paste van code. Iets wat ik maar al te vaak zie gebeuren.


    Groeten,



    Stefaan

  7. #7
    JKuiper, het is toch niet zo gek dat je een losstaande functionaliteit in een losse class stopt, en dat die dan in een aparte unit zit? Zeker zo'n settings object is een goed voorbeeld.

    Al vind ik de manier van aanroepen niet zo goed. Ik zou 'm eerder als singleton aanroepen. Op die manier kun je eventueel nog settings cachen. Bij het instantieren van het object lees je de instellingen, en overal waar je het object verder nog gebruikt geef je de gecachte instellingen terug.

    Dat cachen kun je ook weer af laten hangen van het type bron waar je je instellingen uit haalt. Dan komen er factories om de hoek kijken waarmee je verschillende soorten settings-objecten kunt instantieren en deze transparant gebruiken door heel je applicatie. Je settings object kan de instellingen 'live' uit de bron halen, dit cachen, pollen voor nieuwe settings of luisteren naar een push voor nieuwe settings. Juist wanneer je dit in een aparte unit stopt, kun je het zo complex en flexibel maken als je wilt (of eigenlijk: als nodig is).

    Dus nogmaals, juist een settings-object is een goed voorbeeld, en ik hoop dat we de bovenstaande varianten nog gaan tegenkomen in latere artikelen. (En misschien in het Nederlands?)
    1+1=b

  8. #8
    Senior Member
    Join Date
    Jul 2008
    Location
    Ertvelde, Belgi?½
    Posts
    158
    Dat van die Singleton klopt, maar dat dat het misschien iets te ingewikkeld was om daarmee te beginnen. Zou het daar zeker nog over hebben aan het einde van de reeks.

    Er komt nog vanalles :-) Maar ik moet tijd kunnen vrijmaken om het uit te schrijven. Onze website is in het Engels, maar ik bekijk even of ik hier niet een Nederlandstalige versie van die artikelen kan plaatsen (of ergens op de webisite zelf).

    Groeten,


    Stefaan

  9. #9
    Overigens vind ik vaak dat 2 keer kopiëren helemaal niet de grens zou moeten zijn. Als iets een losse handeling is, stop je het in een losse procedure. Als iets een losse groep bewerkingen is, dan isoleer je het in een aparte class.

    Gebruik je die procedure of class maar 1 keer? So be it. Als je de regel aanhoudt dat je dat pas doet bij 'meer dan 2 keer', dan heb je heel veel code dubbel. Bovendien moet je dan maar hopen dat je beide fragmenten vindt, anders heb je een gecentraliseerd stuk code, én een losse kopie elders in je applicatie.
    Last edited by GolezTrol; 24-Mar-10 at 00:38. Reason: Typo
    1+1=b

  10. #10
    Senior Member
    Join Date
    Jul 2008
    Location
    Ertvelde, Belgi?½
    Posts
    158
    Yeps, ik ben ook van die mening. Put your code where it belongs ! Dat is een van mijn stokpaardjes.

    Groeten,


    Stefaan

  11. #11
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Quote Originally Posted by GolezTrol
    Al vind ik de manier van aanroepen niet zo goed. Ik zou 'm eerder als singleton aanroepen. Op die manier kun je eventueel nog settings cachen. Bij het instantieren van het object lees je de instellingen, en overal waar je het object verder nog gebruikt geef je de gecachte instellingen terug.
    En daar ben ik het je mee eens. Dan ga je het meerdere keren gebruiken.

    Ik wilde alleen aangeven dat dat voorbeeld niet een echt voorbeeld is. Tenminste, dat haalde ik uit het stuk. Als je voor iedere form die class gebruikt, dan wordt het ineens anders. Misschien had Stefaan het kunnen aangeven, maar misschien heb ik dat verkeerd gelezen.

    Maar ondanks alles "Petje Af" hoor, om toch maar je stoute schoenen aan te trekken om daar een aantal artikelen over te schrijven. Dat vind ik trouwens voor iedereen die zoiets doet. Zelf ben ik met een artikel bezig over array's, maar dat versloft een beetje vanwege de drukte op dit moment.
    Delphi is great. Lazarus is more powerfull

  12. #12
    Ook als het het in de praktijk maar 1 keer gebruikt blijft die stelling staan.
    1+1=b

  13. #13
    De werkwijze "splitsen als je het twee keer gebruikt" lijkt erg op de werkwijze "aparte routine van maken als het niet anders kan". Ik hou zelf meer van de werkwijze "aparte routine van maken als het kan". Een routine moet zoveel mogelijk één functie uitvoeren, als er meerdere functies zijn dan verplaats ik die naar een aparte routine. Niet omdat het misschien hergebruikt kan worden, maar meer om de code zo zuiver mogelijk te houden. Programmeren is nou eenmaal iets anders dan duizend regels onder elkaar zetten die compileren.

    En inderdaad, ik begin ook meestal met een verzameling lege routines die ik later ga vullen. Het helpt dan wel om die lege routine dan meteen met een todo te vullen anders slipt er te snel een lege routine doorheen .
    Marcel

  14. #14
    Quote Originally Posted by Marcel View Post
    Het helpt dan wel om die lege routine dan meteen met een todo te vullen anders slipt er te snel een lege routine doorheen .
    Ha, ja! Dat is een risico van die methode. Je denkt dat je klaar bent, en dan heb je een applicatie die niets doet.
    1+1=b

  15. #15
    ..maar wel heel snel is

    Ik ga nog eens aandelen nemen in ModelMaker Code Explorer, maar deze ondersteunt deze werkwijze erg goed. Ik tik de naam van de method die ik wil gaan aanroepen en dan CTRL+ALT+M. Er komt dan een dialoog waarin ik de method verder kan instellen en deze wordt aangemaakt, inclusief een TODO.
    Marcel

Page 1 of 4 1 2 3 ... LastLast

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •