Human above all, with pathos, weaknesses and grumpy at times. Speak for myself; think out loud. Direct, seemingly hard faced. Urged to fix things. Am fortunate.
How To Think Of Json (part 1) Heterogenous Containers
You should already be familiar with the idea of heterogeneous containers and what it takes to kick off. In the next series of posts we’ll see how we can think of JSON in such terms.
In the Element class above there are a couple more things other than the type and the name like a builder, an ElementFormat, an equals/hashCode implementation and a Comparable interface so let’s talk about them one at a time.
The builder is there to help us create new Element(s). The main advantage over using the constructor is that it provides reasonable defaults for the ordering of an element and its format. Thus from the client code it looks like only a type and a name is needed for an Element.
The ElementFormat is used for creating the string representation of an Element for a given value. The need for a formatter comes from the fact that some values (e.g. a Date) need to be formatted outside of their #toString implementation. Nevertheless the string format is always of
with the value being formatted each time.
Bare in mind that the Element class merely describes a JSON element in terms of its type and name without holding its actual value.
You should do well to override equals/hashCode, especially when dealing with the Collections framework as you might be getting some unexpected results when doing add/remove operations.
Finally Comparable used with the order property is merely for making testing slightly easier (coming later on) and not really a requirement. Unless you do want your JSON elements sorted in which case is an easy way to go :) In that case you could have instead opted for the builder to increment the ordering for every element created.