5 ms·
Encapsulation makes sure the data is hidden away, and, in theory, is only accessible through methods, which may, or may not internally use the same data. For e
by sklivvz1971 13y ago
Encapsulation makes sure the data is hidden away, and, in theory, is only accessible through methods, which may, or may not internally use the same data.
For example this pseudoclass
public class Sum1
{
private int _a, _b;
public Sum1(int a, b)
{
_a = a;
_b = b;
}
public int ReturnResult()
{
return _a+_b;
}
}
And this other pseudoclass
public class Sum2
{
private int _tot;
public Sum2(int a, b)
{
_tot = a+b;
}
public int ReturnResult()
{
return _tot;
}
}
Have the same behavior/functionality but depend on different internal data - in this sense the data has been decoupled from the functionality: one can treat the class as a black box - the coupling happens in the implementation of the class, but not anymore in the design of it.
- xerophtye 13y agoTo all the guys saying the example is bad code or is not complex enough. Well, of course! Think of this as a doodle to present a certain example. Quit complaining that it isn't to scale. He just means to show that OO lets us have the luxury of just caring about the functions we need to use to manipulate/use/access the data, without any regard to how it is internally stored.
- chongli 13y agoEncapsulation may hide the data away but it does not hide the effects of state. If an object contains mutable state, it is not referentially transparent. This makes the abstraction leaky, as users need to understand the possible states of an object lest it behave unpredictably.
- adwn 13y ago> If an object contains mutable state, it is not referentially transparent. Why shouldn't an object contain mutable state? When solving a problem for which pure, stateless programming is not suitable, where would you put state if not inside an object?
- chongli 13y agoIn an STM monad, or an ST monad, or even an IORef, or a core.async channel, or whatever. Functional languages have manifold approaches to state that do not require you to lose track of time. And that's the real key to understanding state, isn't it? Time.
- adwn 13y agoPlease do not drag this discussion to stateful vs. stateless programming. It's about OO, which is typically, in practice and in theory, associated with mutable state.
- chongli 13y agoFrom the original article: Refactoring to Functional–Why Class? This is a multi-part series on Refactoring to Functional Programming
- sklivvz1971 13y agoBehavior does not necessarily depend only on state. Behavior depends on state and the code that uses state to implement said behavior. Encapsulation allows us to think on terms of behaviors and not of internal states. That said, this paradigm is easily broken by bad code.
- wheaties 13y agoOne would argue that both are flawed because they are, in essence, a function which is not espressing itself clearly and cleanly. You are co-mingling state with computation in a way that obscures and loses the advantages therein. If you want to make an example of something, then use a Reader, such that you are abstracting away the "source" of what is read and the side-effects thereof. Or an expiring cache (which is a good example of mutable state.) Or a mixed Reader which "reads" from either a cache or in the case of passing the expiration mark on the "key," some unknown "source."
- adwn 13y agoIt's an example, sheesh! I suspect you're a programmer, so you should be able to abstract away the details of the example and take home the message.
- thangalin 13y agoThe code does not demonstrate encapsulation because the data type has not been decoupled from the implementation. A developer cannot change the internal representation to a float without changing code that calls ReturnResult, thereby defeating encapsulation. (Java cannot have two methods of the same name that differ by return type alone.) Encapsulation means that objects should perform operations on their data, instead of giving their data to other objects. See Tell, Don't Ask (http://pragprog.com/articles/tell-dont-ask http://pragprog.com/articles/tell-dont-ask) for details. Encapsulation also lends itself to the Open-Closed Principle whereby class behaviours can be changed through inheritance alone. Please see (and critique) my self-encapsulation presentation for details: http://whitemagicsoftware.com/encapsulation.pdf http://whitemagicsoftware.com/encapsulation.pdf
- adwn 13y ago> The code does not demonstrate encapsulation because the data type has not been decoupled from the implementation. Not all code has to be applicable to more than one use case. What you're suggesting is premature generalization, which is just as bad as premature optimization. One might argue that p.g. is a kind of p.o. with the metric to be optimized being abstraction.