Copy and paste programming: Waar ligt de grens?

[SvMp]

Ik zit met een dilemma dat kan leiden tot een anti-pattern dat op de Engelstalige Wikipedia wordt beschreven als copy and paste programming ( Wikipedia: Copy and paste programming ).

De vraag is: Waar ligt de grens?

Concreet voorbeeld: Ik heb een back-office gebouwd met een aantal dialogen waarin bepaalde gegevens worden beheerd. In die dialogen kunnen elementen worden toegevoegd, gewijzigd en verwijderd. Dat varieert van gebruikers en gebruikersrechten tot verschillende produkten. Programmeertaal: PHP.

Die dialogen hebben erg veel met elkaar gemeen. Invoer wordt gevalideerd, een formulier wordt gegenereerd, gegevens worden gelezen of geschreven etc.. Veel herhaling, wat mij erg doet denken aan copy-and-pate programming.

Ik laat wel zoveel mogelijk doen door classes, zoals het genereren van een form en alle database bewerkingen. De vraag is hoe ver kan ik daar mee gaan? Ik zou een generieke class kunnen ontwikkelen voor alle dialogen. Helaas zijn er veel verschillen waardoor die class complex wordt. Zo hebben produkten foto's of filmpjes, maar gebruikers niet. Gebruikers hebben weer een aparte tabel waarin hun rechten worden beheerd. Gebruikers kun je in de back-office zoeken op grond van een naam of e-mail adres, produkten op een heleboel kenmerken, etc.. Hierdoor zijn de dialogen behoorlijk verschillend, maar toch met veel overeenkomstige code. In welke mate is dat te beschouwen als een anti-pattern?

[Voor 0% gewijzigd door SvMp op 15-06-2011 13:47. Reden: Vermelding PHP toegevoegd]

[Stoffel]

Ik weet niet in welke omgeving je programmeert, maar als dat OO is (waar het wel op lijkt gezien je het over een class hebt), ben je volgens mij op zoek naar overerving/inheritance. Daar kun je de gedeelde functionaliteit mee onderbrengen in een class, daar gespecialiseerde classes van afleiden en dan per afgeleide class de niet gedeelde functionaliteit implementeren.

Wikipedia: Inheritance (object-oriented programming)

[SvMp]

@Stoffel: Ik werk volledig object geörienteerd (met PHP, vergeten te vermelden).
Overerving kan zeker een verbetering zijn. De vraag is wel in hoeverre. Het eerste waar ik aan denk is een soort van sjabloon. Een method voor validatie van een form, een method voor delete-dialoog, een method voor wijzigen-dialoog etc.. Erg veel standaard code toevoegen vind ik lastig. Bijvoorbeeld het valideren. Elk form heeft andere kenmerken. Ik heb er wel eens aan gedacht om dat allemaal op te slaan in een data-structuur, inclusief eventuele foutmeldingen, maar het wordt al gauw complex.

[LauPro]

Het ligt aan de structuur van je applicatie. Als je een registratieformulier hebt voor een makelaar en een klant, dan kan je dat misschien beter samenvoegen. Tenzij je van een makelaar veel meer informatie vraagt dan van die klant, dan is het handiger om op te splitsen.

Zo kan er ook minder stuk gaan als je gaat klussen aan die main class. Natuurlijk kan je dat ook weer met unit tests afvangen alleen dat vertraagt wel je ontwikkeling als 1 change 10 formulieren breekt.

[Anoniem: 42791]

Ik vind het een erg algemene vraag... Je zou eens moeten kijken welke code dan precies gedupliceerd is en die steeds afsplitsen in eigen classes en die class gebruiken in je code. Maak eens een lijst met code die je steeds herhaalt, verzin er een mooie naam voor en steek het in een klasse...

Ik vind overerving nu niet direct een oplossing voor het algemene probleem van code duplication. Overerving is maar een van de mogelijkheden die je hebt in een OO omgeving en vaak niet eens de beste.

Om het wat concreter te maken:

- Hoe ik validatie oplos in PHP.
In alle forms moet er gevalideerd worden. Je krijgt invoer, wil deze checken en je wil als het goed is verder gaan en als het niet goed is foutmeldingen weergeven. Een form bestaat uit meerdere velden en dus uit meerdere validaties.

Ik maak hiervoor een FormValidationResult dat twee velden heeft
- een boolean $isValid. Deze geeft aan of het form als geheel valide is.
- een collectie (array) met FieldValidationResult objecten. Deze class heeft ook een boolean $isValid
die aangeeft of het veld valide is en een $message die je weer kunt geven als het mis is.

