New answers tagged encapsulation
0
Often, an object containing complex state has the high-level responsibility of delegating things to other objects, which it configures using its knowledge of its state.
A Renderer object could be responsible for creating a graphical representation of the current state of the Gripper and would thus be configured by the grabber with information derived from ...
0
If you read about SRP, and you think that you should split up a class because of SRP, and then you run into the problem that it causes you to expose private members that you don't want exposed, then you should step back and consider this:
SRP is there to make your life easier. If following SRP makes your life harder, then it is quite likely that you are ...
5
IMO, from your new approach, both Renderer and Gripper classes break the SRP:
Renderer will need knowledge of all specifics of each item to be rendered; likely to become a god class for this matter (think of it as: this class has multiple sources or reasons to change);
In addition: for every new object to be added in this simulation, you will need to "...
2
Shall Gripper hold the Renderer?
I would suggest to let Gripper provides data Gesture which is immutable and Renderer ask for Gesture.
While operation above is done by an object for screen redering.
By exposing Gesture as interface, who changes the Gripper would be aware of the exposing data shall not be changed.
Refactoring Foo would not break Renderer.
...
2
I mainly agree with Karl Bielefeldt’s answer, but believe the analogy is a bit off.
Encapsulation is not security, it’s purpose is to avoid information overload. Consider the various flavors of autocompletion/auto suggest/intellisense, on systems with reflection, suggesting private methods would make reflection easier and less error prone. Would you want ...
0
This is severely overthought. Look into how Go does it, as an example. That approach removes all the unnecessary cruft. Too much stuff has stacked up around this idea over the years, and most of these ideas can be torched.
An interface is nothing more than a promise about which methods are guaranteed to exist; so that the compiler can reject a method call ...
3
Short answer is: the two properties are unrelated and taking care of one does not ensure that the other is taken care of.
Encapsulation is a property of the code you write, so it is implemented in the coding phase. Immutability is a property of runtime objects. It means ensuring that the state of the objects in memory is not modified after it is instantiated....
8
If you can guarantee Immutability, do you need to think about Encapsulation?
Perhaps, but probably not in a way most people think.
First, realize that encapsulation (the practice of hiding the internal structure of data) is not a goal. It is a means to decoupling (which in turn is a means to abstraction).
Next, you can achieve decoupling in ways that don'...
55
I hate how encapsulation is always framed as preventing unauthorized access. If this were the best way to think of it, immutability would indeed eliminate most of the need for encapsulation. In fact, immutability does eliminate many cases of overzealous encapsulation, where the only purpose of the encapsulation was to keep the bumbling callers out.
...
52
The question
Casting your question to real life:
Is it okay for your doctor to post your private medical records publicly to Facebook, provided no one (other than you) is able to change it?
Is it okay for me to let strangers in your house, provided they can't steal or damage anything?
It's asking the same thing. The core assumption of your question ...
32
Encapsulation could mean that you hide the actual storage of immutable data.
E.g.:
class Color
{
private readonly uint argb;
public byte Blue => (byte)(argb & 0xFF);
public Color(byte red, byte green, byte blue, byte alpha)
{
argb = alpha << 24 | red << 16 | green << 8 | blue;
}
}
The interface (the constructor and ...
23
Coupling
ClassA relies upon the interface only, delegating this responsibility of passing the classB object elsewhere
This is the idea. If you are separating ClassA from ClassB by the use of an interface ISomeInterface...
ensuring (ClassA) doesn't know ClassB
Then you do not want ClassA to ...
22
Your confusion is probably caused by focussing on meaningless class and interface names, with no real usage scenario behind it. So better let us make a concrete example (I prefer C#, but it is not really different in other languages like Java).
The IComparable interface in the .NET framework looks (simplified) like this:
interface IComparable
{
int ...
Top 50 recent answers are included
