-
1. Re: Value Objects/Iterator Pattern
> Pattern gurus,
Mr Blah man,
> We have a value object which is composed of node and
> leaf value objects. I initially implemented the
> iterator pattern within the value object to provide a
> special ordered enumeration of potential child value
> objects. However, I am unclear if this is the best
> home for this 'filtered iterator'.
can't you specify a natural order on an ordered list. Obviously the natural order logic needs to be class specific as only you are aware of what 'order' means in your particular object. It is interesting that there is no ordering in simple Objects.
You could then just say
((Comparable) blablabla).compareTo(goodBlaBla)
and have that return a boolean because dealing with anything else than an order of one dimension is something they never taught me in mathematics.
BTW we can create this object in JBoss 4.0 AOP :) we could replace the Object instance in the class pool, <whistle and look like you are not interested, they are watching us> and then we return the overwritten Object class to the calling classloader. I remember lozevy writting a java virus this way in 98 at SUN France. He he.
The collection should then delegate the comparison to the instances. The instance has a notion of its own order that only it understands (what is the measure and the names).
Actually now that I think of it, if you represent the object like vector with so many variables of type "numeric" you can come with the default metric of cartesian spaces. sqrt(sigma values squared) and that be a default metric :) In any case we give you the hand in telling us the order.
The problem you get into is that you need to implement an algorythm that sorts a full collection based on individual one on one comparisons. We know these algorythms though.
> Q: Does it make sense to do it here in the value
> object??
>
> I have done this with domain type objects in the
> past, but am not sure if this violates any value
> object best practices.
forget best practices, code.
> Alternatively, I could perform this sorting at the
> DAO level. Seems to me this sort of behavior is
> conceivable in the VO (or transfer object - whatever
> you wanna call it these days) since the object is
> still immutable. Although this seems to no longer
> make the VO arbitrary and has the smell of business
> logic. Whereas in the DAO I could issue a
> specialized query to sort the data before handing the
> VO over to the app facade.
Well the question of who compares is today by necessity the instance since there is no notion of abstract order by default (based on the numeric leaves for example, or simple String ordering).
The algorythm that goes about placing oneself by one on one comparisons is a classic I suppose.
>
> Example: a Class VO composed of Students. The Class
> VO provides getStudents() and getOrderedStudents().
> getOrderedStudents() is a filtered iterator doing
> some ordering.
In this case the Students must implement the comparable inteface and compare their ranking based on a few key variables, we are not interested in comparing dates of birth but rather score tests and attendance. Your logic can then compare them.
>
> Thanks!
>
> Regards,
> Blah -
2. Re: Value Objects/Iterator Pattern
like I didn't learn anything in mathematics...
Ok the right way to do this is to support
((Cartesian) o).getSize("inInchesPlease"));
and the size algorythm you can either implement returning an int, or we can guess the size of your object with the sqrt(sum of numerics squared) and that provides the default behavior in an AOP aspect that will provide the object with load time creation of the set of interfaces (or proxies if you really want run-time composition). Man IUnknown from COM starts to make sense.
That's it