When an internal is passed to another method, is it still an internal?

[Grzegorz Gałęzowski]

In GOOS, section Internals vs Peers, it says:

" Much of the point of an object, as we discussed above, is to encapsulate access to its internals through its API and to hide these details from the rest of the system".

On the other hand, just a few sentences later, is also says:

"If we expose too much of an object’s internals through its API, its clients will end up doing some of its work."

and my question here is: can an internal (as opposed to a peer) be exposed and still remain an internal? E.g. in this little snippet, is the internal field still an internal even though it is passed to the peer object's method (thus "exposed")? If it isn't an internal, then what is it?

public class InternalOwner {

  private Internal internal = new Internal();

  //possibly some methods that use internal for something

  public void doSomething(Peer peer) {

    peer.doSomethingElse(internal);

  }

}

Regards,

Grzegorz Gałęzowski

[John Donaldson]

Grzegorz,

 

I don’t like that the method doSomething of object Peer knows about the existence of object Internal. It hardly seems to fit the definition of “internal”.

Are you perhaps mistaking the difference between Internal (a real object that is internal), and “internals” – just some vague description of how an object (e.g. Peer) does it’s work?

 

John D

--

---
You received this message because you are subscribed to the Google Groups "Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/growing-object-oriented-software/ebb45c88-2222-4dd3-88b2-d23a09b64506n%40googlegroups.com.

[Steve Freeman]

As always, the answer is "it depends". It looks like the internal object is being used to hold state, which might not be that much of a problem.

It would be easier to talk about if we had a concrete example.

S

[Grzegorz Gałęzowski]

>  I don’t like that the method doSomething of object Peer knows about the existence of object Internal. It hardly seems to fit the definition of “internal”.

That's exactly my dilemma. On one hand, the object passed to Peer is not so internal anymore. On the other hand, Peer doesn;t know where it gets the object from. From its perspective, it may even be passedaround many times and receive the Internal instance from somewhere else. So I'm in two minds about it. Especially that the Internal instance doesn't look like a "peer object" either.

> Are you perhaps mistaking the difference between Internal (a real object that is internal), and “internals” – just some vague description of how an object (e.g. Peer) does it’s work?

That may be the case. The reason I'm confused is that the sentences I quoted are in the same section, just few sentences away from each other.

Regards,

grzesiek

[Grzegorz Gałęzowski]

> As always, the answer is "it depends". It looks like the internal object is being used to hold state, which might not be that much of a problem. 
> It would be easier to talk about if we had a concrete example.

My intention was to make sure I understand the terminology. For a long time, I thought if something is an internal, then it should be completely hidden inside its owner object, but then I re-read the secion about peers vs internals and found I missed the kind of situation I described. I often get this with collections as internals, so e.g. this toy example could illustrate what I'm sometimes seeing:

public class MessageChain {
  private List<Message> messages = new ArrayList<>();
  private String recipient;

  public MessageChain(String recipient) {
    this.recipient = recipient;
  }

  public void add(String title, String body) {
    messages.add(new Message(recipient, title, body));
  }

  public void send(MessageDestination destination) {
    destination.sendMany(messages);
  }
}

In this toy code, I pass the private collection to another method. Ignoring issues like passing mutable collections around (this could as well be an immutable collection or even a copy of the original collection), I'm in two minds about whether the collection is an internal. On one hand, it is being exposed somewhere, on the other hand, the destination object doesn't know where it receives this collection from and hence doesn't necessarily gain any knowledge about how the MessageChain class is built internally (from the perspective of the destination object, the list might as well be a copy, might be created locally in the send method or even come from a completely different object).

Regards,

grzesiek 

[Steve Freeman]

It looks like I've been off this list for a while. In this case, I wouldn't do anything with messages, I'd just test what happened when I add and send messages. If there were different distribution policies depending on the implementation of messages, then that would be a different question.