I'm not crazy about this solution. You wrote a whole wrapper class and a fake for that wrapper class, all of which you have to maintain, when you could just
This solution takes on less technical debt and is also functionally pure and referentially transparent. You know that every time the function is called for a given date object, it will always return the same result, which helps A LOT with debugging.
(Not that there aren't any valid reasons for writing a date wrapper--I've written them before for different reasons.)
Mormon, Christian, Father, Educator, CEO of Thinkster.io, Organizer of @ngconf, @frameworksummit & React Conf. Front end developer, and Software Craftsmanship Evangelist.
Very good. Great alternative solution. Ultimately my solution and your solution are very similar. Two ways to accomplish the same goal.
On a different point, "this solution takes on technical debt". I see no evidence of either solution containing any "technical debt". Cutting a corner is technical debt. Debt is something that usually needs to be paid back. These techniques (like what you showed here) are about improving the quality of code, which if it has any effect on technical debt, is a reduction.
Good point. I was really unclear in my earlier comment. Perhaps "technical debt" isn't exactly the right phrase. When I said "technical debt", I was referring to the additional maintenance cost of the wrapper and the fake(s) and the cost of the additional developer time it takes to understand the codebase fully. Maybe it's not exactly "technical debt" like a hacky workaround that you know you'll have to eventually "pay back" by fully undoing. More like a technical utility bill or a technical property tax--a long term cost that is a lot smaller than a loan but that you don't ever really get rid of.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm not crazy about this solution. You wrote a whole wrapper class and a fake for that wrapper class, all of which you have to maintain, when you could just
This solution takes on less technical debt and is also functionally pure and referentially transparent. You know that every time the function is called for a given date object, it will always return the same result, which helps A LOT with debugging.
(Not that there aren't any valid reasons for writing a date wrapper--I've written them before for different reasons.)
Very good. Great alternative solution. Ultimately my solution and your solution are very similar. Two ways to accomplish the same goal.
On a different point, "this solution takes on technical debt". I see no evidence of either solution containing any "technical debt". Cutting a corner is technical debt. Debt is something that usually needs to be paid back. These techniques (like what you showed here) are about improving the quality of code, which if it has any effect on technical debt, is a reduction.
Good point. I was really unclear in my earlier comment. Perhaps "technical debt" isn't exactly the right phrase. When I said "technical debt", I was referring to the additional maintenance cost of the wrapper and the fake(s) and the cost of the additional developer time it takes to understand the codebase fully. Maybe it's not exactly "technical debt" like a hacky workaround that you know you'll have to eventually "pay back" by fully undoing. More like a technical utility bill or a technical property tax--a long term cost that is a lot smaller than a loan but that you don't ever really get rid of.