Object reference side effects - desirable?

[VisionSet]

My Swing Table model has a delete method.
When I call it it deletes a row from my table model, updates the view, and
deletes it from the underlying domain model.
Except that last step is a desirable *side effect*.

The swing model holds a list of domain model objects this is the same list
object that is retrieved from the domain model. So as a side effect changes
to the swing model affect changes to the domain model.
This is fine behaviour for me with this system, though I realise that often
more decoupling is desired.

The downside is that I don't explicitly call myDomainObject.deleteWhatever()
so my intent from pure code is not obvious.

Thoughts?

 

[VisionSet]

My Swing Table model has a delete method.
When I call it it deletes a row from my table model, updates the view, and
deletes it from the underlying domain model.
Except that last step is a desirable *side effect*.

The swing model holds a list of domain model objects this is the same list
object that is retrieved from the domain model. So as a side effect changes
to the swing model affect changes to the domain model.
This is fine behaviour for me with this system, though I realise that often
more decoupling is desired.

The downside is that I don't explicitly call myDomainObject.deleteWhatever()
so my intent from pure code is not obvious.

Thoughts?

I wonder if I have the answer?

At present I have Customer as the highest composer (Nothing maintains a list
of customers).
I use arrays[] and ArrayList to compose customers. So this is a good reason
to have a CustomerList object. I'll make it implement List delegating to a
wrapped ArrayList and very little code will change.

 

[Oscar kind]

My Swing Table model has a delete method.
When I call it it deletes a row from my table model, updates the view, and
deletes it from the underlying domain model.
Except that last step is a desirable *side effect*. [...]
This is fine behaviour for me with this system, though I realise that often
more decoupling is desired.

Yes. Preferably, the domain model just is. It doesn't do anything, it is
acted upon by the controller.

The downside is that I don't explicitly call myDomainObject.deleteWhatever()
so my intent from pure code is not obvious.

Thoughts?

One. Update the interface when you commit a change in the domain model.
This can be signaled by the controller logic (for example when a method on
a domain object completed successfully).

Advantage is that what you see is the current situation. Changes become
atomic, just as in a database; this is a Good Thing.

Also: when (for exmple) you create a list to commit, a change is most
likely initiated by the user. This is known to the controller, who can
then signal an update.

The only time when this does not work is when changes come in from the
outside (for example with a stock feed). But in that case a listener
structure in your domain objects is perfectly natural, and that can signal
the controller, etc.

 

[Michael Rauscher]

Hi,

My Swing Table model has a delete method.
When I call it it deletes a row from my table model, updates the view, and
deletes it from the underlying domain model.
Except that last step is a desirable *side effect*.

The swing model holds a list of domain model objects this is the same list
object that is retrieved from the domain model. So as a side effect changes
to the swing model affect changes to the domain model.
This is fine behaviour for me with this system, though I realise that often
more decoupling is desired.

The downside is that I don't explicitly call myDomainObject.deleteWhatever()
so my intent from pure code is not obvious.

Thoughts?

Your presentation logic directly manipulates domain objects and thus
implements application logic.

I'd introduce a control class whose instances control the access to
domain objects (btw: this doesn't have anything to do with the MVC
controller). OF course, I would not create only one control class for
the whole application but for every (group of) use case(s).

So, *any* access to the domain objects has to go through the control
object. If one (the presentation layer) wants to have a list of domain
objects, he has to ask the control object for this list. If one wants to
delete a domain object, he has to ask the control object to do this. And
if one needs a copy of a domain object, he has to ask the control object
to return one...

Bye
Michael

 

[VisionSet]

And
if one needs a copy of a domain object, he has to ask the control object
to return one...

Thanks.

Should the word 'copy' be stressed here.

 

[VisionSet]

And another question. Where does the reference to the base domain objects
go?
eg Accounts can be aggregated in a collection class, but where does the
(base) collection object reference go? Do I have a DomainSingleton class
and put my base collection object in that? Certainly doesn't seem right to
put in a control object.

 

[Michael Rauscher]

Thanks.

Should the word 'copy' be stressed here.

Maybe

Imagine a simple address form. If the control object would return the
"real" address object, the form may directly manipulate it.

IMHO, the situation should be something like this:

User wants to edit address 235, he executes the "Edit Address Use Case".

The use case object requests a copy of address 235 from the "Edit
Address Control Object" and creates a form object (the view) that
displays the address (the model) and allows the user to manipulate
(controllers) the form's fields.

If the user decides to save the changes, the use case asks the form
object to save it's state to the model (maybe there's a method called
viewToModel) and sends an update message to the control object.

If the user decides not to save the changes he made, the use case simply
closes the form and everything is fine ;-)

Bye
Michael

 

[Michael Rauscher]

And another question. Where does the reference to the base domain objects
go?
eg Accounts can be aggregated in a collection class, but where does the
(base) collection object reference go? Do I have a DomainSingleton class
and put my base collection object in that? Certainly doesn't seem right to
put in a control object.

Depends on your needs. But don't try to put everything into one class.
There would be too much coupling.

The control object may use simply an "Addresses" singleton or an
Address-DAO.

E.g.

public class Address {
//...
public Address() {}
public Address( Address toCopy ) { /* ... */ }
}

public class Addresses {
private static final Addresses instance = new Addresses();

// ...

private Addresses() {}
public Address getAddressByID( int id ) { /* ... */ }
public void replace( Address a, Address b ) { /* ... */ }
}

Then, the control class may implement something like

public Address getAddress( int id ) {
return new Address( Addresses.getAddressByID(id) );
}

public void update( Address address ) {
Address realAddress = Addresses.getAddressByID(address.getID());
Addresses.replace( realAddress, address );
}
Bye
Michael