Re: About concurrency and functional programming
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, 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.
C 'is a' B. Is C composite by inheritance?
C is certainly 'a B' but B can't 'exist' without C and dies when C dies.
In at least one way, C 'owns' B. B has no meaning or purpose in the
system without C, a classic description of composition.
Just a thought.
--
Not floundering ... just fishing