Is de keuze afhankelijk van externe data en voldoet het model dan nog wel?

Heb jij nog andere vragen die je zou stellen?

Een service die deze sizes desgevraagd kan ophoesten. Heeft drie methodes: GetSmallPopupUpSize, GetMediumPopupSize, .. – dit in het geval het echt alleen om de sizes gaat. Deze service kan ook Popup-sub-classes of reeds geconfigureerde objecten teruggeven. (als er meer dan alleen de size verschillend is tussen die popups). In eerste instantie kun je de service deze op laten leveren a.d.h.v. configuratie in code, maar hij zou ook een configuratiebestand kunnen inlezen.

Vraag die bij mij heel duidelijk omhoog komt is: wat zijn die verschillende popups met verschillende groottes – is het echt zo dat deze alleen verschillen op grootte? Verder functioneel volledig hetzelfde? En zo ja: waarom hebben ze dan verschillende groottes?

PopUpSize wordt wel altijd gebruikt vanuit de klasse PopUp, die een property van type PopUpSize heeft. Gebruik is dus totaal niet verspreid. Een oplossing zou dus ook kunnen zijn om de enumeration in dit geval te verwijderen en de bijbehorende Size (width/height) direct in PopUp te zetten (omdat het een 1-op-1-mapping is).

Een standaard waarde teruggeven bij een onbekende PopUpSize zou ook kunnen, waarschijnlijk ook in vergelijkbare situaties met willekeurige enumerations. Ik vind het echter wel mooi om een goede “coverage” van mogelijk waarden af te dwingen.

Bepaalde gegevens verplaatsen naar een configuratiebestand en daardoor afdwingen dat bij het inlezen hiervan (en dus bij het starten van de applicatie) het systeem al crasht, is inderdaad wel netter. Ik vraag me alleen af of het de extra moeite waard zou zijn, aangezien deze enumeration in de praktijk waarschijnlijk nooit wordt uitgebreid. Maar netter zou het zeker zijn.

Overigens lukt het mij ook niet om het gebruik van Excepties te allen tijde te voorkomen hoor. :) Maar door de bovenstaande opties langs te lopen weet ik er regelmatig wel een beter alternatief voor te vinden.

Weer een mooi stuk. Doet me wel weer eens goed nadenken over de code die ik tot nu toe heb geschreven. Ondanks je valide argumenten heb ik altijd wel veel gebruik gemaakt van excepties in een domein en is over het algemeen best goed bevallen. Als ik er nu over nadenk had het wel met veel minder excepties gekund.

@Peter jouw code ziet er uit als een onderdeel van UI code. Dus zou je in dat geval kunnen falen of zou je gewoon een Warning willen loggen en een default size terug geven.

Je ziet dit soort excepties vrij vaak, een switch op een enumeratie wordt natuurlijk niet door de compiler gechecked en dan wil je dus een (backup) controle om wijzigingen in de enumeratie te kunnen detecteren.

Echter: dit levert wel een runtime error op! In zekere zin ben je niet heel veel beter af dan dat je applicatie op een later moment ergens laat struikelen over dit probleem. (wel iets)

Er zijn twee richtingen die leiden tot een betere oplossing, denk ik:
1. Je maakt het bepalen van de size helemaal dynamisch: je kunt verschillende groottes en de bijbehorende maten benoemen in b.v. een configuratiebestand, db, etc. – Excepties zijn dan op hun plaats als het configuratiebestand bij inlezen (niet bij gebruik!) niet voldoet aan je verwachtingen. De Excepties dwingen dan pre-condities af op je externe input (het config bestand). Een xml-schema op je configuratiebestand zou nog mooier zijn, daarmee kan dan ook intellisense in je configbestand ondersteund worden. Maar goed, direct na inlezen is vaak eenvoudiger en meestal wel voldoende.
2. Je maakt de sizes juist een echt onderdeel van je applicatie en legt hem beter vast in de code, in de vorm van een Type. Je zou dan kunnen starten met verschillende classes die dezelfde interface implementeren, die 1 methode vereist: GetSize(). Deze neemt de plaats in van je huidige enumeratie (PopUpSize). Als je dit doet, zul je waarschijnlijk gaan bedenken dat deze classes meer kunnen doen dan alleen een grotte vastleggen. Waarschijnlijk zijn het representaties van popups die bepaalde functionaliteit bieden: ideaal om bij elkaar in een class vast te leggen..

Dus: je ziet deze veel en soms is het puur een pre-condition check op een inputparameter. Maar pas op, want enums zijn vaak uitgekleedde classes, waarbij hun functionaliteit over de hele applicatie verspreid ligt. :)

Is het volgens jou ook 1 van de bovenstaande gevallen of toch nog iets anders?

Hieronder nog wel een subtiel voorbeeld uit eigen code. Hier wordt een extension method gebruikt om aan de hand van een enumeration (PopUpSize) een Size terug te geven. Mocht de enumeration niet worden herkend (omdat in de toekomst iemand een waarde hieraan toevoegt), dan wordt er een Exception gegooid. Op deze manier zal bij het uitbreiden van de enumeration (wat zeer onwaarschijnlijk is) snel duidelijk worden dat de bijbehorende extension method nog niet is uitgebreid. Is dat nu geen pareltje van een Exception!

public static class PopUpSizeExtender
{
public static Size GetMeasurements(this PopUpSize size)
{
switch (size)
{
case PopUpSize.Small:
return new Size(636, 256);
case PopUpSize.Medium:
return new Size(670, 384);
case PopUpSize.Large:
return new Size(676, 512);
default:
throw new ArgumentException(”Unknown PopUpSize: ” + size.ToString());
}
}
}