Immutability Q&A

[00:00:00]
>> Does anybody have any questions about these methods thus far?
>> I have a question about the object.assign.
>> Mm-hm.
>> Then, when we were doing this before, you passed a tree arguments to it, I think it was like an empty thing then we pass the client and a payload.

[00:00:24]
And then, you just passed now the client, and why did you do that? And why was it different before?
>> So what you can do, so the question is an object out of sign in one place. I passed in more than one object, or more than one parameter to call I've set aside in one case it was three parameters in another place.

[00:00:50]
In this case, I was two and the reason being is that you can pass in, I believe n, number of parameters and adjust starts to attach those from right to left. And, so in some cases, I don't want to update an entire object. I just want to update a property on an object.

[00:01:23]
In this case, I just want to essentially create a new object in just clone this one over but what I could have done is well is I could have done this in this would have been totally fine. Is that you can pass in any number of arguments where I've even had, so what could happen is you could have your full object.

[00:01:42]
And then, you could have a partial object here and this is completely viable. You could even have more than one I believe, but that's where that came from. Does that make sense? So in this case, I just wanna update the little thing. So I'm just gonna say create new object, move everything over.

[00:01:59]
But if I wanted to, if I just had a partial object, then I would basically merge it all together right to left. I got a great question. Since I use these methods so much do I ever extract them, and the answer is absolutely. In a lot of cases, I will have just like a general utility class that will take just like an entity.

[00:02:31]
And I can just pass any collection in any kind of entity in there, and it will just do this for me. And, so what you could do in theory, if you want it to do a higher level of abstraction, is that you could do something like add entity, which would take in, I'm freestyling here, a collection.

[00:03:03]
And an entity, and it would just return, Since I'm here, I might as well finish this. UpdateEntity=. I'm gonna do delete first, because it's easier for some reason, I just always want to come back and do update last. So for this one, it's collection.filter. We're just presuming that, we're comparing against ID.

[00:03:47]
I might update this, Accordingly, and so from here, collection.map. It's c.id equals entity.id. And I'm gonna break this onto a separate line just because it's getting a little hard to read. And we're going to return object data sign. Entity, Or the existing thing in the collection. I realized I probably should call this e, e.

[00:04:41]
E, e, and e. Actually, let me see if I can break this in a way that ideally, there we go. All right? Here we go. This is, How I would obstruct this, and so I could pass it in any collection, in an entity. And as long as I needed to compare against the ID, this should work.

[00:05:22]
>> When you do this abstraction, don't you think that you're reducing the readability?
>> Absolutely, because in order for this to work across multiple entities, I have to adopt a language that's common for all of the entities. And, so this is where depending on what I'm doing is that, I may or may not do this.

[00:05:52]
So I have abstracted this out, but like, create a client, is a lot more descriptive, than what, add entity is. Because now we're talking in very generic terms. And so, this is the trade-off. And, so when we talk about complexity is do we optimize or continue to optimize, or where do we stop?

[00:06:24]
And the answer is, as long as it continues to provide clarity and value to your code then continue to optimize. But if you are creating abstraction, that find and identify the interested parties, and then put your abstraction at the layer just above that, and no more. Because what I've seen is that we've got this low level problem here, and you'll extract the solution where it's three and four layers up.

[00:06:56]
And then, that that cognitive kind of leap that you have to make where if you've ever been in a project, and you're over here working on this thing over here. And then, all sudden you need something related, but then you have to jump all the way down here to some other like live or whatever that is.

[00:07:17]
You're having to jump back and forth, mentally, that is creating complexity. And, so you can over abstract your code in such a way where the mental burden of having to jump back and forth is far more than the advantage you get from, having ultra fine grain code. And, so it's really identify where that return of value is and then kind of where starts to diminish.

[00:07:42]
Then, reasonably and logically, stop right there. Ultimately is if you follow, I think I said Kent Beck, the other day but surely Kent Bloch who is this juggernaut of software engineering, he made the statement, make it work. <ake it right, make it fast, and it's not the first time I've said this, I say it quite a bit.

[00:08:07]
But ultimately, we're pragmatist and somebody, a lot of times will ask me like, should I do this? And my first question is, does it work? Because if it doesn't work, then let's just stop right there. Like, let's get it working, and then we can get it right. And then, as we start to go into production, then we can get it fast.

[00:08:32]
So that's a really, really good observation and I think you're starting to see that that tension and that balance of that of abstraction and the cost of abstraction. And start to realize that like some things we can move, other things is, it's just not worth it initially. And as well as if you adopt a principle of refactoring through promotion is that you can say, I'm going to leave this here because, at this scale, it's not a problem.

[00:09:05]
But as the application grows, then I'm going to go ahead, and then I'm going to extract it. And that's the other thing is, the beautiful thing about code is you can refactor it. And, so I think when you want to adopt a policy that you can safely refactor your code, then you can say I don't have a strong feeling about this now.

[00:09:24]
Is I have more information, then I may change it, and there's just things where it's like, I don't have an opinion about this. It feels right, or it doesn't or does it feel wrong, so I'm going to leave it.