<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <div class="moz-cite-prefix">El 27/4/22 a las 13:56, Hilaire Fernandes via Cuis-dev escribió: </div> <blockquote type="cite" cite="mid:e7766d4a-e475-f7cc-3832-17b62a9b9381@drgeo.eu"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> Hi, I don't understand the PreferenceType interest, why not subclassing Preference for specific model and behavior. </blockquote> Personally I like the idea of being able to augment current preferences in Cuis with type information, without introducing new classes. We could go ahead and annotate current preferences with preferenceType: Boolean,Integer,Color etc. <blockquote type="cite" cite="mid:e7766d4a-e475-f7cc-3832-17b62a9b9381@drgeo.eu"> The visitor pattern makes the understanding more complex (your code snipped really show it) and as I understand it (I never used that pattern), it is for situation where the model can't be modified. It is not the case here as we are just discussing on the most appropirate model </blockquote> I think I would use a Visitor in the end in any case. Let's say you subclass Preference class and create StringPreference class. How do you decide what class of widget to use for editing it? You would "hardcode" the widget class somewhere in StringPreference class? My preference is to use a Visitor (that's how it is done in my packages; I have a PreferenceWidgetBuilder that given a preference type builds a widget for it. ). <blockquote type="cite" cite="mid:e7766d4a-e475-f7cc-3832-17b62a9b9381@drgeo.eu"> I am slightly concern it will be over engineered. </blockquote> I understand. This is how I would do it, and see it as a price to pay in order to prevent introducing new classes and for the possibility of having separate widget building objects. But have no problem with doing it in some other way if it is decided that this is unnecessarily complex. Mariano </body> </html>