• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

how, possibly, to encapsulate at the level of objects?

 
Guennadiy VANIN
Ranch Hand
Posts: 898
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Does anyone have experience of encapsulating at the level of objects? The simplest ways/patterns, plz. Java, as I understood, provides encapsulation ONLY at the level of class, so the instance has access to private attributes/methods of another object of the same class
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The language doesn't support object-level encapsulation.
- Peter
 
Guennadiy VANIN
Ranch Hand
Posts: 898
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The language doesn't support a lot of things. The question is how to construct it with what we have...
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, the other question is why to construct it. What would this be useful for?
 
Guennadiy VANIN
Ranch Hand
Posts: 898
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
By ALL the same reasons why people insist on encapsulation.
Plus one more, there are OO languages with encapsulation at the level of objects and there are tools that trnslate from one language to another.
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by G Vanin:
there are OO languages with encapsulation at the level of objects and there are tools that trnslate from one language to another.
That doesn't say a lot, since encapsulation is enforced at compile time, not at run time. Short of writing a javac preprocessor, I wouldn't know a feasible technique to enforce object-level encapsulation.
If you are perverse enough, you could have a class FoobarImpl, implementing the Foobar interface, created by a FoobarFactory. The interface is loaded using the normal class loader, but for each instantiation of Foobar the FoobarFactory creates a new classloader and loads FoobarImpl afresh. That way, each FoobarImpl instance technically belongs to a different class, and the objects will not have any access to each others' private parts. But I wouldn't classify this as "feasible" - too much overhead, too much effort, too little gain.
- Peter
 
Guennadiy VANIN
Ranch Hand
Posts: 898
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Peter,
I do not understand

The interface is loaded using the normal class loader, but for each instantiation of Foobar the FoobarFactory creates a new classloader and loads FoobarImpl afresh.

especially in parts of

  • FoobarFactory


  • creating a new classloader


  • May you throw in some link and/or example? VGV
    Peter and Jim,


    1. Yes, I am perverse if it is a term of being original, gettin away from conventions imposed by a language or getting to the roots of (Java?) smth.


    2. The encapsulation at the level of classes has an implicit presuppositions that:
      1. we do not have a lot of instances of a class,

      2. that class is not complicated, and is trackable; it was not written and re-written by years people that already died


      3. it is possible to control instances' interaction, etc.


      4. It is wrong! In practice we deal with a rather complicated subsubsubsubclasses, written by "nobody knows why and by whom",
        They are "do not touch me or..."
        There are millions of clients, molecules (in cubic cm), etc. Cheers


        [This message has been edited by G Vanin (edited October 30, 2001).]
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You need a FooBarFactory (or maybe a general EncapsulatedObjectFactory) because instantiation is simply too complicated - you want to abstract it in some way.
You can find examples of instantiating new ClassLoaders in every (open source) application server or servlet engine. In fact, my suggestion is quite similar to what happens when you redeploy a web-application and the server reloads the classes. Most of us have seen the occasional ClassCastException caused by the fact that reloaded classes are considered different from their predecessors even if they're completely identical.
What this suggestion doesn't address is the subsequent need for a new accessibility modifier that would allow a class instance to call class-private methods on another instance.
Yes, I am perverse if it is a term of being original, gettin away from conventions imposed by a language or getting to the roots of (Java?) smth.
Well, as you noted it is not exactly unheard of; but James Gosling et al apparently thought it wasn't the best way for Java.
The encapsulation at the level of classes has an implicit presuppositions [...] In practice we deal with a rather complicated subsubsubsubclasses [...]
Why? I don't see any significant issues. If a class has become so messed up that an ordinary developer can no longer safely modify it, then yes, with class-level encapsulation an object can mess up other instances. With object-level encapsulation the same developer would add methods enabling the instances to mess up themselves. The net effect is exactly the same. When a developer who doesn't understand the class starts to modify it, things go pear-shaped no matter how it's encapsulated.
Remains the question whether class-level encapsulation makes a class harder to understand. This could conceivably be the case, but I have yet to see a practical example of a class that really could've done with instance-level encapsulation. But I can easily come up with examples that would become less readable with the extra syntax required, e.g. linked list implementations and the like.
- Peter
 
Guennadiy VANIN
Ranch Hand
Posts: 898
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Peter,
I understood that you are not convinced in the necessity of encapsulation at object level.
In one of my previous employments I worked at ban transaction programming.
They still use Cobol and one of the main reason is that they have there guaranted security from what Java is refusing in the bid.
For ex., there is a common class Account, 2 subclasses SavingAccount and CurrrentAccount. They are managed by a program (if you out of money at current account it is automatically added from Savings Account, etc., etc.). Accounts may have different and common owners. There are conglomeration of banks, and different offices... They are all have associations (look in UML for that), they have assertions, they have transactions/interactions not only inside their own instances but also with someone's else instances of the same classes. They have static members, etc. It is only the part of very huge and complicated UML scheme... The classes are for code re-use not for duplicating for each account, client, bank
THERE IS A DANGER OF INTRUDERS, after all!!!
Beleive me that there is a need that account instances of one owner be isolated from another person's owner.
You just should look at examples of UML models, if you need a motivation
This is very strange that from one side Java promises absolute security and from the other side makes Disclaimers for possible damage in nuclear plants, etc.
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
GV,
I just looked at a few UML diagrams. They didn't look any different from the thousands I've seen before, and I still feel a bit unenlightened.
To my eyes, your example appears to miss the mark completely, but probably I'm just missing the point of your example. Account would be perfectly encapsulated; a user of Account wouldn't be able to tamper with its internals. A subclass of Account has no access whatsoever to its private methods and variables. This issue of encapsulation is only relevant within the class itself; not its subclasses, nor its superclasses. So I'm not sure why you're persistantly talking about subclasses and subsubsubclasses.
Security does not seem to be the issue either. If you regard the source code of Account as tainted, then Account cannot be trusted irrespective of whether you have object-level encapsulation or not. If, on the other hand, you trust Account (it's written by G-d Himself, sealed in a signed jar, hammered down using a security policy, etc) then you have a guarantee that an Account instance isn't doing anything nasty with other Accounts. The absence of object-level encapsulation doesn't make it any less trustworthy.
What am I missing?
- Peter
PS. The disclaimers about nuclear plants and medical applications are there because the development of software for those purposes requires a far more rigid and demanding process than that used to develop Java or 99.9% of the other software on the world. I don't think it has anything to do with language features, except perhaps the absence of real-time response guarantees.
[This message has been edited by Peter den Haan (edited October 31, 2001).]
 
Guennadiy VANIN
Ranch Hand
Posts: 898
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Peter,

A subclass of Account has no access whatsoever to its private methods and variables.

that is the problem. Account, as a class, does not have access to classes but <in a running program > we have deals with a lot of instances of the same class Account and they do not have any restrictions to access each other. The Account (SavingAccount) instance of one owner has acces to account of another owner! because class is the same. Try to explain this to the bank client that he lost money because the class was the same.
The real situation and UML models have deals with objects states evaluation interactively and in time.
[This message has been edited by G Vanin (edited November 02, 2001).]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic