Is it 'safe' to expect myClasses to agree not to only call package Scope methods from other Package scope methods?

Question

The questions says it all, but a quick overview of the situation. I'm creating a Model which contains classes (all inherriting myObject) which have a large amount of interconnection. I want the controller to be able to create any of these objects any time, without modifying the Model. Only an explicit cal to the model to "AddToModel" would 'install' the object into the model (including updating all the connected objects). myObjects will use a factory pattern, if a user tries to create something already represented in the Model the already-instanced object in the model will be returned instead of constructing a new one.

To help with encapsulation I want all of my Objects to be effectivly-immutable to the controller, no matter what he does with an object he can't change the Model without calling the Model's add/remove. The model still has to be able to change myObject state; so I would put all of the objects into the Model package. Each object will then have package scope methods for updating state, including add/remove methods which install them in the model and update connected objects. So essentially Package scope methods can change model state, public can't.

My concern is that this will all break if any of myObjects calls one of their package scope methods from a public method; messing with my state without explcit calls to Model. I am writing this all, so I can abide by the contract that "only package methdos can call other package methods" But what if someone comes by later and tries to call "addToModel" from a constructor because they didn't read my comments and don't realize this breaks an assumed contract?

Is it 'safe' to expect others to read comments and abide by such an implicit contract when messing with 'my' model? Can I enforce this with some sort of pattern (preferable without too much abstraction/interfaces as it could confuse some of the other developers).

ps, I'm using Java if that helps. I think I might even be able to enforce this with the security API, though that may just prove more confusing/complicated since it would result in an obscure runtime exception.

Answer 1

It sounds like you are planning on making Model and all these object classes mutually dependent. I think this is a bad idea that will make testing and maintenance very difficult. Probably none of the object classes should depend on Model. If the Model needs to react to object state changes, then you could have the Model observe the objects.

Answer 2

No. Classes/objects should have manage their own state. It sounds like you are expecting the Model to manage the state of myObject.

To elaborate, it sounds like

1. myObject has public "read-only" methods, and package-access "mutator" methods.
2. If myObject invokes its own "mutator" methods, Model will/might break.

Ideally, a future programmer should be able to change 'myObject' without breaking Model.