Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #31244

Re: About concurrency and functional programming

Show key headers only | View raw

On 01.03.2015 09:41, Robbie Brown wrote:
> On 01/03/15 02:28, Jerry Stuckle wrote:
>> On 2/28/2015 4:26 PM, Robbie Brown wrote:
>>> On 28/02/15 18:56, Joshua Cranmer 🐧 wrote:
>>>> On 2/27/2015 6:45 PM, Ramine wrote:
>>>>> You will notice that "Bartosz Milewski" is saying that object oriented
>
> <snip>
>
>>>>
>>>> I don't know where you learned object-oriented programming, but however
>>>> much it cost you was a waste of money if you passed without being able
>>>> to distinguish between composition and inheritance.
>>>
>>> hmm
>>>
>>> Thinking abstractly, inheritance is a perfectly valid way of
>>> implementing composition. In fact, we can look on inheritance as the
>>> purest form of composition (in an Object Oriented paradigm). An instance
>>> of a subclass cannot exist without the superclass extant, the subclass
>>> is (in part) *composed* of the superclass.
>>>
>>> How do you 'distinguish between composition and inheritance'?
>>> (as opposed to distinguishing between composition and aggregation)
>>> they are two entirely different (but ultimately, often connected)
>>> concepts.
>>>
>>> I do agree that the OP has a somewhat 'unique' way of putting his/her
>>> ideas across to say the least.
>>>
>>>
>>
>> I would strongly disagree with this.  Inheritance and composition are
>> two entirely different things, with two entirely different approaches to
>> programming.  About the only thing they have in common is there is some
>> kind of relationship between the parts.  But what kind of relationship
>> is all important.
>>
>> Composition exists in virtually every programming language, including
>> assemblers.  The elements of the composition have a "has-a" relationship
>> with the object.  For instance, a Person has a Name, a BirthDate, and
>> many other attributes.
>>
>> Inheritance, OTOH, exists only in Object Oriented languages such as
>> Java, SmallTalk and C++.  The relationship between the base and the
>> derived classes is an "is-a" relationship.  For instance, and Employee
>> is always a Person and has the same attributes of a Person.  However,
>> the Employee has additional attributes such as StartDate, CurrentSalary
>> and others.
>>
>> It's easy to get composition and inheritance mixed up - but even in the
>> most abstract case they are not the same thing.
>
> Actually, I find that people often get composition and aggregation mixed
> up,

And now you even mix up the topic of the discussion: it was composition 
vs. inheritance.

> personally I can never remember which UML diamond to use for each,
> filled or outlined, I have to write it down :-(
>
> Anyway, here's a thing
> (compiles in Eclipse Kepler with compliance = 8)
>
> class A{
>     protected Integer state = 99;
> }
>
> abstract class B {
>
>     protected A a;
>
>     public B() {
>        a = new A();
>     }
> }
>
> class C extends B{
>
> }
>
> public class D{
>
>     public static void main(String[] args){
>
>        C c = new C();
>        B b;
>        b = c;
>        Integer x = c.a.state;
>        Integer y = b.a.state;
>        System.out.printf("%d", x);
>        System.out.printf("%d", y);
>        //prints 9999
>     }
> }
>
> So, I think we probably agree that B has a composite relationship
> with A, C has an inheritance relationship with B, B is a composite.

Check.

> C 'is a' B. Is C composite by inheritance?

Not sure what that is supposed to mean.  C inherits B and as such 
instances of C contain an instance of A as well.  So in sum, C makes use 
of both concepts but for different purposes.

> C is certainly 'a B' but B can't 'exist' without C and dies when C dies.

No, C does not die but _instances_ of C die!  That's a huge difference. 
  And for all these instances there are just two object identities and 
not three - one for instance of A and one for instance of C.  There is 
no separate identity for instances of B, so there is no composition at 
work.  It's really that simple.

> In at least one way, C 'owns' B.

Not at all.  Ownership is usually not a concept used among classes but 
rather used to describe relationships between instances.

> B has no meaning or purpose in the
> system without C, a classic description of composition.

The purpose of B is to inherit from it (either because it represents an 
abstract concept or purely for implementation inheritance purposes).  If 
there is no class inheriting it then it _may_ be superfluous but the 
fact does not change the purpose of B.  Otherwise all interfaces defined 
in libraries are without purpose if not at least one class in the 
library implements it.  That is silly.

I recommend reading "Object Oriented Software Construction" by Bertrand 
Meyer.  That is the most profound work on various aspects of OO and 
inheritance I am aware of.  You'll be hard pressed to find a language 
that has more ways to do inheritance (and a few other things) than Eiffel.

Kind regards

	robert


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: About concurrency and functional programming Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2015-02-28 12:56 -0600
  Re: About concurrency and functional programming Robbie Brown <rob@example.com> - 2015-02-28 21:26 +0000
    Re: About concurrency and functional programming Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-28 21:28 -0500
      Re: About concurrency and functional programming Robbie Brown <rob@example.com> - 2015-03-01 08:41 +0000
        Re: About concurrency and functional programming Robert Klemme <shortcutter@googlemail.com> - 2015-03-01 12:34 +0100
          Re: About concurrency and functional programming Robbie Brown <rob@example.com> - 2015-03-01 14:26 +0000
            Re: About concurrency and functional programming Joerg Meier <joergmmeier@arcor.de> - 2015-03-01 15:30 +0100
              Re: About concurrency and functional programming Robbie Brown <rob@example.com> - 2015-03-01 14:31 +0000
            Re: About concurrency and functional programming Robbie Brown <rob@example.com> - 2015-03-01 14:30 +0000
            Re: About concurrency and functional programming Jerry Stuckle <jstucklex@attglobal.net> - 2015-03-01 11:29 -0500
              Re: About concurrency and functional programming Robbie Brown <rob@example.com> - 2015-03-01 17:07 +0000
                Re: About concurrency and functional programming Joerg Meier <joergmmeier@arcor.de> - 2015-03-01 20:12 +0100
                Re: About concurrency and functional programming Robbie Brown <rob@example.com> - 2015-03-01 20:31 +0000
                Re: About concurrency and functional programming Jerry Stuckle <jstucklex@attglobal.net> - 2015-03-01 16:13 -0500
                Re: About concurrency and functional programming Jerry Stuckle <jstucklex@attglobal.net> - 2015-03-01 16:11 -0500
                Re: About concurrency and functional programming Jerry Stuckle <jstucklex@attglobal.net> - 2015-03-01 16:17 -0500
    Re: About concurrency and functional programming Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2015-03-01 12:03 -0600

csiph-web