Voor PHP zelf zou ik een template engine gebruiken (Smarty bij voorkeur) en dan zo'n heel FormValidationResult object teruggeven aan de Smarty template waar alles in zit.

Ik schrijf verder per veld of per veldtype een validatieklasse (FirstNameFieldValidator, LastNameFieldValidator, EmailValidator, DutchZipValidator, etc).

Ik gebruik deze aanpak eigenlijk in al mijn PHP projecten en ik kan de code dus ook gewoon hergebruiken.

[Voor 6% gewijzigd door Anoniem: 42791 op 15-06-2011 14:06]

[djc]

De vraag waar je de abstractie precies moet leggen is denk ik een van de grote fundamentele problemen van het programmeren. Ik denk dan ook niet dat wij daar voor je gaan uitkomen. Zoek naar abstracties die niet of nauwelijks "lekken" (zie Joel Spolsky over leaky abstractions) en kijk welke abstracties je het beste helpen je code te organiseren op een manier dat je snel features kunt toevoegen en verwijderen.

[Grijze Vos]

Ik denk wellicht veel van de dingen die je wilt doen goed ingevuld worden door bestaande frameworks. Niet dat je per se een bestaand framework moet gebruiken, maar het kan geen kwaad om een keer een kijkje te nemen in de keuken van die frameworks hoe ze de dingen afhandelen.

Als je wat duidelijke voorbeelden geeft kunnen we in dit topid wellicht gerichter antwoord geven op hoe je bepaalde dingen aan kunt pakken.

[ameesters]

hoevaak copy & paste: rule of three(Wikipedia: Rule of three (programming)), daarnaast heb je ook nog DIE(DRY) die je kunnen helpen KISS is ook wel een mooie filosofie.

Daarnaast als veel classes op elkaar lijken maar toch net iets anders moeten doen, zou ik een abstract class maken, die je andere classes weer extenden, moet je wel oppassen dat het geen god object wordt...

als je zoekt naar een soort van sjabloon, kan je naar interfaces kijken

[Voor 26% gewijzigd door ameesters op 23-06-2011 16:46]

[Glorificationer426]

Anoniem: 42791 schreef op woensdag 15 juni 2011 @ 14:03:
Maak eens een lijst met code die je steeds herhaalt, verzin er een mooie naam voor en steek het in een klasse...

Ik vind overerving nu niet direct een oplossing voor het algemene probleem van code duplication. Overerving is maar een van de mogelijkheden die je hebt in een OO omgeving en vaak niet eens de beste.

Om het wat concreter te maken:
[...]

Pas sowieso wel op dat je geen classes gaat verzinnen als verzamelbak voor functionaliteit waarvan je wilt overerven. Een class moet wel (althans in mijn optiek) zinnig zijn als entiteit. Anders heb je het al eerder over een namespace.

[ameesters]

Glorificationer426 schreef op vrijdag 24 juni 2011 @ 16:05:
[...]

Pas sowieso wel op dat je geen classes gaat verzinnen als verzamelbak voor functionaliteit waarvan je wilt overerven. Een class moet wel (althans in mijn optiek) zinnig zijn als entiteit. Anders heb je het al eerder over een namespace.

een klasse is altijd zinnig als entiteit, het is wat procedureel en object georiënteerd van elkaar scheid, en een klasse is altijd een verzamelbak van methodes die je aanroept. Alhoewel, als je 1 functie nodig heb verantwoord dat niet een complete klasse, maar aangezien je nooit weet wat de toekomst brengt voor je "hobby projectje", kan het handig zijn om het wel in klasse te zetten, en goed na te denken over de structuur van je project. daar zijn frameworks dan weer handig voor, je bent in een vroeg stadium al bezig met een model waar je geen tijd aan heb hoeven te verspillen.. een nadeel is dan weer is dat je moet leren hoe het werkt...

Het komt allemaal neer op ervaring en afwegingen, maar daarnaast moet je ook weer niet blind af gaan op je ervaring. Uitzonderingen zijn er namelijk altijd, en verandering nog meer, niks beweegt zo snel als de ict, en het lukt nooit evengoed om alles bij te houden. Maar de (ontwikkel) filosofieën zullen altijd blijven gelden.

Dat merk ik wel steeds meer in mijn omgeving, allerlei Cargo Cult programmers, die dingen implementeren zonder te weten wat het doet of wat het inhoud... of patterns totaal verkeerd toepassen. Maarja, dat is een kwestie van opvoeden...

