Reacties op artikel 'Frameworks - Deel 1, Theorie'

[Marcel]

Enige tijd geleden ontstond er op het NLDelphi forum een discussie over frameworks. Het is er toen zelfs van gekomen dat een aantal enthousiastelingen bij elkaar kwam om eens te kijken naar een framework in de praktijk. Niet iedereen was natuurlijk in de gelegenheid om daar bij te zijn, dus vandaar deze reeks artikelen over frameworks.

Lees het artikel...

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

[Dees]

Baldo,

erg duidelijk artikel.. ik ben benieuwd naar deel 2!

Ga vooral zo door...

[Anders]

Baldo,

Heel goede artikel, zit nu al in spanning naar deel twee te wachten.
Erg fijn dat je een simpele NLDelphi Framework stap voor stap gaat uitleggen, dan kan ik het misschien ook ooit begrijpen .


PS. Kan je niet een paar dagen vrij nemen

[Rob Bos]

Originally posted by Anders
Baldo,
Erg fijn dat je een simpele NLDelphi Framework stap voor stap gaat uitleggen, dan kan ik het misschien ook ooit begrijpen .

Ik deel diezelfde mening

Deel 1 was in ieder geval een goede uitleg ... nu de implementatie nog ...

Heb je al een deadline ? (maw heb je veel tijd over ? )

GreetZ,

Rob

[PsychoMark]

Wederom een goed en duidelijk artikel, klasse! Het is voor mij ook pas kort geleden dat ik de voordelen van een solide framework heb ontdekt. Dat je jouw kennis hierover in een serie artikelen gooit is dus geweldig, hopelijk kunnen een hoop mensen hier nog van leren!



...inclusief ik

[Francois Schumans]

Originally posted by Dees
Baldo,

erg duidelijk artikel.. ik ben benieuwd naar deel 2!

Ga vooral zo door...

Helemaal mee eens Dees!!
Ik had nog nooit over een framework nagedacht, maar ik zie nu al raakvlakken met de software die wij aan het bouwen zijn!! Rob en ik hebben al meerdere malen nagedacht over iets in de geest van een BaseClass. Zeg maar waarin je de meest basische functionaliteiten en regels in vastlegd omtrent je applicatie.

Een framework noemen ze dat dus !

Een bijzonder mooi verfrissend en verhelderend artikel!

Ik kijk met smaak uit naar deel 2

[StephanEggermon]

Leuk artikel, ik ben benieuwd naar het vervolg. Natuurlijk heb ik wel wat te zeuren:
Ik heb wat moeite met de framework definitie.

Frameworks are reusable designs of all or part of a software system described by a set of abstract classes and the way instances of those classes collaborate.

past beter bij mijn beeld van frameworks, hoewel de nadruk te veel op abstract-instantiatie i.p.v. delegatie ligt.
Komt uit een uitstekend engelstalig artikel over het ontwikkelen van frameworks, http://st-www.cs.uiuc.edu/users/droberts/evolve.html.
Het is me overigens niet duidelijk waarom de classes niet-visueel zouden moeten zijn. Een groot deel van het werk bij het gebruik van een framework bestaat uit het configureren van componenten. Ik zie niet in waarom dat niet visueel zou kunnen gebeuren. Alles beter dan XML-files met de hand editen .
De voordelen die je noemt van een framework, zijn eigenlijk nauwelijks voordelen van een framework, maar die van een software-bibliotheek.

[Vos]

Zeer duidelijk allemaal! Ik ben (net als andere hier) zeer benieuwd naar het vervolg, met name de concrete voorbeelden. Mijn complimenten!

[Baldo]

Originally posted by StephanEggermon
Ik heb wat moeite met de framework definitie. "Frameworks are reusable designs of all or part of a software system described by a set of abstract classes and the way instances of those classes collaborate." past beter bij mijn beeld van frameworks, hoewel de nadruk te veel op abstract-instantiatie i.p.v. delegatie ligt.

Tja, zoals ik al zei is dit de definitie waar ik samen met mijn collega het meest gelukkig mee ben, afgeleid uit een enorme hoeveelheid literatuur over frameworks. Jouw definitie raakt die van ons toch duidelijk: het gaat om een structuur van classes (skelet) en hoe ze samen (moeten) werken (regels). Het is maar waar je gelukkig mee bent, maar grofweg komen ze veelal op hetzelfde neer. Ik moet zeggen dat jouw definitie mij ook wel ligt hoor. Dank voor de link trouwens, nog meer leesvoer over frameworks

Originally posted by StephanEggermon
Het is me overigens niet duidelijk waarom de classes niet-visueel zouden moeten zijn.

