[DiscordArchive] And how does directly manipulating member variables solve this problem?
[DiscordArchive] And how does directly manipulating member variables solve this problem?
Original source
So if you follow the reasoning that you shouldn't manipulate the interval, you shouldn't ever have to have a need to call this setter. Calling this setter should be an edge case, at best
rektbyfaith
06-13-2024, 10:45 PM #11Archived author: chipzz • Posted: 2024-06-13T22:45:05.909000+00:00
Original source
So if you follow the reasoning that you shouldn't manipulate the interval, you shouldn't ever have to have a need to call this setter. Calling this setter should be an edge case, at best
Original source
But again, that depends on the specific variable
rektbyfaith
06-13-2024, 10:45 PM #12Archived author: Foe • Posted: 2024-06-13T22:45:32.006000+00:00
Original source
But again, that depends on the specific variable
Original source
You can't broadly apply that logic to every single variable
rektbyfaith
06-13-2024, 10:45 PM #13Archived author: Foe • Posted: 2024-06-13T22:45:46.695000+00:00
Original source
You can't broadly apply that logic to every single variable
Original source
There's a reason all modern languages reduce boilerplate needed for Getters and setters, and all adopt the pattern. Nobody reasonable is going to say adding a getter or setter is worse unless you are exposing class internals that shouldn't be exposed, or you are working on extremely low level logic where every cpu instruction matters (and even then, it can be optimised away at compile time potentially)
rektbyfaith
06-13-2024, 10:46 PM #14Archived author: stoneharry • Posted: 2024-06-13T22:46:47.708000+00:00
Original source
There's a reason all modern languages reduce boilerplate needed for Getters and setters, and all adopt the pattern. Nobody reasonable is going to say adding a getter or setter is worse unless you are exposing class internals that shouldn't be exposed, or you are working on extremely low level logic where every cpu instruction matters (and even then, it can be optimised away at compile time potentially)
Original source
Fifth: this is supposed to replace existing code. The very first thing you should do in this case is analyse the use-cases of the existing code. I see no evidence that this has been done. If you do analyse the existing use cases up-front, you're extremely likely you'll end up with a design you don't /need/ to change because you got it right the first time, by using your head before writing code. For complex code this can be hard, but for something as trivial as a timer like this this should be entirely possible
rektbyfaith
06-13-2024, 10:54 PM #15Archived author: chipzz • Posted: 2024-06-13T22:54:29.659000+00:00
Original source
Fifth: this is supposed to replace existing code. The very first thing you should do in this case is analyse the use-cases of the existing code. I see no evidence that this has been done. If you do analyse the existing use cases up-front, you're extremely likely you'll end up with a design you don't /need/ to change because you got it right the first time, by using your head before writing code. For complex code this can be hard, but for something as trivial as a timer like this this should be entirely possible
Original source
I'm not sure what that has to do with your point that only fresh grads write setters and Getters
rektbyfaith
06-13-2024, 10:55 PM #16Archived author: stoneharry • Posted: 2024-06-13T22:55:10.862000+00:00
Original source
I'm not sure what that has to do with your point that only fresh grads write setters and Getters
Original source
And when you do that, first of all the chance of in the future code needing a different API are extremely small. And if you do encounter such a case in the future, I would argue that the problem is less likely to be with the existing design and more likely with the new code
rektbyfaith
06-13-2024, 10:56 PM #17Archived author: chipzz • Posted: 2024-06-13T22:56:03.056000+00:00
Original source
And when you do that, first of all the chance of in the future code needing a different API are extremely small. And if you do encounter such a case in the future, I would argue that the problem is less likely to be with the existing design and more likely with the new code
Original source
The problem is that "Everything must have a getter and setter" is the kind of dogma that is hammered into you in college, and which is mostly correct. "Mostly" being the operative word here. Dogma is exactly that, dogma. You need to take dogma with the necessary grain of salt. Only fresh graduates parrot dogma because they don't know any better.
rektbyfaith
06-13-2024, 10:59 PM #18Archived author: chipzz • Posted: 2024-06-13T22:59:26.891000+00:00
Original source
The problem is that "Everything must have a getter and setter" is the kind of dogma that is hammered into you in college, and which is mostly correct. "Mostly" being the operative word here. Dogma is exactly that, dogma. You need to take dogma with the necessary grain of salt. Only fresh graduates parrot dogma because they don't know any better.
Original source
Am I saying you shouldn't apply the principle of encapsulation, or that encapsulation is bad? No, it definitely has a lot value and prevents bad code.
rektbyfaith
06-13-2024, 11:00 PM #19Archived author: chipzz • Posted: 2024-06-13T23:00:33.075000+00:00
Original source
Am I saying you shouldn't apply the principle of encapsulation, or that encapsulation is bad? No, it definitely has a lot value and prevents bad code.
Original source
But there are also a lot of places where encapsulation is nothing more or less than overkill. You're not only writing pointless code, you also have to waste your time writing documentation for said code.
rektbyfaith
06-13-2024, 11:03 PM #20Archived author: chipzz • Posted: 2024-06-13T23:03:23.212000+00:00
Original source
But there are also a lot of places where encapsulation is nothing more or less than overkill. You're not only writing pointless code, you also have to waste your time writing documentation for said code.
1 Guest(s)
1 Guest(s)