Overcoming the one weakness of OOP, thoughts ?

[Luca Minudel]

Thanks to encapsulation, it is easy to locally understand an object in isolation, reuse it, extend it, evolve it, and most of all change it without affecting the rest of the program.

OOP does not provide a built-in support, comparable to encapsulation for flexibility, in object interrelationship such that relationships between objects or structure of objects in a relationship can change, without affecting the rest of the program. Instead :

1. When an object’s unstable dependency changes, it can trigger changes into the object itself and this can start a chain reaction of changes in dependent objects.
2. When an object hierarchy changes or some responsibilities or state is moved from one object to another, code traversing the objects and making computations on the traversed objects needs to be changed too, to adapt to the new object hierarchy and the new objects structure.

I'm writing a post based on my understanding of GOOS book, Mock Objects papers, Professor Karl Lieberherr work on Adaptive programming, and Sandi Metz's 'Less the path to better design:'

In the meanwhile I'd like to hear your thoughts and what solutions have been found so far to deal with this OO weakness?

Luca

[Christopher Gardner]

Approaches to mitigate or prevent such problems are following the stable dependencies principle and abstracting the actual relationship itself via a mediator.

--

---
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.
For more options, visit https://groups.google.com/d/optout.

[Luca Minudel]

Good points, thanks Christopher.

To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriented-software+unsubscribe@googlegroups.com.

[Steve]

Correct me if I'm wrong but it seems that you are describing two objects where the consumer has be written in such a way that it is coupled to the implementation of it's neighbor rather just dependent on it's interface. 

Your typical Solid principles can limit this headache.

This ripping effect can also occur when one makes the mistaken of over separating his design. By separating functionality that can't be reasoned about on its own across multiple objects resulting in this cascading changes. Kent beck has a short article on this

https://m.facebook.com/notes/kent-beck/bits-clumps-and-just-right/792597974106402

Thanks

Steven Solomon 

Sent from my Apple Lisa.

[Luca Minudel]

Hey Steven

thanks for the clarifying question to Christopher points.

If that helps the discussion, the kind of changes to the relationships and the object structure are like these:

 1) We are given a conglomerate of companies and we have to compute the total salary paid by the whole conglomerate.

2) Once the software is written, there are changes like
    - the list of employees is now available directly for every company, without the need to go through the list of offices and look into every office
    - the computation of the total salary now should include also subsidiary companies
    While this introduces changes in the objects hierarchy and in some object structure, the logic of the computation of the total salary
    and the logic of the navigation of the object essentially is still the same, still the related code needs to be changed.

This is another example I just sketched:

HTH, Luca

Il giorno giovedì 1 gennaio 2015 16:06:31 UTC+1, Steven Solomon ha scritto:

Correct me if I'm wrong but it seems that you are describing two objects where the consumer has be written in such a way that it is coupled to the implementation of it's neighbor rather just dependent on it's interface. 

Your typical Solid principles can limit this headache.

This ripping effect can also occur when one makes the mistaken of over separating his design. By separating functionality that can't be reasoned about on its own across multiple objects resulting in this cascading changes. Kent beck has a short article on this

https://m.facebook.com/notes/kent-beck/bits-clumps-and-just-right/792597974106402

Thanks

Steven Solomon 

Sent from my Apple Lisa.

On Jan 1, 2015, at 9:33 AM, Christopher Gardner <chris.r...@gmail.com> wrote:

Approaches to mitigate or prevent such problems are following the stable dependencies principle and abstracting the actual relationship itself via a mediator.

On Jan 1, 2015 9:21 AM, "Luca Minudel" <luca.m...@gmail.com> wrote:

Thanks to encapsulation, it is easy to locally understand an object in isolation, reuse it, extend it, evolve it, and most of all change it without affecting the rest of the program.

OOP does not provide a built-in support, comparable to encapsulation for flexibility, in object interrelationship such that relationships between objects or structure of objects in a relationship can change, without affecting the rest of the program. Instead :

1. When an object’s unstable dependency changes, it can trigger changes into the object itself and this can start a chain reaction of changes in dependent objects.
2. When an object hierarchy changes or some responsibilities or state is moved from one object to another, code traversing the objects and making computations on the traversed objects needs to be changed too, to adapt to the new object hierarchy and the new objects structure.

I'm writing a post based on my understanding of GOOS book, Mock Objects papers, Professor Karl Lieberherr work on Adaptive programming, and Sandi Metz's 'Less the path to better design:'

In the meanwhile I'd like to hear your thoughts and what solutions have been found so far to deal with this OO weakness?

Luca

--

---
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-oriented-software+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
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-oriented-software+unsubscribe@googlegroups.com.

[Nat Pryce]

This is the problem that the "Law of Demeter" addresses. Using the Law of Demeter, one would make each Company object responsible for calculating total salary within the company. The application merely sums the total salary of each Company.

That way, the client(s) of the Company objects are shielded from changes to their structure. When the structure of the companies change, only the class of the affected companies would need to be changed, which should not affect the rest of the application.  The first time this happens, you can introduce a polymorphic interface between the company and the application and implement it differently for different company types.

To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

http://www.natpryce.com

[Luca Minudel]

Hi Nat

thanks for your description.

That looks pretty congruent with the way I'm using to summarize the 3 key elements of GOOS that helps to deal with the changes I described:
- programming by composition that with what nowadays we call dependency injection, to minimize and decouple dependencies
- the tendency to push behaviour towards Visitor-like, relevant for computations on object hierarchies
- Composite pattern to abstract away differences between the traversed objects

Luca

http://www.natpryce.com

[Nat Pryce]

I'm not sure about Visitor-like. Do you mean the Visitor pattern?

I think the key element of GOOS, w.r.t. your question, is that objects talk only to their immediate neighbours, and do not know anything about the object graph of which they are part.  Code does not explicitly traverse the object graph. The thread of control running through the objects does traverse the object graph (because it carries messages from one object to another), but the code that defines object behaviour is decoupled from the structure of that graph.

This idea came from a variety of sources -- the Law of Demeter, "Tell Don't Ask" by the PragProgs, and modelling concurrent message-passing systems with process calculi (CSP, pi-calculus, etc) to mention just three.

To unsubscribe from this group and stop receiving emails from it, send an email to growing-object-oriente...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

http://www.natpryce.com

[Raoul Duke]

and here i thought visitor pattern is like nigh an antithesis of oo. :-}

[Luca Minudel]

Yes, I mean objects like the visitor from the visitor pattern, used often in combination with the Composite pattern to abstract away differences between the traversed objects.

You put a lot of emphasis on programming by composition (or, is there a better name for it?).
In a previous email exchange you reference the work of Kramer, Magee and Sloman on the Conic and Regis systems and the Darwin configuration language.  And you mention the first paper on
Conic (from 1981!) describes how software can be composed with what is now called dependency injection.

Because of that, in the current draft of the post I considered programming by composition and dependency injection as equivalent.
Your emphasis on programming by composition make me thing that deserve to be considered two distinct things, programming by composition is much more that just D.I.

Luca