Page 1 of 3 1 2 3 LastLast
Results 1 to 15 of 35

Thread: Reacties op artikel 'Frameworks - Deel 2, De basisarchitectuur'

  1. #1

    Reacties op artikel 'Frameworks - Deel 2, De basisarchitectuur'

    Als vervolg op de theorie die is besproken in het eerste deel uit deze reeks artikelen volgt nu het begin van de implementatie van een framework. In dit artikel is te vinden hoe de theorie in de praktijk kan worden gebracht en welke overwegingen daarbij komen kijken.

    Lees het artikel...

    ...of reageer op dit artikel als reply op deze thread.
    Marcel

  2. #2
    Theorie is erg duidelijk,.. Heb het praktijk voorbeeldje nog niet gemaakt, maar dat gaat zeker komen (als me dat gaat lukken )

    Ga vooral zo door !.

    Succes met het volgende deel alvast

  3. #3
    Ik probeerde hem uit te printen, maar ik verlies de rechterkant van de tekst (ook in de printvriendelijke versie). Ik zal hem zo dan maar eens vanaf mn scherm gaan lezen
    Black holes are where God divided by zero

  4. #4
    Senior Member PsychoMark's Avatar
    Join Date
    Nov 2001
    Location
    Raamsdonksveer
    Posts
    10,269
    Gebruik Opera, die heeft niet dat gezeur met printen wat IE vaak geeft . De printervriendelijke versie doet het hier dan ook prima...
    Qui custodiet ipsos custodes

  5. #5
    TSusjuh.Love.Count>MaxInt Francois Schumans's Avatar
    Join Date
    Dec 2002
    Location
    Vodafone-NL, Business Critical Connections
    Posts
    997
    Originally posted by Savage
    Ik probeerde hem uit te printen, maar ik verlies de rechterkant van de tekst (ook in de printvriendelijke versie). Ik zal hem zo dan maar eens vanaf mn scherm gaan lezen
    Zet de pagina instelling eens op liggend?
    of heb je dat al getried?
    If IDE = Delphi Then Raise Greets.Create('Frenske');
    Else Throw New Greets('Frenske')

  6. #6
    TDelphiDeveloper Baldo's Avatar
    Join Date
    Apr 2002
    Location
    Hellevoetsluis
    Posts
    498
    Ik zal de volgende keer proberen rekening te houden met printvriendelijkheid. De versie op mijn site drukt waarschijnlijk wel goed af.
    Why is it that every time I think I'm holding all the cards, it turns out we're playing chess?
    Download Re-Depend, onmisbaar als je met packages build

  7. #7
    Iets omslachtiger: Ik heb de url van de printvriendelijke versie geopend in Word. (gewoon plakken in de OpenDialog). Deze laat e.e.a. wel goed zien en zodoende kun je ook netjes (als je wilt) paginanummering toevoegen. (Hetgeen geen overbodige luxe is op zo'n lap tekst.)

    De inhoudelijke reactie volgt nog.
    1+1=b

  8. #8

    Thumbs up

    Nou, dat viel dus ook een beetje tegen
    Ik had wel weer eens zin om ouderwets te gaan zeuren, maar de enige serieuze kanttekening die ik had neergezet was de paradox dat je form gebruikt als basis terwijl je in het eerste artikel zei dat het framework geen visuele componenten mag bevatten.
    Helaas geef je hier zelf al antwoord op en omdat ik geen purist genoemd wil worden zal ik de discussie maar niet aangaan of een kaal form nou wel of niet als visueel component gezien moet worden in deze context. Het artikel is gewoon te goed om over te zeuren, flauw hoor

    Toch even proberen:
    Ik vind dat je misschien toch een risico creëert door toch een vrij belangrijke rol voor dit basis-form te reserveren. Vooral het overzetten naar andere platvormen, of bijvoorbeeld een overschakeling naar een web-interface zal hierdoor een heel stuk lastiger worden. Natuurlijk is dit maar voor het voorbeeld. In de praktijk zal je misschien wel een basisklasse voor de GUI maken waar de programmeur dan nog keuzes in kan doen over wat voor type interface er gekozen gaat worden.

    Verder een heel goed artikel dus, dat goed laat zien wat er allemaal kan, zonder ons te overspoelen met ingewikkelde details. Wel heel interessant hoe je aan het eind van het artikel nog even het 'ontwerp' (Deel 1) erbij pakt om te kijken of je implementatie (Deel 2) nog aan dat ontwerp voldoet. Ik denk dat dit in de praktijk veel te weinig gebeurt.
    1+1=b

  9. #9
    TDelphiDeveloper Baldo's Avatar
    Join Date
    Apr 2002
    Location
    Hellevoetsluis
    Posts
    498
    Originally posted by GolezTrol
    [...]
    Ik vind dat je misschien toch een risico creëert door toch een vrij belangrijke rol voor dit basis-form te reserveren. Vooral het overzetten naar andere platvormen, of bijvoorbeeld een overschakeling naar een web-interface zal hierdoor een heel stuk lastiger worden. Natuurlijk is dit maar voor het voorbeeld. In de praktijk zal je misschien wel een basisklasse voor de GUI maken waar de programmeur dan nog keuzes in kan doen over wat voor type interface er gekozen gaat worden.
    [...]
    Je hebt helemaal gelijk. Daarom is er nog een hogere functie class, waarin nog geen GUI gekozen is. Je Web GUI zou je in een afgeleide daarvan kunnen kiezen, hoewel de afbakening van het framework stelt dat ik er geen rekening mee hoef te houden.

    Wat betreft je opmerkingen over het form en "non-visual": Psychomark gaf bij het vorige artikel al aan dat het soms best handig kan zijn om een deel GUI toch het framework in te trekken. Dit toont alleen maar aan dat de regels van een framework in de praktijk best moeilijk na te leven zijn en dat je af en toe best om wille van het praktische een wat meer vrije interpretatie aan sommige definities mag geven. Dat houdt het werkbaar

    Dank voor je feedback trouwens!

    [edit]Bedankt toegevoegd[/edit]
    Why is it that every time I think I'm holding all the cards, it turns out we're playing chess?
    Download Re-Depend, onmisbaar als je met packages build

  10. #10
    Hoi Baldo,

    Wat zien ik nou?? Kom jij ook uit Hellevoetsluis? We moeten elkaar dan ZEKER eens ontmoeten!

    T.a.v. je artikel: erg goed! Leuk om te lezen dat anderen hier ook mee bezig zijn. En erg goed geschreven!

    Ik heb maar één opmerking:

    Je schrijft: maak alle protected en public methods "virtual".

    Hier ben ik het niet mee eens, om de volgende redenen:

    1) Wat als een andere ontwikkelaar iets maakt op basis van jouw code, en jij later je code update en een extra virtual method bij maakt met een zelfde naam als welke de andere ontwikkelaar ook toevallig had gekozen.. Dan werkt zijn code niet meer.

    2) "virtual" erachter zetten betekent automatisch dat je de illusie wekt dat je ooit deze code nog wilt overriden. Soms is het beter om de gebruiker gewoon te vertellen: luister, dit is de uiteindelijke versie.

    3) "virtual" method tables zijn langzamer dan static methods.

    Pas heb ik een opmerkelijk interview gelezen met Anders Hejlsberg, "chief architect" van de C# .NET taal, en deze man heeft in het verleden eerst turbo-pascal ontwikkeld en daarna Delphi, dus hij weet van wanten. Een erg interessant artikel.. hier de link:
    http://www.artima.com/intv/nonvirtual.html

    Met vriendelijke groet,

    Nils Haeck
    (ook uit Hellevoetsluis)
    --Nils Haeck
    Scientific Software Developer

  11. #11
    Een kleine reactie daarop:
    2) "virtual" erachter zetten betekent automatisch dat je de illusie wekt dat je ooit deze code nog wilt overriden.

    Eén woordje vergeten: Je vertelt ermee dat je deze code wilt kunnen overriden.

    Hoewel de VMT vast wel wat performance kost, zal dat in de praktijk wel meevallen. Ik denk daarom ook dat zodra er maar een klein beetje twijfel is een method gewoon virtual moet zijn. Ik ben er al regelmatig tegenaan gelopen dat ik een VCL class niet kon overriden waardoor ik i.p.v. een enkele regel code bijna de hele class moest kopieren.
    Een andere issue is namelijk de keuze tussen protected en private. Ik had om een gegeven moment het probleem dat ik een method wilde overriden, maar deze neit virtual was. Het kopiëren van de code in die method naar mijn eigen method in de afgeleide class bleek ook niet te werken omdat die code nog wat private methods aanriep die ik in mijn afgeleide dus niet aan kon roepen zodat ik hiervoor ook truuken uit moest halen (lees: heel veel code kopiëren).

    Eén regeltje code en verder inherited aanroepen had genoeg kunnen zijn als dat kleine woordje virtual daar had gestaan.

    Wanneer je natuurlijk een class hebt zoals bijvoorbeeld een TList achtige met een method die Heel Vaak wordt aangeroepen, dan kun je eventueel wat overridability inleveren voor performance winst, maar zeker in zo'n soort framework denk ik toch dat flexibiliteit voorop staat.
    1+1=b

  12. #12
    Leuk artikel, ga zo door!

    En dan nu weer een kritische blik:
    het verhaal klopt, maar is een beetje moeilijk. Even analyserend waar dat door komt: allereerst in de opbouw van het verhaal zit wat mij betreft een beetje teveel top-down, big bang. Met iets meer successive disclosure, bottom up, kan het nog wat makkelijker worden. Wat mij betreft een opdeling per ontwerpprobleem dat je wilt aanpakken met een stukje code, en die dan iteratief uitbreiden om ieder volgend ontwerpprobleem op te lossen. Als je bijvoorbeeld een keer hebt laten horen dat je objecten constructors en destructors hebben hoef je daar verder geen aandacht meer aan te besteden, en dat ruimt lekker op in de class diagrammen.
    Vervolgens koppel je naar mijn smaak de functionaliteit te hard aan de user interface, maar dat heb je zelf al gezien. Je functies (een woord met veel te veel betekenissen, waar voor mijn gevoel processen, of use cases, beter past) hebben eigenlijk geen inheritance relatie met de user interface. De architectuur kan denk ik nog wat helderder worden door aparte UserInterfaceVoorFunctie objecten in te voeren. Die kunnen dan de verantwoordelijkheid op zich nemen voor het aanmaken van menus en forms (of webpagina's). Mijn ervaring is dat het vrijwel direct een puinhoop wordt zodra je user-interface en basis-framework door elkaar gooit. De testbaarheid van de code neemt dan drastisch af, en als je met onafhankelijke teams modules ontwikkelt, wil je graag weten of de kans dat de nieuwe module het systeem onderuit haalt nog een beetje redelijk is.
    Als derde mis ik het globale verhaal over de lagen onder het stuk dat je nu beschreven hebt. De gemeenschappelijke objecten die de modules nodig hebben en de database-interface. Door je functie-definitie ontwijk je het keurig, maar daar loop je dan tegen afhankelijkheden aan en versie-management, maar ik neem aan dat je daar liever een apart artikel aan wilt wijden . Oh wacht, met actions heb je natuurlijk ook al een mogelijk conflict tussen de shortcuts.
    Nog een wat meer gedetailleerd probleem: je maakt CreateFunction ervoor verantwoordelijk of er een nieuwe instantie, of een gesharede wordt teruggegeven. De verantwoordelijkheid daarvoor hoort echter bij de functie, niet bij de functionmanager, want de functie is het kleinste zelfstandige onderdeel. Verder mis ik de lokale procedure.

  13. #13
    SillyMember
    Join Date
    May 2003
    Location
    Gent
    Posts
    7,725
    Originally posted by Nils
    Je schrijft: maak alle protected en public methods "virtual".
    <knip>
    Baldo heeft gelijk, maakt niet uit wat Anders H. vertelt en hoe hoog we hem inschatten.
    1) Veel erger: een andere programmeur wil je method overriden en kan dat niet, want ze is niet virtueel. Zeker voor een framework (elk framework) is dit nefast.
    Anders H. gebruikt dit argument ook en geeft het voorbeeld van versioning problemen met Java class libraries. En vergeet er strategisch bij te vertellen dat noch C#, noch Java programming by contract ondersteunen, in tegenstelling tot bv. Eiffel. Dit probleem is trouwens voor een groot deel op te lossen door te werken met expliciete interfaces, ook voor abstracte klassen.
    2) Je weet niet op voorhand welke methods er later en/of door anderen moeten aangepast/uitgebreid/vervangen worden. Indien voor 1 of andere method om duidelijke redenen blijkt dat ze finaal is, maak dan de uitzondering en maak die ene method dan niet virtueel.
    3) Dit komt in mijn ogen zelfs niet in de buurt van een argument.
    All methodologies are based on fear. -- Kent Beck.

  14. #14
    Leuk artikel, ga zo door

    [offtopic]
    printen in landscape gaat wel goed, op de site van Baldo krijg ik hetzelfde probleem
    [/offtopic]
    Black holes are where God divided by zero

  15. #15
    TDelphiDeveloper Baldo's Avatar
    Join Date
    Apr 2002
    Location
    Hellevoetsluis
    Posts
    498
    @ Nils:

    [...]Wat zien ik nou?? Kom jij ook uit Hellevoetsluis? We moeten elkaar dan ZEKER eens ontmoeten!
    Gezellig, biertje doen en over Delphi lullen is altijd gezellig

    [...]Je schrijft: maak alle protected en public methods "virtual". Hier ben ik het niet mee eens, om de volgende redenen:

    Kan ik me voorstellen. Echter, als antwoord:

    1) Die ontwikkelaar leidt af van mijn class, dus moet hij mijn naamgeving van methods volgen.

    2) Niet de illusie, de mogelijkheid. Daarmee bereik je de uitbreidbaarheid van het framework. Let op: je hoeft dit dus niet met alle classes te doen, maar voor een framework is het veelal handig.

    3) Als jij het gemeten krijgt, dan vind ik het stoer Natuurlijk is performance belangrijk, maar dan bij classes die een bottle neck kunnen vormen. Framework classes zijn dat veelal niet. Zie ook feedback van GT.

    Dank voor je reactie en een keertje kletsen lijkt me zeker gezellig!

    @StephanEggermon

    [...]het verhaal klopt, maar is een beetje moeilijk. Even analyserend waar dat door komt: allereerst in de opbouw van het verhaal zit wat mij betreft een beetje teveel top-down, big bang. Met iets meer successive disclosure, bottom up, kan het nog wat makkelijker worden.

    Okee, point taken. Ik leer steeds een beetje meer hoe een goed artikel er uit moet komen te zien...

    [...]Vervolgens koppel je naar mijn smaak de functionaliteit te hard aan de user interface, maar dat heb je zelf al gezien.

    Je moet een keus maken he. Dit houdt het praktisch (=uit de praktijk) voor veel lezers denk ik.

    [...]Je functies (een woord met veel te veel betekenissen, waar voor mijn gevoel processen, of use cases, beter past) hebben eigenlijk geen inheritance relatie met de user interface.

    Functie is inderdaad wat lastig, maar de beste term. Wat zegt bijvoorbeeld use case? Is dat iets wat je recycled ? De koppeling met de UI is volgens mij niet zo sterk. Ik heb besloten een ook class te maken waarmee je een form start, maar ik gebruik in de voorbeeld applicatie 4 classes die helemaal geen specifieke UI hebben; ze starten een browser.

    De architectuur kan denk ik nog wat helderder worden door aparte UserInterfaceVoorFunctie objecten in te voeren. Die kunnen dan de verantwoordelijkheid op zich nemen voor het aanmaken van menus en forms (of webpagina's).

    Kan, maar ik wil het niet te abstract maken. Dan wordt het voor teveel mensen een ver-van-mijn-bed show. En ik wil ik zoveel mogelijk koppelen aan de praktijk van alledag voor de meeste ontwikkelaars en daarbij een framework aanpak tonen.

    [...]Als derde mis ik het globale verhaal over de lagen onder het stuk dat je nu beschreven hebt.
    Ja, klopt. Heb ik niet genoeg aan gedacht in dit artikel. Ik zal proberen er meer aandacht aan te besteden in het volgende deel.

    [...]Nog een wat meer gedetailleerd probleem: je maakt CreateFunction ervoor verantwoordelijk of er een nieuwe instantie, of een gesharede wordt teruggegeven. De verantwoordelijkheid daarvoor hoort echter bij de functie, niet bij de functionmanager, want de functie is het kleinste zelfstandige onderdeel. Verder mis ik de lokale procedure.

    Sorry, ik ben hem even kwijt. Wat wil je precies? De functionmanager (de naam zegt het al) managed de functies. Een functie kan zichzelf niet managen? Wat weet een functie nou van zichzelf opstarten? Ik begrijp ik je niet? En wat bedoel je met de lokale procedure?

    Ik zie gezien je kennelijke ervaring met framework in ieder geval mogelijkheden om mijn artikel ter redactie aan te bieden aan je zodat je er goed op kunt schieten Betere kwaliteit artikelen kan nooit kwaad toch? Interesse?
    Why is it that every time I think I'm holding all the cards, it turns out we're playing chess?
    Download Re-Depend, onmisbaar als je met packages build

Page 1 of 3 1 2 3 LastLast

Thread Information

Users Browsing this Thread

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

Similar Threads

  1. Reacties op artikel 'Zelf een component bouwen'
    By Marcel in forum De website
    Replies: 13
    Last Post: 14-Dec-08, 20:26
  2. Reacties op artikel 'Rave artikel 1: De basis'
    By Marcel in forum De website
    Replies: 14
    Last Post: 26-Jul-05, 10:05
  3. Replies: 18
    Last Post: 30-Sep-03, 20:42
  4. Replies: 9
    Last Post: 25-Aug-03, 21:37

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
  •