Timeline for Is encapsulation still one of the elephants OOP stands on?
Current License: CC BY-SA 3.0
27 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 16, 2020 at 10:01 | history | edited | CommunityBot | Commonmark migration | |
| Oct 6, 2017 at 15:25 | comment | added | candied_orange | This almost feels like a semantics debate but it's an important one. Wrapping public assignments and returns in methods that ensure you can validate and set breakpoints is indeed powerful. It's just not encapsulation. Encapsulation offers the reassurance that the only things that care if X exists are in here with X and not running around wherever they please. | |
| Oct 6, 2017 at 11:33 | comment | added | Caleth | @VinceEmigh You can have validation, but you can't stop anywhere else writing a "valid" value at a time you are not expecting. That's why it isn't encapsulated. You can't stop somewhere else reading a transient value that is inconsistent with something else | |
| Oct 6, 2017 at 11:27 | comment | added | Gangnus | @Caleth yes, they are not hidden. Really, I raised the question due to the base of the problem - existing beans realization that is moving Java practice in bad direction. But you have pointed just to the very practical result of that politics. Just now I escaped from one project, where using the Lombok, people set and get values across several layers. Awful practice, and the quality decreases still more and more! It is a pity that so small comment cannot be turned into an answer, I would gladly upvote it, too. | |
| Oct 5, 2017 at 18:40 | comment | added | chrylis -cautiouslyoptimistic- | @Caleth Having getters and setters does not remove encapsulation--even on an @Data class the author is free to add custom setter methods with validation, or at some future point remove the backing field and make a property synthetic. | |
| Oct 5, 2017 at 16:52 | comment | added | Warbo | @VinceEmigh By "API-breakage implications" I meant constructors are part of the API, so changing them means changing the API (breaking or not). In this example, we can't (accurately) calculate a DoB if only given an age, so even though the field declaration can be switched without altering the API, there needs to be some way of getting a LocalTime value into that field. This could be a setter, or a constructor argument (which, BTW, is more "immutable object" than "dependency injection"), but in any case would require changing the public API (breaking or not). | |
| Oct 5, 2017 at 16:03 | history | edited | Dioxin | CC BY-SA 3.0 | added 183 characters in body |
| Oct 5, 2017 at 15:51 | comment | added | Dioxin | @Caleth You could encapsulate a field, you could encapsulate a property, you could encapsulate a type, you could encapsulate a module. All of which have their own benefits and use-cases. How is this not encapsulation? How does it not matter? Yes, you could encapsulate a property behind behavioral methods. But whose to say the type shouldn't be encapsulated? What about the module that the type is contained in? How would you define "proper encapsulation" without realizing the different tiers of encapsulating? | |
| Oct 5, 2017 at 15:47 | comment | added | Caleth | No, I'm saying partitioning off "levels of encapsulation" is unimportant. OO code looks different than just "structs with methods" | |
| Oct 5, 2017 at 15:42 | comment | added | Dioxin | @Caleth How is it not important? That doesn't make any sense. You're saying encapsulation doesn't apply because you feel it's not important in this situation, even though it applies by definition and has it's use cases? | |
| Oct 5, 2017 at 15:40 | comment | added | Caleth | And what I'm saying is that isn't important | |
| Oct 5, 2017 at 15:38 | comment | added | Dioxin | @Caleth And that's exactly what I'm trying to say: there exists different tiers of encapsulation. The fields are still hidden, there is benefit to it, regardless of whether some devs are against. Yeah, it shouldn't be applied religiously, but nevertheless, encapsulation by definition applies to this form of hiding (fields), and still serves purpose for certain requirements. I'd say the problem is assuming classes are used only for instantiating objects, which although classes were designed with that in mind, many languages give us no choice but to use them for other things, such as utilities | |
| Oct 5, 2017 at 15:36 | comment | added | Dioxin | @Warbo How would that imply API-breakage? Injecting an age via User(int) would still be viable as long as it doesn't violate any contracts, albeit it would be better to deprecate and expose a User(LocalDate). But you don't need to inject a value. DI is it's own topic, similar to how DbC is it's own topic. But there exists other styles of development that make implementation of certain requirements easier (hence JavaBeans). Yeah, they're abused, but definitely have purpose - they weren't conceived for no reason. | |
| Oct 5, 2017 at 15:33 | comment | added | Caleth | @VinceEmigh I misspoke, what I mean is the state that the class has, as (currently) represented in the fields, is not hidden | |
| Oct 5, 2017 at 15:24 | comment | added | Warbo | @Caleth Nothing can call setAge(xyz) if there is no setAge method, and this User example has no setAge method. There needs to be some way to initialise the field though, e.g. a constructor like public User(int age) { /*set age or DOB here*/ } and this would have API-breakage implications. | |
| Oct 5, 2017 at 15:21 | history | edited | Dioxin | CC BY-SA 3.0 | added 101 characters in body |
| Oct 5, 2017 at 15:16 | comment | added | Dioxin | @Caleth The fields are hidden. You're acting as if setters can't have pre and post conditions, which is a very common use case for using setters. You're acting as if a field == property, which even in languages like C#, just isn't true, as both tend to be supported (as in C#). The field can be moved to another class, it can be swapped for a more complex representation... | |
| Oct 5, 2017 at 15:11 | comment | added | Caleth | No, the fields are not hidden. Because anything can come along and setAge(xyz) | |
| Oct 5, 2017 at 14:59 | comment | added | Dioxin | @Caleth Its an annotation to ease development. You are enforcing rules that don't exist. There are no rules stating you couldn't implement a new implementation for a getter that still abides the contract later down the road. It doesn't "unencapsulate" fields - the fields are still hidden... Yes, you can have getters that do nothing more than expose a field if needed. It's no bound to that notion though. | |
| Oct 5, 2017 at 14:56 | comment | added | Caleth | This is unrelated to slapping the @Data annotation on a type, which by design unencapsulates all the fields | |
| Oct 5, 2017 at 14:23 | history | edited | Dioxin | CC BY-SA 3.0 | [Edit removed during grace period]; added 61 characters in body |
| Oct 5, 2017 at 14:16 | history | edited | Dioxin | CC BY-SA 3.0 | added 58 characters in body |
| Oct 5, 2017 at 14:06 | history | edited | Dioxin | CC BY-SA 3.0 | added 803 characters in body |
| Oct 5, 2017 at 12:54 | history | edited | Dioxin | CC BY-SA 3.0 | added 137 characters in body |
| Oct 5, 2017 at 12:53 | history | undeleted | Dioxin | ||
| Oct 5, 2017 at 12:48 | history | deleted | Dioxin | via Vote | |
| Oct 5, 2017 at 12:43 | history | answered | Dioxin | CC BY-SA 3.0 |