21–30 of 140 posts
I sympathize, yet encapsulation is appropriate for some projects. Not all users of a library want to frequently update to their own code. Forbidding encapsulation and deprecation would increase this cost. Also, it's comforting to be able to refactor the guts of a class without harming users.
Does Java have something similar to .Net's reflection?
See http://download-llnw.oracle.com/javase/1.3/docs/api/java/lan...
"If I buy you a house and put the title in your name, but I mark some of the doors 'Employees Only', then you're not allowed to open those doors, even though it's your house. Because it's really my house, even though I gave it to you to live in." Love it!
Does Java have something similar to .Net's reflection?
In a global header long time ago, a friend of mine (and big "C" lover) did this to his best buddy once (a C++ and especially boost lover): #define class struct #define private public #define protected public
#define true false
#define false true
#define true 0
#define false !true
#define if while
#define continue break
In a global header long time ago, a friend of mine (and big "C" lover) did this to his best buddy once (a C++ and especially boost lover): #define class struct #define private public #define protected public
I sympathize, yet encapsulation is appropriate for some projects. Not all users of a library want to frequently update to their own code. Forbidding encapsulation and deprecation would increase this cost. Also, it's comforting to be able to refactor the guts of a class without harming users.
Encapsulation is completely orthogonal to access modifiers.
http://www2.research.att.com/~bs/glossary.html#Gencapsulatio...
Since this idea is not obvious, would someone mind explaining?
Eclipse is another matter: far more ridicule is called for. Far, far more.
I sympathize, yet encapsulation is appropriate for some projects. Not all users of a library want to frequently update to their own code. Forbidding encapsulation and deprecation would increase this cost. Also, it's comforting to be able to refactor the guts of a class without harming users.
The issue is less about encapsulation and more about language-enforced encapsulation. Encapsulation is good, but encapsulation that's enforced by the language is debatable.
For me, encapsulation comes down to "What I hide, I can change. What I expose, other types may couple to in an inappropriate way."
Earlier quoted context omitted.
Encapsulation is completely orthogonal to access modifiers.
Your view differs from some of the OO language designers. For example, Stroustrup defines encapsulation as "the enforcement of abstraction by mechanisms that prevent access to implementation details of an object or a group of objects except through a well-defined interface. C++ enforces encapsulation of private and proteced members of a class..." http://www2.research.att.com/~bs/glossary.html#Gencapsulatio... Since t…
Oh come on, that's not true at all. C++ just happens to use access modifiers to provide its brand of encapsulation. However, languages without the `private` reserve word can still provide encapsulation -- they're not the same thing.
What if Java had no notion of private? It would be very difficult to provide data hiding (not that they're hidden anyway, but that's beside the point), so instead you would be forced to put little flags on your names and warnings in your documentation delineating the parts that people shouldn't touch. If they did then that's their fault no?