CodeCaster schreef op woensdag 17 augustus 2016 @ 15:40:
[...]
Wat is er mis mee dan? Als je met data moet werken waarop jij geen invloed hebt, en ook nog eens met gegenereerde klassen, is dit een stuk duidelijker dan telkens maar weer
if (foo.SomeCollection != null && foo.SomeCollection.Any()) { ... } te moeten gebruiken.
Ter info, is voor data dat we zelf onder controle hebben

. Normaliter zijn de properties niet null (kan wel leeg zijn). Verder was deze extension method amper 20 keer gebruikt, op een gigantische code-base. Zulke methodes zorgen voor verwarring.
Wat er mis mee is: ik werk veel in een code base waar ondertussen heel véél extension methods gedefinieerd zijn van het kaliber dat ik toonde. In heel die hoop, wordt er random wél en niét gecontroleerd op NULL. De naam geeft ook niet duidelijk aan of dat er op NULL gecontroleerd wordt. Telkens als ik zo'n methode tegen kom, moet ik naar de implementatie gaan om te kijken wat er in gebeurt. Ik schrijf sneller "if (coll != null && coll.Any()" dan "coll.HasItems". Ik wil standaard code schrijven, zonder 1000 extension methods van buiten te kennen of ze wel of niet op null checken.
CodeCaster schreef op woensdag 17 augustus 2016 @ 17:01:
[...]
Dit verhaal van mij, waarin ik een extension method verdedig die iemand anders belachelijk vindt zonder verder enige context te geven, bevat ondertussen de volgende aannames:
• Er is een API of andere databron waarop we geen invloed hebben.
• Uit deze databron worden klassen gegenereerd om de data uit te lezen. Deze klassen wil je niet aanpassen.
• Deze databron kan voor bepaalde collections zowel een gevulde, als lege, als null-collection retourneren, en alledrie deze gevallen zijn geldig.
• Deze collection-properties komen veelvuldig voor, niet alleen meerdere malen binnen één klasse, maar zelfs in meerdere klassen.
• De programmeur wil niet overal waar deze collection-properties worden uitgelezen, de code
if (foo.CollectionProperty != null && foo.CollectionProperty.Any()) { ... } gebruiken.
Dán
vind ik dat zo'n extension method weinig kwaad kan.
Verdere context nog: extension method was toegevoegd in een algemene library, dat overal standaard gereferencet wordt (soort van standard library in het bedrijf).
• In dit geval niet. Echter, mocht dat het geval zijn, werken we sowieso in lagen. Data van externe partijen komen slechts op één locatie binnen en worden verder getransformeerd naar een intern formaat. Vooral omdat we vaak werken met meerdere leveranciers van ongeveer dezelfde data (of gelijkaardige data). Datastructuren van een externe partij vloeien
niet door in het verdere verwerkingsproces.
• Klasses die gegenereerd worden, zijn over het algemeen partial klasses en zijn perfect uit te breiden in een aparte code file, zodat je niet in de generated code moet zitten aanpassen.
• Wanneer je elke 5 regels (bij wijze van spreken) een controle moet doen of eenzelfde property NULL is, is dat vaak voor mij al een eerste indicatie dat de code niet goed in elkaar zit. Mijn principe is steeds: data van een externe bron moet je niet vertrouwen, doe eerst validaties en onderneem acties voor niet verwachte waarden (waarbij ik een NULL voor een collectie vaak als "niet verwacht" bestempel).
Ik zie ook zeker wel scenario's waarbij zo'n functie nut kan hebben; maar dan nog durf ik te zeggen dat een Extension Method niet de correctie methode is. Elke keer dat een type (waar je zelf geen invloed op hebt) moet uitbreiden met een Extension Method, moet je goed nadenken of dat het écht wel meerwaarde heeft (in plaats van bv een null check minder te moeten typen); zeker op algemene types van het .NET framework. Ik heb zelden het gevoel dat ik methodes mis op types in het .NET framework. Af en toe komt het voor, maar dat zijn wel methodes die iets meer inhoud hebben dan een conditie uitsparen in een if-statement.
[
Voor 58% gewijzigd door
Styxxy op 18-08-2016 02:45
]