Volgens mij ben ik een beetje aan het ratelen nu, laat ik maar even koffie gaan zetten!

[R4gnax]

ameesters schreef op vrijdag 24 juni 2011 @ 21:36:
een klasse is altijd zinnig als entiteit, het is wat procedureel en object georiënteerd van elkaar scheid, en een klasse is altijd een verzamelbak van methodes die je aanroept.

Een klasse is enkel dan zinnig als entiteit als het een duidelijk toegekende en geisoleerde rol vervuld. Dat gaat wel iets verder dan gewoon een verzamelbak van methods. Klassen behandelen als het laatste is vaak het start punt van het god class anti-patroon.

[Kajel]

ameesters schreef op vrijdag 24 juni 2011 @ 21:36:


een klasse is altijd zinnig als entiteit, het is wat procedureel en object georiënteerd van elkaar scheid, en een klasse is altijd een verzamelbak van methodes die je aanroept.

Dit is pertinent niet waar! De data die encapsulated is door de class (fields) is net zo belangrijk als de behaviours (methods). Een class zonder data, wordt al gauw een soort singleton class/verzameling static behaviours zonder context.
De methods in een "normale" class, zijn er bijna altijd om de state van het object te beinvloeden. Dus om de data in de fields te bewerken.

Inheritance is overigens heel vaak niet de juiste oplossing. Een veel gebruikte stelregel: Favor 'object composition' over 'class inheritance'. Daar is een hoop voor te zeggen, omdat je dan de verschillende componenten uit je applicatie loskoppelt.

Wat betreft forms waar verschillende velden/soorten data al dan niet in moeten zitten: kijk eens naar verschillende Design Patterns die je daarbij kunnen helpen. Een goede bron van informatie is het boek "Design Patterns" van de "Gang of Four".
Ik zou me bijvoorbeeld kunnen voorstellen dat je een basis Form class maakt, die vervolgens decorate met de juiste elementen, volgens het Decorator principe. Ook zou je m.b.t. validation kunnen denken aan het gebruiken van Dependency Injection. Dan geef je dus de juiste validator at runtime mee aan de form.

[Ruudjah]

Lees "Clean code". Zeer goed advies door industriele grootnamen gebacked (Stroustrup, Knuth, etc). Dit boek is hard aan het stijgen op mijn top 10 mustreads voor devvers. Als in top5 of top3.

Copy'n paste code voor domeinlogica is in 99,99% van de gevallen not-done. Voor UI is dit anders: Een MessageBox is een van de beste voorbeelden van mislukt hergebruik van code. "Do you want to save this document?" met de knoppen "Yes" en "No" is faalhazerij van de eerste orde gezien vanuit UX perspectief. Er moet natuurlijk "Save document" en "Don't save document & discard changes" op de knoppen staan. Met icoontje die een toepasselijke metafoor weergeeft. Daar zal best code in zitten wat andere dialogen/widgets hebben wat er sterk op lijkt, maar toch anders is.

[Voor 7% gewijzigd door Ruudjah op 10-07-2011 12:15]

[Anoniem: 82076]

In geval van een simpele message box (met een titel, een boodschap en twee knoppen) kan je de variabele delen nog wel als parameters meegeven, maar bij meer uitgebreide dialogs kan Inversion of control een uitkomst bieden (en is ook beter van toepassing van inheritance). Je zou dan een algemene ModifyElementsDialog class krijgen, die een aantal objecten krijgt aangeleverd -- zoals een Authentication class, een ContentProvider class, etc.

Heb je dialogs die echt functioneel anders zijn, dan moet je er ook een aparte class van maken, natuurlijk.

[GewoonWatSpulle]

Waar ligt de grens?

Heeft iets of iemand je ooit al eens tegengehouden?
Moet de applicatie snel klaar zijn of goed in elkaar steken?

Jouw voorbeeld doet mij denken aan een formbuilder*-class met een aantal velden en validaties welke sterk overeenkomen met elkaar dus mogelijk extended van een basis formuliertje?

DRY: Don't Repeat Yourself, dus ook niet te veel CTRL+C en CTRL+V** toepassen, vind ik een vereiste bij een groter project.


*formbuilder-class een waarin je opgeeft AddTextbox etc. class->output() resulteert dan in de HTML code
** * GewoonWatSpulle denkt terug aan zijn eerste "AI" voor een boter, kaas & eieren tegenstander, dat waren VEEL if-statements, zo goed dat je kon niet winnen alleen gelijk spelen! blij als een kind(14) was ik toen!