+1 On Dec 14, 2014 7:01 PM, "Adam Estrada" <[email protected]> wrote:
> +1 > > > > > On Dec 14, 2014, at 4:53 AM, Martin Desruisseaux < > [email protected]> wrote: > > > > Hello all > > > > Thanks Marc for the feedback. > > > > About AbstractAutoChecker, no problem as the goal sound nice. I suggest > > to just move them in some internal package until the API settle down. We > > can move it back to a public package (it can be logging, or other) once > > the API look fine. > > > > Martin > > > > > > Le 14/12/14 18:47, Marc Le Bihan a écrit : > >> => The goals of these (yet still incomplete) classes are not to log > >> messages, even if they are doing this too, it's to grant the objects > >> inheriting them the ability of auto-checking themselves, and if they > >> find some troubles then, to list all the errors, warnings they can > >> find and not only the first one. But, I have not put the parts doing > >> the auto-checking of the objets yet and I understand really well why > >> find these classes gruesome ! I am really sorry ! Soon I will complete > >> these classes. > >> The overall idea of these classes is to allow the API to check an > >> object entirely before doing something important with it. Most of the > >> time, I use this feature before inserting or updating a business > >> object into a database. I ask, for example, my Customer object about > >> itself : "Do you feel ok ?", if the object replies : "no, I have no > >> Name" or something else, I will throw an InvalidCustomerException. > >> Because if I carry a Customer object from function to function it has > >> to be ok (in memory at least) : it has respect some core rules. This > >> kind of defensive programming is really useful when you are reading > >> business objects from a database that has not be written by you and > >> seldom contains errors you cannot figure easily : you detect theses > >> errors immediately. And silently or not, depending what you want. > >> I will move this classes outside the log package, even if they will > >> stay on utility jar. > >> > >> Marc. > > >
