I certainly appreciate the feedback. But I'm not sure exactly what you're inferring in your response. so my reply might, admittedly, miss the mark. But here goes:
Even if the internal structure is publicly accessible the convention is to only interact with a type instance via publicly available functions.
I think my entire objective on this is to rail against "convention". Convention has its place. And I'm not claiming we shouldn't care at all about convention. But the whole point of this article is to point out the silliness of convention-for-the-sake-of-convention.
I'm not against the idea of having getters and setters. And I understand the theory of why getters/setters are encouraged. But if you're creating getters/setters just to tick off some checklist in your computer science class, you're missing the whole point.
I fully understand that, sometimes, you create a whole batch of getters/setters because you're essentially wireframing new code. And you know that, at some point in the near future, there will be additional logic inside those getters/setters. So you create them as a kind of scaffolding and, fairly soon, you end up adding the logic to them.
But if you're "scaffolding", for some kind of assumed future expansion of the code, but you don't know that you'll be building out that portion of the code, then you're just creating unnecessary complexity for the purpose of satisfying some theoretical programming professor.
One way to identify a "code smell" is to find those places where the coder has written a whole bunch of boilerplate code to account for some unforeseen eventuality that may not ever occur. When someone insists on never creating a public variable and always couching every class member in getters/setters (even if those getters/setters don't do anything), then they are committing this same sin.
I think you've read several of my articles, so you might've started to understand this theme from me now: I don't much care whether you love getters/setters - or whether you hate them. What I care about is dogma. I care about the OOP acolytes who get all up in their ivory tower to preach the gospel of getters/setters - even when those getters/setters are a complete waste of time.
And I understand the theory of why getters/setters are encouraged.
From my perspective that practice has been a code smell for at least the past 17 years - unless you're dealing with a DTO.
What is encouraged is to hide access to instance variables behind methods so that implementation details like validation, computation and storage can be hidden away and remain subject to change without impacting the object's public API.
Mindless getters and setters on the other hand hint at lack of design, revealing too much about the object's internal structure which causes its collaborators to be too tightly coupled to it.
Don't ask for the information you need to do the work; ask the object that has the information to do the work for you.
I certainly appreciate the feedback. But I'm not sure exactly what you're inferring in your response. so my reply might, admittedly, miss the mark. But here goes:
I think my entire objective on this is to rail against "convention". Convention has its place. And I'm not claiming we shouldn't care at all about convention. But the whole point of this article is to point out the silliness of convention-for-the-sake-of-convention.
I'm not against the idea of having getters and setters. And I understand the theory of why getters/setters are encouraged. But if you're creating getters/setters just to tick off some checklist in your computer science class, you're missing the whole point.
I fully understand that, sometimes, you create a whole batch of getters/setters because you're essentially wireframing new code. And you know that, at some point in the near future, there will be additional logic inside those getters/setters. So you create them as a kind of scaffolding and, fairly soon, you end up adding the logic to them.
But if you're "scaffolding", for some kind of assumed future expansion of the code, but you don't know that you'll be building out that portion of the code, then you're just creating unnecessary complexity for the purpose of satisfying some theoretical programming professor.
One way to identify a "code smell" is to find those places where the coder has written a whole bunch of boilerplate code to account for some unforeseen eventuality that may not ever occur. When someone insists on never creating a public variable and always couching every class member in getters/setters (even if those getters/setters don't do anything), then they are committing this same sin.
I think you've read several of my articles, so you might've started to understand this theme from me now: I don't much care whether you love getters/setters - or whether you hate them. What I care about is dogma. I care about the OOP acolytes who get all up in their ivory tower to preach the gospel of getters/setters - even when those getters/setters are a complete waste of time.
From my perspective that practice has been a code smell for at least the past 17 years - unless you're dealing with a DTO.
What is encouraged is to hide access to instance variables behind methods so that implementation details like validation, computation and storage can be hidden away and remain subject to change without impacting the object's public API.
Mindless getters and setters on the other hand hint at lack of design, revealing too much about the object's internal structure which causes its collaborators to be too tightly coupled to it.
That was exactly the point of this whole article.