Clever Geek Handbook

Aconcagua: Base Units - Would Comparison Comparison Be Better Than Identity?

I learned in another question that BaseUnits should be single. This has a number of disadvantages, including making the client code a little harder to work with (you have to store the singleton file somewhere and give it access), making it difficult to serialize the code, for example. through fuel.

What is the advantage of this limitation? (I assume users are safe if they download two Aconcagua clients that define BaseUnit subclass: #Pound

differently for example )

In practice, is it worth it, or would it be better to treat BaseUnits as value objects? Especially in light of the fact that the paper itself uses type expressions 1 dollar

that already exclude units of the same name.

+3


source to share


1 answer


I wrote something about this in another post.

Units are not singleton (as Singleton is defined in a gang of four books) and the idea is not to create a class per unit, but to instantiate BaseUnit or DerivedUnit, etc. per unit you want.

So, for example, you can create:

meter := BaseUnit named: 'meter'.
centimeter := ProportionalDerivedUnit basedUnit: meter convertionFactor: 1/100 
              named: 'centimeter'.

And then write:

1*meter = (100*centimeter)

which will return true. When I post in another question, equality is defined as the default, so the id is used.



So, you can do two things to make equality work:

  • To know objects well (using global variables or the global root object to access them like Chalten does)
  • Change # = in Unit and make the two units equal if they have the same name (or create a subclass with this # = definition)

The main reason for using the standard implementation of # = is:

  • This is a more general solution
  • Units (in real life) are unique, so it makes sense to be unique in the model
  • It makes sense to have one "metric" object, rather than create one every time you need it.

The main disadvantage is that you see that the first time you see it, it can be problematic to understand, but again you only need to access the object and solve the problem.

As far as fuel is concerned, the problem can be solved by keeping the root object that defined all units (e.g. TimeUnit in Chalten) or implementing option 2) :-)

Hope this help! Let me know if you have any more questions!

+4


source






More articles:


All Articles