Why? Why should the Room class itself be aware that something like imperial even exists? And what if we add other distance measures, should be add methods for those too? Seems to go against single responsibility principle (Room knows about non-Room stuff) and open/closed (need to modify Room when a different distance measure is added).
Because room calculating always bound to measure units.
Not should. Could. And I see no problem about.
No. Room calculates it not by itself, but uses external service.
Could be. So what?
Calculate at first room with Room and than convert with DistanceConverter is clear against Information Expert. Any time if required to convert room and so on,⌠developer should to use some other class, instead of use Room only.
Room has to be aware an external service exists to invoke the external service. The idea is that the Room object can act agnostically of its environment; it reports its measurement. If the user wants to take that measurement and pipe it through an external service, that is a choice of the user, not the object.
In real life there is no square measurement without concrete measure unit. This makes no any sense. That means, any time developer uses Room he should use some converter class after that. Those principle of code building brings a lot of troubles. Developer must rememeber a number of some specific classes, instead of just to choice proper Room method.
It⌠has a unit.
By definition, if you need a âconvertMetricToImperialâ⌠your initial value is in a metric unit.
It HAS a unit.
If the USER wants to convert the METRIC unit to IMPERIAL units⌠they would invoke the conversion.
It is not for Room to implement.
That said, the theory of area of a rectangle doesnt give a flip what your units are.
x * y doesnt care if itâs in miles, feet, inches, meters, parsecs. You get Square-Whatever-You-Put-Inâs.
Seems the edit has a bug⌠Inserting another post instead of updating 
I expect what you are trying to say Room should return the desired metric type by utilizing the metric object which is passed as a dependency injection to Room.
If metric is desired, then an Metric object is injected that just pass along the values without doing changes.
If imperial is desired, then an Imperial object is injected, which will convert the metric values it receive.
If internally in the system is using metric (for example mm etc.), and in the event different users/cases should return a different metric, we solve this by passing the desired metric the data should be returned as in a dependency injection, this way you get around the single responsibility issue you mention.
This would be similar to how you deal with Timezones you store the time internally as UTC, and when any interaction happens with the user you convert to/from their timezone.
In both of these cases, I would never recommend doing the conversion in the front end. The conversion should happen automatically before this, all depending on the user/software choices, this way no matter what layer is used to display the data, it will show the same.
And this is how NASA puts the wrong amount of fuel in the rocket.
I donât follow? (I am the OP - no previous experince of OOP at all - brain still very much linear).
Just to put another spanner in the works. This talk of units has got me to thinking. The conversion to imperial doesnât produce a float that is a length in feet - it produces a string that includes the units of feet and inches eg 17Ⲡ9âł. Not sure if that makes any difference to the above discussion? It probably doesnât. An object instantiated by the class Room will have a property width which is a float that is a number of metres. When the script needs to output this value in Imperial that is when the underlying value needs to be converted to a string that is derived from the conversion, I guess.
The argument theyâre trying to make is that Room should incorporate a mechanic by which you can demand Room give you the area in any unit by injecting another object into the room object that automatically converts the unknown-but-presumed-to-be-Metric-of-some-description units in the class to the userâs desired units when they ask for it.
The issue mirrors tales from various agencies around the world collaborating and getting their units mixed up. While I believe the specific one about Gallons to Litres is apocryphal in terms of NASA, similar things have actually occured:
How NASA Lost a Spacecraft From a Metric Math Mistake | SimScale
Gimli Glider - Wikipedia (AKA Air Canada Flight 143)
(and many more besides. There are even books on maths blunders.)
It should be noted to all involved at this point that âMetricâ isnt a unit either. The maths laid out is not âmetricâ to âImperialâ, itâs MetersToFeet. A very specific conversion from one unit to another.
2 Likes
Generally class Room should to return all frequently required infos. In real life this would walk with DI-containers, factories and so on⌠But here we have just a little learn example. And I just trying to explain the main idea.
1 Like
In fact, I think, it is not even that - it is a conversion from metres to a string that expresses that distance in the âfeet and inchesâ format?
I have never heard amount this incident. In the event this is what happened, it is their system/software that failed, not the idea itself.
In this case, the application was feed information in the wrong metric, or the user reads the information believing it was a different metric. Both of these are the case of user error.
If the metric was sent together with the information this would not have been an issue, since if you passed imperial to an application expecting metric, it would convert your data, or promptly ask you to resubmit in metric. (Example, value object for languages that support this)
Similar when displaying the data, if a specific user prefers the data in Imperial, they could receive it as such. Or if it was important the data was in metric, it would be displayed as such with the correct numerator. In addition for an imperial user, there could be displayed a warning indicating that it is metric or another way around.
Utilizing a specific metric, timezone, etc. internally is the only sensible way to handle an application. When you receive the data, you convert it if required, store it, and when feeding it out, convert it again to what the user expects to see.
If we are taking this to the step discussed above, then âMetricâ in this case would for example utilize mm internally, and then have several ways to display the information, i.e. as meters, pretty format ( i.e. X m, Y cm and U mm) etc.
And again similar with Imperial. This way, it is easy to convert between the two, and then display it the desired way. Of course we would only tackle length measurements in this case, but any measurement would be set up similarly.
Now, the question is if you need this or not, all depends on the use case. The benefit of a good structure, is that it is easier to maintain in the long run, but at one point you need to stop, as the advantages are lost to bloating of code.
I canât be the only person thinking of this clip from Spinal Tap re getting the wrong units:
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.