Re: About concurrency and functional programming
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
<snip>
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
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/