Timeline for How to use scala case classes when delegation is needed
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 15, 2015 at 12:27 | comment | added | itsbruce | Multiple repositories would be another reason for considering containers, but I was thinking of other domains with other concerns. Imagine you want to track the insurance status and tax registration of cars; these are things which change (new regulations, changes n cost). I don't think those states should be held in the car class. | |
| Jan 15, 2015 at 9:41 | comment | added | valenterry |
Well, most code will just work with the plain Car, but some code knows about that a car can be registrated and has to work with their registration number, so it will work with RegisteredCar. What do you mean by extra state? Like a second repository where cars can be registrated in?
|
|
| Jan 15, 2015 at 8:57 | comment | added | itsbruce | @valenterry But how much of your code cares about (or should know about) repositories? What happens if you have to create some other context, in a different part of the code, which contains extra information or state about cars? Will you add new case classes? You couldn't, because those states would be orthogonal to repository states. | |
| Jan 15, 2015 at 7:54 | comment | added | valenterry |
Hi, the problem with the Map-approach is, that I want to give a registered car to a function and it should be aware, that this car is registered. I could also go for someFunction(plainCar, registerNumber) but naturally it feels better to group both these arguments into one object, because they belong together - and I called this object RegisteredCar. Extending PlainCar also came to my mind, but I have read in different places that extending a case class is not recommended.
|
|
| Jan 15, 2015 at 1:36 | history | answered | Karl Bielefeldt | CC BY-SA 3.0 |