[OOP] DRY bij UserMappers. Exceptions, een lastig concept?
Wouter J
01/03/2014 19:52:18Ozzie, nu ga je weer veel te veel in de theorie over. Ga eerst opzoek naar een praktijk voorbeeld waarin dat gebeurd. Ik ben er nog geen 1 tegen gekomen. In de OO moet je voornamelijk werken met praktijk voorbeelden, je mag niet blijven hangen in het FooBarCat wereldje.
PHP hulp
15/11/2024 12:56:35Ozzie PHP
01/03/2014 20:08:39Misschien heb je gelijk, alleen ik wil niet alles omgooien en overstappen op WAT exceptions als straks blijkt dat ik daar niet (voldoende) mee uit de voeten kan. De WAAR exceptions hebben als nadeel dat je veel dezelfde exceptions moet maken (druist in tegen het DRY princips). De WAT exceptions hebben als nadeel dat je niet exact weet WAAR de exception vandaan komt. Is het inderdaad de exception die jij denkt dat het is, of komt ie (per ongeluk) ergens vandaan waar jij het niet verwacht. Dat is nu een beetje het dubbele gevoel wat ik heb.
Milo S
01/03/2014 20:46:01Even wat schematisch uitgedacht...
DBException, PageNotFoundException etc. etc.
- setError()
-- ExceptionMapper -> save
- getError()
-- ExceptionMapper -> findById /
-- ExceptionMapper -> findByDate
ExceptionMapper
- save()
-- TxtStorage -> create
- findById()
-- TxtStorage -> create
- findByDate()
-- TxtStorage -> create
- delete()
TxtStorage
- create()
- read()
- update()
- delete()
Als ik deze structuur volg, dan zou ik bijna alles met mijn exceptions kunnen doen. Ik kan het opslaan en weergeven en mocht t nodig zijn ook wissen.
De melding die de gebruiker krijg hou ik voor de view pagina, dus return ik naar mijn klasse gewoon TRUE of FALSE. Mocht de view dan een FALSE terugkrijgen geeft hij dus een simpele fout weer. Dat is immers genoeg voor de gebruiker. Ik kan er echter voor kiezen om alle fouten bij te houden in mijn database / textbestand wat ik maar wil.
DBException, PageNotFoundException etc. etc.
- setError()
-- ExceptionMapper -> save
- getError()
-- ExceptionMapper -> findById /
-- ExceptionMapper -> findByDate
ExceptionMapper
- save()
-- TxtStorage -> create
- findById()
-- TxtStorage -> create
- findByDate()
-- TxtStorage -> create
- delete()
TxtStorage
- create()
- read()
- update()
- delete()
Als ik deze structuur volg, dan zou ik bijna alles met mijn exceptions kunnen doen. Ik kan het opslaan en weergeven en mocht t nodig zijn ook wissen.
De melding die de gebruiker krijg hou ik voor de view pagina, dus return ik naar mijn klasse gewoon TRUE of FALSE. Mocht de view dan een FALSE terugkrijgen geeft hij dus een simpele fout weer. Dat is immers genoeg voor de gebruiker. Ik kan er echter voor kiezen om alle fouten bij te houden in mijn database / textbestand wat ik maar wil.