Timeline for Is encapsulation still one of the elephants OOP stands on?
Current License: CC BY-SA 3.0
74 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 9, 2018 at 15:10 | review | Close votes | |||
| Dec 16, 2018 at 3:05 | |||||
| Oct 26, 2017 at 13:21 | history | rollback | Gangnus | Rollback to Revision 2 | |
| Oct 13, 2017 at 10:52 | comment | added | Warbo | @VinceEmigh Whilst I get the 'value object' idea (although I prefer algebraic datatypes for that), for the particular example of vectors there are still reasons to encapsulate the components :) | |
| Oct 11, 2017 at 17:35 | history | edited | Gangnus | CC BY-SA 3.0 | deleted 647 characters in body |
| Oct 11, 2017 at 16:53 | comment | added | user251748 | What's large and grey, and doesn't matter? An irrelevant. | |
| Oct 11, 2017 at 14:26 | history | edited | Gangnus | CC BY-SA 3.0 | added 1076 characters in body |
| Oct 10, 2017 at 7:09 | answer | added | Joeri Sebrechts | timeline score: 4 | |
| Oct 10, 2017 at 5:41 | history | tweeted | twitter.com/StackSoftEng/status/917626026091565056 | ||
| Oct 9, 2017 at 7:57 | comment | added | sampathsris | Related discussion on use of public/private fields in Java: stackoverflow.com/q/36701/1461424 | |
| Oct 6, 2017 at 16:06 | comment | added | user251748 | And then there is the old "Elephant in the room" idiom (it sits next to the 800 pound Gorilla). And the Pink Elephant, and the White Elephant... How many metaphors can dance on the head of a Pinterest? | |
| Oct 6, 2017 at 16:04 | comment | added | user251748 | @CarlWalsh Actually, the reference is to something else: the Hindu idea that the world sits on the back of an elephant, which stands on another elephant, which stands on another elephant... Another version has the world on top of a turtle which is supported by several elephants at its feet. My reference was to something else entirely. Metaphors are like Standards - you can never have too many of them. Until you reach the metaphor event horizon and collapse into a black hole (itself a metaphor) (OMG! There is no escape!!!) | |
| Oct 6, 2017 at 15:35 | comment | added | Carl Walsh | Was I the only person completely bewildered by the "elephants" reference? @nocomprende's comment is the only hint I see: en.wikipedia.org/wiki/Blind_men_and_an_elephant | |
| Oct 6, 2017 at 13:03 | answer | added | JacquesB | timeline score: 6 | |
| Oct 6, 2017 at 9:04 | comment | added | Gangnus | @Flynn1179 If you follow the rule that using getters/setters is bad, and you use fields mostly inside the class, then you practically don't need to catch the getting/setting act, for you have far less errors connected to it. But I agree it is a nice method, we all use it, and will use it for badly written products. | |
| Oct 6, 2017 at 8:59 | comment | added | Flynn1179 | Aside from all the other issues discussed, for me one of the biggest benefits of encapsulation is being able to set a breakpoint in the getter/setter to see the call stack when the property is set. Not the only benefit obviously, but it's very useful when debugging. | |
| Oct 6, 2017 at 3:15 | answer | added | Joshua | timeline score: 0 | |
| Oct 6, 2017 at 3:07 | comment | added | 9000 | Encapsulation is actually one of the few truly valuable parts of OOP. Most of the rest isn't; getters and setters definitely aren't. | |
| Oct 6, 2017 at 3:01 | answer | added | Davislor | timeline score: 1 | |
| Oct 6, 2017 at 1:11 | answer | added | meriton | timeline score: 12 | |
| Oct 5, 2017 at 22:54 | answer | added | radarbob | timeline score: -1 | |
| Oct 5, 2017 at 21:57 | answer | added | candied_orange | timeline score: 6 | |
| Oct 5, 2017 at 21:49 | comment | added | jpmc26 | You should consider this: Object Oriented Programming is Bad. Don't be fooled by the slightly baity intro; it's a pretty well thought out, useful discussion. Even if you disagree that OO is bad, the problems it discusses are definitely things you'll want to keep in mind. | |
| Oct 5, 2017 at 21:05 | comment | added | user3685427 | Don't think of getters and setters as hiding fields. Instead, they are tools that you use to work with those fields. Suppose your computer tower is a field (this is a huge oversimplification, but roll with me); then the getter is the computer screen and the setter is the keyboard. The getter and setter are components that help you interact with the computer. In complex projects, some simple types actually should be objects - such as distances in engineering programs (metric vs imperial). You can change the private field to an object, without changing all the calls to get() and set(). | |
| Oct 5, 2017 at 20:21 | comment | added | user251748 | @alephzero "He who dies with the most code, wins." | |
| S Oct 5, 2017 at 20:04 | answer | added | BananyaDev | timeline score: 5 | |
| S Oct 5, 2017 at 20:04 | history | protected | CommunityBot | ||
| Oct 5, 2017 at 19:54 | comment | added | alephzero | You are forgetting that in working environments where "productivity" is measured by counting lines of code, getters and setters have a great value to the programmers who code them - compared with just using public variables, they make the code longer, with a low risk of creating more bugs! | |
| Oct 5, 2017 at 16:16 | comment | added | Caleth | @VinceEmigh I'm not saying get rid of anything. I am saying label things correctly. Encapsulation isn't a goal. Code is not sinful if it is unencapsulated. It is just not OO | |
| Oct 5, 2017 at 16:13 | comment | added | Dioxin | @Caleth Have you been reading my comments? So you're saying there are no requirements that would require deconstructing a vector for it's absolute position? Yeah, that example of vector works, assuming the requirements call/allow for that. Let me emphasize once again: Not all software share the same requirements. You're suggesting we rid of deconstructing, albeit many modern languages implement it? | |
| Oct 5, 2017 at 16:03 | comment | added | Caleth | @VinceEmigh Did you read the example? The point is you don't need to access the state outside of the class. Yes you could extend it with an add and a multiply, where you need those operations. But notice how there isn't any outside usage of x or y | |
| Oct 5, 2017 at 15:59 | comment | added | Dioxin | @Caleth Thats not the only relevant operation... What about add or subtract? Multiplying by a scalar? One may say those operations should be segregated out of Vector. But wouldn't equal also be segregated if that were the case? I'm not sure where you're getting all these undocumented restrictions, but they just aren't true. What if you wanted to deconstruct the vector? How would you do so? Or did you not account for that possible requirement | |
| Oct 5, 2017 at 15:51 | comment | added | Caleth | @VinceEmigh Except where the only relevant operation for the collaborators of Vector is Vector::equal, so that's the only public method. Example | |
| Oct 5, 2017 at 15:46 | comment | added | Dioxin | @Warbo @Data wasn't designed to be blindly slapped onto every type you come by. But it definitely has it's purposes, for example, a 2D Vector type that does nothing more but store [x, y] coordinates. | |
| Oct 5, 2017 at 15:38 | comment | added | Warbo | Getters/setters for everything is such a pervasive anti-pattern that I not only avoid the practice, but I also treat names like getFoo and setFoo as code smells: much better to stop and think, from an external/consuming perspective, what the method is for; rather than an internal/implementating perspective of how it works. In other words, even if a getAge method is justified, would it make more sense to call it e.g. ageInYears(), or maybe just age() (which returns a Duration type constructed from the private int), etc. | |
| Oct 5, 2017 at 15:05 | comment | added | Dioxin | @Caleth Refer to my "encapsulation and design by contract are not the same" comment. Encapsulation is not all about the contract, and has EVERYTHING to do with changing the shape of the data, or in other words, the internal representation.. | |
| Oct 5, 2017 at 14:55 | comment | added | Caleth | @VinceEmigh encapsulation is all about the contract that an object has, and very little to do with the "we want to change the shape of the data here" | |
| Oct 5, 2017 at 14:47 | answer | added | Graham | timeline score: -1 | |
| Oct 5, 2017 at 14:39 | comment | added | skapral | @MichaelBorgwardt They (getters/setters) might be treated as public contract of some object, but it'd be very crappy public contract. | |
| Oct 5, 2017 at 14:31 | comment | added | Dioxin | @Caleth "data classes have no encapsulation" - So they don't generate getters? The fields aren't hidden? Or are you furthering the argument that getters provide no form of encapsulation, which just isn't true? It doesn't take much to realize there is benefit. | |
| Oct 5, 2017 at 14:29 | answer | added | JimmyJames | timeline score: 6 | |
| Oct 5, 2017 at 14:28 | history | edited | Matthieu M. | CC BY-SA 3.0 | Reworded the title as a question, and a few nits and bits. |
| Oct 5, 2017 at 14:18 | comment | added | user251748 | Too bad the Wise Men still can't properly explain what the OOP Elephant is. They all describe it differently. We are all in the dark about it, apparently. | |
| Oct 5, 2017 at 14:17 | comment | added | Dioxin | @Gangnus Check out my answer for a concrete example. I'm surprised developers actually believe getters have no benefit over public fields. Getters are not the same as exposing fields. | |
| Oct 5, 2017 at 14:15 | comment | added | Michael Borgwardt | @Caleth: JavaBeans as originally envisioned are very much an OO concept. They were intended to have complex behaviour with a small number of carefully chosen getters and setters exposed as their public API. | |
| Oct 5, 2017 at 14:13 | answer | added | HorriblePerson | timeline score: -1 | |
| Oct 5, 2017 at 14:09 | comment | added | Michael Borgwardt | @skapral: the problem is not getters and setters, you can have perfectly good OO design if you use them like they are a public API, not like they are a mandatory add-on for every field (which is as stupid as it is common). | |
| Oct 5, 2017 at 14:05 | comment | added | VGR | See stackoverflow.com/questions/1568091/why-use-getters-and-setters. | |
| Oct 5, 2017 at 14:03 | answer | added | Michael Borgwardt | timeline score: 75 | |
| Oct 5, 2017 at 13:48 | answer | added | Matthieu M. | timeline score: 18 | |
| Oct 5, 2017 at 13:25 | comment | added | jrh | I've put a lot of thought into this over the years; I think this is a case where the intent of OOP differed from the implementation. After studying SmallTalk it's clear what OOP's encapsulation was intended to be (i.e., each class being like an independent computer, with methods as the shared protocol), though for reasons so far unknown to me, it has definitely caught on in popularity to make these getter/setter objects that offer no conceptual encapsulation (they hide nothing, manage nothing, and have no responsibility other than data), and yet they still use properties. | |
| Oct 5, 2017 at 13:14 | comment | added | gnat | possible duplicate of Is it bad practice to use public fields? | |
| Oct 5, 2017 at 13:06 | comment | added | Caleth | @VinceEmigh they can't have (non-trivial) invariants safely, which means the scope of behaviours that they can have is limited | |
| Oct 5, 2017 at 13:04 | comment | added | Dioxin | @Caleth So you're suggesting beans can't have behaviors? They aren't subject for messages, for example, events? | |
| Oct 5, 2017 at 13:01 | comment | added | skapral | @Gangnus Lombok is great for doing stuff like getters/setters. IMO getters/setters are the bad thing. Even if not talking about OOP. Good software abstraction protects its invariants - by contract, consistent type system, different sort of constraints etc. Structures is weak protection. Preudo-object with getters/setters doesn't make it any better. And Lombok? Lombok is just following the trends, it isn't their blame that the trends are like that. | |
| Oct 5, 2017 at 13:00 | comment | added | Caleth | @VinceEmigh using JavaBeans is not OO, it is Procedural. That the literature calls them "Objects" is a mistake of history. | |
| Oct 5, 2017 at 12:57 | comment | added | Caleth | @VinceEmigh data classes have no encapsulation. Instances of them are values in exactly the sense that primitives are | |
| Oct 5, 2017 at 12:56 | comment | added | Dioxin | @skapral Dont be so concrete, we can all clearly see what the question is asking about. "Could somebody explain me, what is the sense of hiding all fields as private and after that to expose all of them by some" - "Could somebody explain me, what is the sense of hiding all fields as private and after that to expose all of them by some extra technology" - What's your answer? JavaBeans should be avoided and we should burn down enterprise development? | |
| Oct 5, 2017 at 12:55 | comment | added | skapral | @VinceEmigh the initial question was asked in context of OOP, so I'm talking about OOP. What's wrong. | |
| Oct 5, 2017 at 12:54 | comment | added | Gangnus | @skapral Yes, mass use of getters/setters is a bad thing. We should rather use an object as a whole. But then the whole Lombok is a bad thing? | |
| Oct 5, 2017 at 12:53 | review | Close votes | |||
| Oct 10, 2017 at 3:02 | |||||
| Oct 5, 2017 at 12:51 | comment | added | Dioxin | @skapral You act as if the term encapsulation derives from OOP, and can only be used within OOP.. But since you're wondering: "Encapsulation is used to hide the values or state of a structured data object inside a class". Yeah, it's one of the foundations for OOP, but you act as if it can't be applied outside of OOP, as if non-OO languages can't support encapsulation. | |
| Oct 5, 2017 at 12:43 | answer | added | Dioxin | timeline score: 13 | |
| Oct 5, 2017 at 12:39 | comment | added | skapral | @VinceEmigh and what do these Kotlin data classes encapsulate then? For me they are just structures, a naked data, not objects. So - IMO no sense in applying OOP terminology to them. | |
| Oct 5, 2017 at 12:35 | history | migrated | from stackoverflow.com (revisions) | ||
| Oct 5, 2017 at 12:30 | comment | added | Dioxin | @skapral You must not be familiar with Kotlin's data classes. They are not contradictory. Encapsulation is about hiding information - you are trying to limit it to "hiding internals of a behavioral object", which isn't it's only use (hence Kotlin's data classes and Lombok's @Data annotation). | |
| Oct 5, 2017 at 12:27 | comment | added | skapral | @VinceEmigh Probably, but it actually changes nothing. Incapsulation is about hiding the internals, DTO, getters/setters are about exposing them. These two things are just contradictory. | |
| Oct 5, 2017 at 12:23 | comment | added | Dioxin | @skapral Designing by contract and encapsulation are not the same/interchangeable. You can hide information without designing by contract. DbC encourages stronger encapsulation, but that's not to say it's the only form of encapsulating, nor the only way encapsulation is beneficial. | |
| Oct 5, 2017 at 12:10 | comment | added | skapral | Encapsulation is hiding implementation internals of the object behind its public contract (usually, an interface). Getters and setters does exactly the opposite thing - they expose the object's internals, so the problem is in getters/setters, not encapsulation. | |
| Oct 5, 2017 at 12:09 | comment | added | Sergey Kalinichenko | "What is the sense of hiding all fields as private and after that to expose all of them by some extra technology?" People tend to do it in other areas, too: But I was thinking of a plan/To dye one's whiskers green,/And always use so large a fan/That they could not be seen | |
| Oct 5, 2017 at 12:03 | answer | added | glennsl | timeline score: 2 | |
| Oct 5, 2017 at 11:58 | answer | added | daniu | timeline score: 7 | |
| Oct 5, 2017 at 11:56 | answer | added | Izbassar Tolegen | timeline score: 90 | |
| Oct 5, 2017 at 11:31 | comment | added | David | "It will create getters, setters and setting constructors for all private fields." - The way you describe this tool, it sounds like it is maintaining encapsulation. (At least in a loose, automated, somewhat anemic-model sense.) So what exactly is the problem? | |
| Oct 5, 2017 at 11:28 | history | asked | Gangnus | CC BY-SA 3.0 |