Wij beschouwen de GUI als een implementatie op het framework. Vandaar dat wij stellen dat het niet-visuele classes betreft. Natuurlijk zijn er ook weer diverse definities in omloop waarbij de GUI wel binnen het framework zou vallen, het is maar waar je de grens wil leggen. GUI's zijn wat ons betreft te veranderlijk om in een framework te betrekken. Belangrijk is dat je in ieder geval wel een grens trekt denk ik.

Originally posted by StephanEggermon
De voordelen die je noemt van een framework, zijn eigenlijk nauwelijks voordelen van een framework, maar die van een software-bibliotheek.

Daar ben ik het niet helemaal mee eens. Een software bibliotheek gaat volgens mij veel minder ver dan een framework (wederom geldt: het is maar wat je definitie van een software bibliotheek is) en zegt bijvoorbeeld niets of weinig of regels van gebruik die wel degelijk tot voordelen leidt. Natuurlijk zijn er ook wel overeenkomsten (hergebruik van code lijkt me ook een voordeel van een functie bibliotheek), maar het gaat hier om voordelen dat het gebruik van een framework biedt ten opzichte van het niet gebruiken ervan en niet ten opzichte van het gebruik van andere, ook goede, programmeergebruiken.

[Baldo]

En aan iedereen: dank voor de feedback. Altijd prettig om wat respons te hebben zodat ik weet of ik de goede richting op schrijf Uitgebreide reacties als die StephanEggermon kan ik alleen maar toejuichen!!

[PsychoMark]

Originally posted by Baldo
Natuurlijk zijn er ook weer diverse definities in omloop waarbij de GUI wel binnen het framework zou vallen, het is maar waar je de grens wil leggen. GUI's zijn wat ons betreft te veranderlijk om in een framework te betrekken. Belangrijk is dat je in ieder geval wel een grens trekt denk ik.

De GUI zelf valt wat mij betreft ook niet binnen het framework, maar de manier waarop die GUI werkt (of samenwerkt met het framework) kan je natuurlijk wel opnemen in je framework om zo alle applicaties dezelfde look & feel te geven.

In Delphi is dit iets lastiger te definieren, voor mij persoonlijk dan; ik ben zelf nogal bezig met een PHP framework, maar ook hierbij is 't van belang die scheiding te houden: wat is standaard en wat is applicatie-specifiek? Een leuk voorbeeld is denk ik het redirect schermpje wat ik heb (vergelijk 't met een "even wachten" dialoog in Delphi bijvoorbeeld). Dit is in feite 100% onderdeel van de interface, maar aangezien vele applicaties hiervan gebruik maken heb ik besloten 't aan 't framework toe te voegen. Hierbij wordt een standaard dialoog weergegeven. Echter, het framework is flexibel genoeg om die dialoog te kunnen overriden (de implementatie van overriden is overigens een feature van m'n framework, vandaar dat deze optie valt onder het framework ipv een losse gedeelde functie). De override neemt het dan over van het origineel, maar behoudt nog steeds exact dezelfde functionaliteit. GUI van framework gescheiden en toch geintegreerd...



Ik ben geen expert op framework-gebied, maar vind het ook zeer interessante materie, zeker omdat het applicatie-ontwikkeling enorm kan versnellen (ook dit heb ik in de praktijk al gemerkt, en dat op vrij korte tijd)...

[Baldo]

Originally posted by PsychoMark
De GUI zelf valt wat mij betreft ook niet binnen het framework, maar de manier waarop die GUI werkt (of samenwerkt met het framework) kan je natuurlijk wel opnemen in je framework om zo alle applicaties dezelfde look & feel te geven.
[...]
Ik ben geen expert op framework-gebied, maar vind het ook zeer interessante materie, zeker omdat het applicatie-ontwikkeling enorm kan versnellen
[...]

Ik ben ook geen framework expert, maar ik weet er door ervaring inmiddels wel aardig wat over frameworks...

In het framework wat ik op mijn werk gebruik maken we gebruik van hetzelfde principe als wat je noemt: er zit wel een stukje dicht bovenop en het framework kan er gebruik van maken. Maar voor deze GUI kan altijd een alternatief geregistreerd en gebruikt worden, of er kan een afgeleide van gebruikt worden. Wij spreken dan van een "standaard implementatielaag". De opzet wordt dan: framework, met daar bovenop de standaard implementatielaag, met daar bovenop de applicatie implementatie (meer hierover in deel 2 en verder schat ik zo in )

[Johnnny1]

Baldo.

Mooi geschreven. Wordt allemaal iets duidelijker nu.

Ben al nieuwschierig naar Deel2

John

[Anders]

Originally posted by Baldo
...... Dank voor de link trouwens, nog meer leesvoer over frameworks

Misschien kan je wat links geven naar jou "leesvoer over frameworks". Als opwarming voor deel twee

bvd.

[Savage]

Ik snap al een stuk beter wat het nou inhoudt. Het is uiteindelijk het goed gebruiken van classen en methoden?