61–70 of 154 posts
Oh god the ‘object oriented’ refactor. I wish everyone who had OO thrust upon them in the early 2000s received some explicit communication that what they were taught is essentially a hoax and bears no resemblance to Alan Kay’s original intention
Earlier quoted context omitted.
The dig against FP is weird since the "good refactor" also uses FP, just a built in one in JS. Which I agree is better, but mostly by being built in and idiomatic, it's still exactly as functional.
I think that was the point - the library added nothing, the same thing could be done with pure javascript.
The first example of a good refactor is a meh refactor at best, and possibly a bad refactor. Array methods such as map or filter are not "more conventional" in javascript; they are "as conventional" as for-loops, and arguably less "conventional", given how for-loops have been around since the introduction of the language. They are also inevitably more expensive than for-loops (every cycle creates an anonymous functio…
> every cycle creates an anonymous function No, that's not how it works. The function is evaluated once before the call and passed as an argument, then internally reused. Also, you're microptimizing. Prioritizing supposed performance over readability. And yes, for-loops and mutable structures are more error prone than map-filter-reduce. The original is OK but could be better.
Yes, sorry; you are right of course.
The first example complained about the refactor appealing to functional thinkers (implying that it would be difficult to grok by the existing devs), but then the “improved” version is virtually the same save for the (unnecessary?) use of Ramda in the first. And while many devs are resistant to try functional ways, this first example reads so much better than the original code that I find it impossible to believe that…
(Raises hand.) I prefer the for loop. Pushing items to an array is idiomatic Javascript for creating an array. An if statement is an idiomatic way to do it conditionally. It's also easier to debug. The map and filter methods are nice too, but they're for one-liners.
I got as far as here: > If you need to introduce a new pattern, consider refactoring the entire codebase to use this new pattern, rather than creating one-off inconsistencies. Putting aside the mis-application of "pattern" (which _should_ be used with respect to a specific design problem, per the Gang of Four), this suggestion to "refactor the entire codebase" is impractical and calcifying. Consistency increases legi…
That OO refactor isn’t actual OO. The tell tale sign is that it is named by what it does rather than what it is (verb vs noun) and the -or ending in the name [0]. It’s just a function masquerading as a class. The better refactor to introduce OO concepts would have been to introduce an isAdult function on the user class and maybe a formatted function. This + the functional refactor probably would have made for the bes…
Being adult is not a property of the user but of the jurisdiction that the user is in. In some places or some purposes it is 18 but it could be, e.g., 21 for other purposes.
If you software is not going to just run on the USA it is not a good idea to implement isAdult in the user but in a separated entity that contains data about purpose and location.
Earlier quoted context omitted.
I think it’s widely accepted that refactors should not change behavior. That’s my experience, at least.
Huh, I guess that's true, even on wikipedia. I will have to stop using the word then. Though I'm pretty sure most people use it in day-to-day with much more abandon.
x^2 + x z + y x + y z
then you notice that you can express the same polynomial as:
(x + y)*(x + z)
It's still the same polynomial, but you "separated concerns", turning it into a product of two simpler factors.
Similar ideas apply to sets of tuples. Perhaps you were given
{(1, 1), (1, 4), (2, 1), (2, 4), (3, 1), (3, 4)}
and you notice that this can be expressed more simply as the Cartesian product:
{1, 2, 3} x {1, 4}
Again, a literal factoring. You can imagine how variations of this idea would apply to database tables and data structures.
That's where I think the word "refactor" comes from.
Earlier quoted context omitted.
Huh, I guess that's true, even on wikipedia. I will have to stop using the word then. Though I'm pretty sure most people use it in day-to-day with much more abandon.
The metaphor, I think, is that your code is a mathematical function, and, to be even more specific and "toy example" about it, let's say it's a polynomial. If the old code was x^2 + x z + y x + y z then you notice that you can express the same polynomial as: (x + y)*(x + z) It's still the same polynomial, but you "separated concerns", turning it into a product of two simpler factors. Similar ideas apply to sets of tu…
Earlier quoted context omitted.
The metaphor, I think, is that your code is a mathematical function, and, to be even more specific and "toy example" about it, let's say it's a polynomial. If the old code was x^2 + x z + y x + y z then you notice that you can express the same polynomial as: (x + y)*(x + z) It's still the same polynomial, but you "separated concerns", turning it into a product of two simpler factors. Similar ideas apply to sets of tu…
My man, thanks for the explanation but I understand the concept I just didn't agree on definition.
That OO refactor isn’t actual OO. The tell tale sign is that it is named by what it does rather than what it is (verb vs noun) and the -or ending in the name [0]. It’s just a function masquerading as a class. The better refactor to introduce OO concepts would have been to introduce an isAdult function on the user class and maybe a formatted function. This + the functional refactor probably would have made for the bes…
> u.isAdult() Being adult is not a property of the user but of the jurisdiction that the user is in. In some places or some purposes it is 18 but it could be, e.g., 21 for other purposes. If you software is not going to just run on the USA it is not a good idea to implement isAdult in the user but in a separated entity that contains data about purpose and location.
boolean isAdult() {
return this.age >= this.location.ageOfAdulthood();
// or this.location.isAdult(this.age); pick your poison!
}