Comments on: Typesafe ENUM’s http://www.herrodius.com/blog/27 Thoughts from a software developer Wed, 30 Nov 2011 09:13:06 +0000 hourly 1 http://wordpress.org/?v=3.3 By: nils http://www.herrodius.com/blog/27/comment-page-1#comment-821 nils Thu, 18 Aug 2005 23:22:01 +0000 http://www.herrodius.com/blog/?p=27#comment-821 I think you are missing the woods for the trees - the AssessmentItemTypes surely are value objects, so adding themselves to a static array etc. seems to go about it the wrong way. Just create an AssessmentItemTypeCollection, which in turn contains the static TYPES array and has getByID and getByName entries (and can contain further structures to speed up access to these two) - and it is this class which creates and adds new item types to the TYPES array. (and use getters/setters for the AsessmentItemType class :)) I think you are missing the woods for the trees – the AssessmentItemTypes surely are value objects, so adding themselves to a static array etc. seems to go about it the wrong way.

Just create an AssessmentItemTypeCollection, which in turn contains the static TYPES array and has getByID and getByName entries (and can contain further structures to speed up access to these two) – and it is this class which creates and adds new item types to the TYPES array.

(and use getters/setters for the AsessmentItemType class :) )

]]> By: Greg Burch http://www.herrodius.com/blog/27/comment-page-1#comment-820 Greg Burch Tue, 16 Aug 2005 22:54:40 +0000 http://www.herrodius.com/blog/?p=27#comment-820 One thing I would do, strings or not, is make all those identifiers constants that way if and when they change they are all in one place. It also helps identify uniqueness since all of the constants are defined in one place. I personally try to not use node names at all as identifiers but always have an id field that is used. The nodes define the structure and their attribute define the metadata, I don't mix them. One thing I would do, strings or not, is make all those identifiers constants that way if and when they change they are all in one place. It also helps identify uniqueness since all of the constants are defined in one place. I personally try to not use node names at all as identifiers but always have an id field that is used. The nodes define the structure and their attribute define the metadata, I don’t mix them.

]]> By: Christophe http://www.herrodius.com/blog/27/comment-page-1#comment-819 Christophe Tue, 16 Aug 2005 21:01:24 +0000 http://www.herrodius.com/blog/?p=27#comment-819 Hi Greg, thx for the feedback. About the id's: using strings as assessmentitem identifiers just felt better when reading or correcting the XML files. The QTI standard also uses strings as identifiers ("choiceMultiple" for multiple choice assessmentitems for instance), though this is not the reason we chose strings. Mentioning QTI, I was just thinking that in order to assign one of the types to an assessmentitem parsed from a QTI XML file, we would need to extend the constructor of the AssessmentItemType to accept the QTI identifier as well. And what if more XML structures needed to be used...I think we'll need to rethink the design. Hi Greg,

thx for the feedback. About the id’s: using strings as assessmentitem identifiers just felt better when reading or correcting the XML files. The QTI standard also uses strings as identifiers (“choiceMultiple” for multiple choice assessmentitems for instance), though this is not the reason we chose strings.

Mentioning QTI, I was just thinking that in order to assign one of the types to an assessmentitem parsed from a QTI XML file, we would need to extend the constructor of the AssessmentItemType to accept the QTI identifier as well. And what if more XML structures needed to be used…I think we’ll need to rethink the design.

]]> By: Greg Burch http://www.herrodius.com/blog/27/comment-page-1#comment-818 Greg Burch Tue, 16 Aug 2005 20:38:27 +0000 http://www.herrodius.com/blog/?p=27#comment-818 Well in your case I would definately go with the second not only because it keeps private's, private, but because its just more natural. However why didn't you stick to ID's? When using strings like that on a larger scale you would have to actually localize your code rather than defining them as a constant (or as close as you can in AS) -Greg Well in your case I would definately go with the second not only because it keeps private’s, private, but because its just more natural. However why didn’t you stick to ID’s? When using strings like that on a larger scale you would have to actually localize your code rather than defining them as a constant (or as close as you can in AS)

-Greg

]]>