Timeline for Avoiding getters and setters: what is wrong with my design?
Current License: CC BY-SA 4.0
26 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 6, 2021 at 23:11 | comment | added | Filip Milovanović | @RobertBräutigam "I can use this "don't be dogmatic" argument, right? :)" - I'm more concerned about the self-study context, as the statement itself is lacking nuance, than I'm about scenarios where two devs are having a discussion. People often find something like "getters & setters are evil" online, but are offered very little to no additional context/guidance, so they misinterpret what the point of it all is. Just the other day, we had a question along the lines of "I heard getters and setters are bad, so can I just use public fields instead?", which misses the point completely. | |
| Feb 6, 2021 at 0:50 | answer | added | Mike Robinson | timeline score: -2 | |
| Feb 5, 2021 at 13:44 | comment | added | IMSoP | @Flater Yes, it can be read that way, but I found it more interesting to discuss the actual issue than the nuances of wording, that's why I said "splitting hairs". It feels pedantic to demand elaboration of every point when I do know why the advice exists. Again, I've written an answer based on that assumption, which I think is far more useful to everyone than this debate. | |
| Feb 5, 2021 at 13:41 | comment | added | Flater | @IMSoP: I interpret the question somewhat differently, since OP assumes (quote) that their code must be wrong. There's a difference in asking whether the article they read was correct, and asking how to fix their code based on some arbitrary advice without any elaboration as to what it precisely tried to solve. | |
| Feb 5, 2021 at 12:56 | comment | added | IMSoP | @Flater I took this question to be asking: "I've read this advice, but I didn't fully understand it; can anyone use this example to help me understand it better?". My answer is on that basis, rather than splitting hairs about who wrote what when with what words. | |
| Feb 5, 2021 at 12:52 | comment | added | IMSoP | @Flater "I've read that we should all fear the sky falling on our heads one day" is a poor analogy, because it relates to an objective fact, whereas the idea that a particular practice should be avoided is only ever going to be an opinion. It's reasonable to ask for the reasoning behind that opinion, and to decide if you agree with it, but it's not really meaningful to call it "false". It's also perfectly possible to generalise from one example to many cases, so you don't need to ask someone who has that opinion to apply it to every piece of code you write, you can learn to do that yourself. | |
| Feb 5, 2021 at 12:43 | comment | added | Flater | @RobertBräutigam: Once again, you're injecting your personal agenda here. Regardless of precisely how frequently data structures are used (which you've railed against many, many times in this community), their usage in turn warrants the existence of getters and setters. Any discussion on the frequency of data objects being used is simply not relevant. I am frankly tired of having to read your entire take on the state the field of software development, how it uses OOP, and how your career has been progressing; every time someone talks about anything remotely resembling a data structure. | |
| Feb 5, 2021 at 12:40 | comment | added | Flater | "I've read that getters and setters are evil and break OOP" I've read that we should all fear the sky falling on our heads one day, but that doesn't make it true. If you're blindly going to assume that what you read is true, then you're going to have to ask whoever wrote it how your code should be fixed. Asking others who are not aware of what you read or who wrote it and what their intention was, is simply not feasible. | |
| Feb 5, 2021 at 12:36 | comment | added | IMSoP |
@RobertBräutigam I wasn't attacking your understanding, just pointing out where your straw man argument fell down, in a hypothetical conversation between two developers. Maybe in an ideal world even a basic data type like Address would encapsulate behaviour, but creating a plain data object with getters and setters will be better than falling back on a built-in type like string or list<string>. Discussing why the rule is there might help someone build a better Address type; enforcing it blindly might lead them to not create one at all.
|
|
| Feb 5, 2021 at 12:18 | comment | added | Robert Bräutigam | @IMSoP I believe I did "develop a deep understanding of" the pros and cons, and in my last 5 years of software development I never even once encountered a scenario where I thought the best solution would be a data structure. The furthest I got in rare scenarios is to write a couple of getters in some otherwise non-data-structure objects. I've worked on banking software, trading software, web-based apps, android apps, microservices, iot-related software, communication libraries, etc. There may come a time, but hasn't happened yet. | |
| Feb 5, 2021 at 11:40 | comment | added | IMSoP | @RobertBräutigam You missed the second half of that sentence: "develop a deep understanding of ... the pros and cons". So, absolutely, if the best argument anyone has against your design is "it doesn't follow this dogma", then you can argue back; but if they say "that mixes responsibilities, which makes these scenarios harder...", they're applying the principles reasonably. The same applies to getters and setters: they might be a "code smell" to check if the design is appropriate, but you might look at the design and realise that a plain data structure is actually appropriate. | |
| Feb 5, 2021 at 10:02 | comment | added | Robert Bräutigam | @FilipMilovanović "The way to go is not to be dogmatic". Ok. So when I say object-orientation allows me to include the UI code in the business object and people lose their minds about it for the 100th time, I can use this "don't be dogmatic" argument, right? :) | |
| Feb 5, 2021 at 10:01 | answer | added | IMSoP | timeline score: 2 | |
| Feb 5, 2021 at 9:31 | comment | added | Filip Milovanović | @RobertBräutigam "data structures are the norm today" - the context was someone wanting to write good OOP code; "sometimes" wasn't meant as a statement about the frequency plain data structures in most code today. "Sometimes == almost never in applications" - I disagree, there's plenty of opportunity to use behaviorless data structures at the boundaries of applications, or you can mix paradigms if it fits the problem better. The way to go is not to be dogmatic, it's to develop a deep understanding of design, of the pros and cons of certain design choices. | |
| Feb 5, 2021 at 8:32 | comment | added | Robert Bräutigam | @FilipMilovanović "That said, some objects are really just data structures, so sometimes getters & setters are OK." This might be technically true, but is misleading, because data structures are the norm today. We are very far from data structures "sometimes" are ok, and are more in the "always" ok state. Also sometimes == almost never in applications, maybe some in libraries. Being "dogmatic" about it is much much closer to where it should be. | |
| Feb 4, 2021 at 5:20 | comment | added | Filip Milovanović |
"getters and setters are evil" sounds a bit too dogmatic; the problem they indicate is that you're grabbing data from other components on other to do something yourself (procedural programming), instead of telling those components (via method calls) what you want them to do in a higher level way (OOP). This means that the relevant code that should be extracted out of the ExampleModalWindow into some other component (Map, or a new one) is precisely the detail-manipulating code that you omitted. That said, some objects are really just data structures, so sometimes getters & setters are OK.
|
|
| Feb 4, 2021 at 1:59 | answer | added | Kevin Krumwiede | timeline score: 2 | |
| Feb 3, 2021 at 21:00 | history | tweeted | twitter.com/StackSoftEng/status/1357071384766255106 | ||
| Feb 3, 2021 at 13:58 | answer | added | gnasher729 | timeline score: -1 | |
| Feb 3, 2021 at 12:16 | history | edited | Eoin | CC BY-SA 4.0 |
added 87 characters in body
|
| Feb 3, 2021 at 12:10 | comment | added | Eoin | Hi @DocBrown, I've added a couple of images to clarify. I cannot show screenshots of the application itself as it doesn't belong to me, but the UI is very similar to Google Maps. Hopefully the images above clarify the question. | |
| Feb 3, 2021 at 12:09 | history | edited | Eoin | CC BY-SA 4.0 |
added 414 characters in body
|
| Feb 3, 2021 at 11:31 | vote | accept | Eoin | ||
| Feb 3, 2021 at 10:49 | answer | added | Robert Bräutigam | timeline score: 3 | |
| Feb 3, 2021 at 10:43 | review | First posts | |||
| Feb 3, 2021 at 11:45 | |||||
| Feb 3, 2021 at 10:37 | history | asked | Eoin | CC BY-SA 4.0 |