Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!eternal-september.org!feeder.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: About concurrency and functional programming Date: Sun, 01 Mar 2015 12:34:43 +0100 Lines: 164 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: individual.net jGYE5txvwd1calKuU8rwGwXXWdHQ5bhH0Tawc/2ZKNdpxuLVs= Cancel-Lock: sha1:azbFCNpMbQSVBBz3vT7CPkxfvM0= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 In-Reply-To: Xref: csiph.com comp.lang.java.programmer:31244 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 =F0=9F=90=A7 wrote: >>>> On 2/27/2015 6:45 PM, Ramine wrote: >>>>> You will notice that "Bartosz Milewski" is saying that object orien= ted > > > >>>> >>>> I don't know where you learned object-oriented programming, but howe= ver >>>> much it cost you was a waste of money if you passed without being ab= le >>>> 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 insta= nce >>> of a subclass cannot exist without the superclass extant, the subclas= s >>> 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 som= e >> 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" relationsh= ip >> 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, CurrentSalar= y >> and others. >> >> It's easy to get composition and inheritance mixed up - but even in th= e >> most abstract case they are not the same thing. > > Actually, I find that people often get composition and aggregation mixe= d > up, And now you even mix up the topic of the discussion: it was composition=20 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 =3D 8) > > class A{ > protected Integer state =3D 99; > } > > abstract class B { > > protected A a; > > public B() { > a =3D new A(); > } > } > > class C extends B{ > > } > > public class D{ > > public static void main(String[] args){ > > C c =3D new C(); > B b; > b =3D c; > Integer x =3D c.a.state; > Integer y =3D 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=20 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= =2E No, C does not die but _instances_ of C die! That's a huge difference.=20 And for all these instances there are just two object identities and=20 not three - one for instance of A and one for instance of C. There is=20 no separate identity for instances of B, so there is no composition at=20 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=20 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=20 abstract concept or purely for implementation inheritance purposes). If = there is no class inheriting it then it _may_ be superfluous but the=20 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=20 library implements it. That is silly. I recommend reading "Object Oriented Software Construction" by Bertrand=20 Meyer. That is the most profound work on various aspects of OO and=20 inheritance I am aware of. You'll be hard pressed to find a language=20 that has more ways to do inheritance (and a few other things) than Eiffel= =2E Kind regards robert --=20 remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/