Plus this may typically interact with some serialization/materialization
which would use the base format ('red', 'organization', 'kind'), so if
there's any change to the name another mapping format would be required.On Wed, Mar 23, 2016 at 5:41 PM, Peter Uhnák <i.uh...@gmail.com> wrote: > Hi, > > as this probably doesn't have one solution I am interested in your > approach, if you have any. > > The problem is that often you want to create instances (or just return > constants) in some particular domain, e.g. > > Color red. > Color blue. > > Unfortunately this doesn't scale, because putting unary methods on the > class-side is a good way to break your image. > > *1) capitalize* > > doesn't follow method naming conventions > > Color Red. > ParticipantType Organization (uncapitalized returns ClassOrganization) > VisibilityKind Package (package returns package) > > *2) have it on instance-side* > > need for an extra singleton and more typing > > Color default red. > ParticipantType default organization. > VisibilityKind default package. > > maybe #enum could work better? > > Color enum red. > VisibilityKind enum package. > > *3) use ALLCAPS* > > looks like C/Java… ugly af > also same issue as 1) > > Color RED. > ParticipantType ORGANIZATION. > VisibilityKind PACKAGE. > > *4) use some prefix/suffix?* > > may not be enough, can be confusing when implementing a domain with given > specifications > > Color redColor. > ParticipantType organizationType. > VisibilityKind packageKind > > *5) something better?* > > All the above work (obviously) but all are broken to some extent… so it's > picking the best of the worst. -_- > > Any ideas appreciated, > > Peter >
