Timeline for How far can you push Object Oriented Programming?
Current License: CC BY-SA 4.0
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 25, 2024 at 22:21 | comment | added | chubbsondubs | @RobertBräutigam String.length is a great example! Library or not should hold true to your rule. It's an inconvenient fact so you want to dismiss it as special. But the reason it's a great example is it's an API we all know and understand, it shows what you are saying isn't a fact in general. If what you are advocating doesn't even work for a common library then it probably isn't true. And it doesn't stop there. How about collections? Oh well darn it doesn't work there either. After a few of these common examples it all of a sudden looks like what you are saying might not be a fact. | |
| May 31, 2024 at 13:24 | history | edited | chubbsondubs | CC BY-SA 4.0 |
Add more clarity to the position that getters still provide encapsulation
|
| May 31, 2024 at 3:43 | history | edited | chubbsondubs | CC BY-SA 4.0 |
Clarified some topics with more concrete examples.
|
| May 31, 2024 at 3:38 | history | edited | chubbsondubs | CC BY-SA 4.0 |
Clarified some topics with more concrete examples.
|
| May 16, 2024 at 0:05 | comment | added | Basilevs | Different structure and normalization of grapheme clusters make the length ill-defined. On a second thought, charArray is also bad abstraction. toGraphemeArray or toGraphemeClusterArray might be a better design. | |
| May 15, 2024 at 23:58 | comment | added | Basilevs | Exposing a length is definitely an abstraction leak. One does not need length to do base string operations. It is useful for computing positions within, but indexed access to a collection is more suitable for an Array than a String. Arguably instead of getLegth(), a method toCharArray() should be exposed. Especially for mutable String. | |
| May 15, 2024 at 12:03 | comment | added | Bergi |
"String.getBytes() must violate encapsulation right?" - not necessarily, as you demonstrated; as long as the byte array is read-only. However it violates TDA, a String.writeToBuffer(buf) or writeToByteStream(str) might be a better, more flexible and more performant API. Still a getter, or even a .getBytesIterator(), is sometimes more convenient than inversion of control; a rich API ideally has both.
|
|
| May 14, 2024 at 16:28 | comment | added | Robert Bräutigam |
@GregBurghardt String.length is a bad example, it sits at the edge of a library. Still, "losing control" means that as soon as you publish that, you can't modify your string to be an unlimited string. If the length is int, now you can't have a longer string than that. If you calculated the length based on bytes before, and people started using it to store it, you'll have a huge problem when unicode comes along. As soon as its published, it's out there. You can't take it back, you'll have to support it. This is what I mean by "lost control".
|
|
| May 14, 2024 at 16:23 | comment | added | Robert Bräutigam |
@JenserCube The point of step two was to move the checks of the source account into the account. The receiving account has similar methods to receive money, that will check itself, so no need for the source to know about the target account. Also remember, this was just step two, Money is still a data structure at this point. I just wanted to show this (somewhat) self-contained piece about the account.
|
|
| May 14, 2024 at 14:11 | comment | added | JenserCube | @RobertBräutigam In the example you link to related to Accounts, I cannot see how it solves the underlying issue. How will you actually check if the money can be moved to the external account that is referenced? Or rather - how does the account know which currency the receiving account is in? | |
| May 14, 2024 at 12:40 | comment | added | ConnieMnemonic | Thanks @RobertBräutigam I'll go take a read! Appreciate your time :) | |
| May 14, 2024 at 12:16 | comment | added | Greg Burghardt | @RobertBräutigam: if you expose the "length" of a string, but do not allow the length to be modified, how is that losing control of the data? | |
| May 14, 2024 at 11:41 | comment | added | Robert Bräutigam | @ConnieMnemonic This is an article about Accounts and Money, which is a simplified version of real code I did. Another simplified but real example about Devices. | |
| May 14, 2024 at 10:52 | comment | added | ConnieMnemonic | @RobertBräutigam Could you explain more? What's meant here by "include behaviour instead of giving it out"? Could you give an example? This way of thinking is new to me but I'm intrigued. | |
| May 14, 2024 at 8:01 | comment | added | Peregrine | @RobertBräutigam you were the one who wrote "Encapsulation is "encapsulating", erecting a capsule, a barrier around, i.e. not making available, internal state". Your response then 100% contradicted that. If you have the appropriate data available, no harm can come from providing salutation / first name / last name / full name (in a read only manner) and let the consumer pick the most appropriate one for their usage. | |
| May 14, 2024 at 7:53 | comment | added | Robert Bräutigam | @Peregrine It's not 100% opaque. It is a wall of behavior, that is derived from requirements, i.e. the Ubiquitous Language. The "damage" of exposing a name, is that you can not reason about it anymore. What is it for? Do I need one string, do I need firstname and lastname, do I need a salutation? You have no clue. If you include behavior instead of giving it out, you'll know the context, therefore can reason and change in isolation. This is the best I can do in a comment., HTH. | |
| May 14, 2024 at 7:17 | comment | added | Peregrine | @RobertBräutigam In what universe does encapsulation equate to creating a 100% opaque wall around an object. If I have a person instance, what's so damaging about me being able to know their name (via some property getter or method)? | |
| May 14, 2024 at 7:09 | comment | added | Robert Bräutigam | "Exposing those properties doesn't violate the principles of encapsulation in oop.". It does though. This is not a matter of opinion, but just fact. Encapsulation is "encapsulating", erecting a capsule, a barrier around, i.e. not making available, internal state, i.e. instance variables. It doesn't matter whether it is impossible to avoid, it doesn't matter if this is good or bad. The only thing that matters pragmatically is: do you lose control of the data or not. If you expose it, you lose control, if you don't, you don't. | |
| May 13, 2024 at 2:50 | history | answered | chubbsondubs | CC BY-SA 4.0 |