aspose file tools*
The moose likes Java in General and the fly likes tell me if this is a good idea Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "tell me if this is a good idea" Watch "tell me if this is a good idea" New topic
Author

tell me if this is a good idea

Phil Chuang
Ranch Hand

Joined: Feb 15, 2003
Posts: 251
.. for establishing package or even class-specific access to an object.
SomeObject implements LockedByPackage which declares functions with a PackageLock object



So in order to access the object, you need a certain PackageLock. Only members of the same package can instantiate their PackageLock. However, it can still be passed around so care must be taken to not pass the PackageLock unnecessarily.
The main point of this methodology is to restrict read/write access to an object by what package the caller is in - this doesn't really affect a programmer, since they can always override a class, or create a new class in whatever package, but it does stop someone from writing a malicious jsp/servlet.
Jason Menard
Sheriff

Joined: Nov 09, 2000
Posts: 6450
As discussed in your other thread...
The point of MVC, which you mentioned in the other thread, is to maintain separation of the various layers. Allowing your view to manipulate your business objects directly, aside from generally being a bad idea, creates a coupling that runs counter to the purpose of MVC. A normal design pattern used to enforce this separation (again, see the other thread) is to use data transfer objects. In other words, if you need to maintain the integrity of your business objects, then only allow the user to access copies of your data (like you get with DTOs, see other thread for complete context), as opposed to the data itself. Good programming practices will allow you to protect your data from being maliciously manipulated without having to come up with some complex set of interfaces that goes outside of the norm.
Remember that design patterns are best practices used to solve common problems. There's no need to re-invent the wheel if a best practice already exists to solve your problem.
[ September 29, 2003: Message edited by: Jason Menard ]
Phil Chuang
Ranch Hand

Joined: Feb 15, 2003
Posts: 251
The objects in question are not really business objects, but rather simple beans that just hold data. They do no business logic at all, those are done by other objects which use the data beans. So I can reuse beans and not duplicate functionality anywhere else, I can control access at a package level without changing my existing package structure.
The reason I don't feel that DTO applies in my case is that I don't like the idea of having 2 objects doing the exact same thing except one not having mutator methods.
Maybe my whole application architecture needs reworking then - I'll give you an overview
database <-> dao <-> workflows <-> controller <-> view
What I call workflows are simply thread-safe processes which works on input and interacts with the data, and are called by the controller. The application has been designed so that the front end could be just about anything, as long as the inputs come in as strings. This means a little more work for a swing app, but is natural for a web app.
The way I pass around data is by using beans, and those are worked on by the workflows, then sent to the view. What I want to make sure of is that the view cannot directly modify these beans, it has to submit the proper inputs to the controller which then calls the workflow.
So am I crazy?
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Consider making all the methods on objects you want to protect, um, protected. Then build a facade with the only public interfaces in your package. Clients outside the package can only interact with the facade. The facade passes requests (more or less) straight through to the protected objects that do the real work. Would that meet your needs?
BTW: It's up to you to be sure your facade does not "leak" any protected objects out to other packages. But if all their methods are protected, others would find them pretty useless, wouldn't they?


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Phil Chuang
Ranch Hand

Joined: Feb 15, 2003
Posts: 251
I think i'd run into the same problems as before, namely that I want to allow multiple packages to be able to access the objects normally, just not all packages - because of the way I have my classes split up, the dao, workflow, and inputloader packages would all need to be able to access the setters on the bean.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Sorry, I didn't read your requirements thoroughly. Then again, maybe this difficulty is a sign from above regarding your package dependencies ...
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: tell me if this is a good idea
 
Similar Threads
FBN : Exception in High level Data Interface
NX:About DBMain interface
Beta Question: unlock
URLyBird 1.3.3 Locking question
ArrayList, contains, objects