Talk:Object composition

Composition versus Inheritance

It would be interesting if somebody would add a small section discussing this. A Google search on this topic suggests that these are comparable solutions to the same problem of class relationships, except the composition allows for runtime hierarchy management. An example demonstrating this comparison would be interesting. --Daydreamer302000 (talk) 08:01, 11 May 2009 (UTC)

There is a short discussion about this now, but it is inadequate: it doesn't really explain what is different about subtyping, and it uses C as the example language, which has no subtyping. Rp (talk) 19:15, 15 March 2010 (UTC)

Code associated with UML diagram

Below the UML diagram, there is a piece of code showing composition: a car is composed of one carburetor. The car class however, contains a pointer to a carburetor. This is in contrast with the code examples in the point above, where is stated that composition uses an 'object within object' structure, whereas aggregation uses a reference/pointer to the object. In my opinion, if I have understood correctly, the car/carburetor example should be without pointer. it also shows what the sun is. --Patrickdepinguin 19:05, 18 June 2006 (UTC)

Your point is too language specific to easily fit into the article. Rp (talk) 16:05, 20 September 2009 (UTC)

I think User:Patrickdepinguin is quite right. Not using the pointer is the way to make a composite in C++, so why to show the questionable code, when there is a surely correct one? I grasped the idea of composite for myself just after I saw the proper code in C++ and I realized that you can't do a real composite in Java. Also, once you've used a pointer, you probably will have to deal with deallocation and that's straight against the concept of composite -- the component dies when the composite dies. --Jary (talk) 18:00, 12 August 2010 (UTC)

Multiplicity

The UML samples should be given multiplicity. On the owning (diamond) end of the association, for aggregation, the multiplicity, can be any multiplicity (except for 0..0), including 1, 0..1, 0..*, and *. For composition, the owning end can only be 1 or 0..1 --Mjchonoles 13:53, 18 May 2006 (UTC)

Done. Rjgodoy 18:02, 3 April 2007 (UTC)

I believe that 0..1 is not correct for the owning end of a composition. Only 1 should be possible, because the contained objects can only exist if the owning object exists. (There can be zero owning objects, but only if there are zero owned objects, in which case the relation is meaningless.) BTW: The German wikipedia shares this POV. --史慧开 (talk) 14:16, 9 September 2009 (UTC)

Splitsing of aggregation

I think aggregation should get its own article and that composition should only mention the differences briefly...

Record (database)

The subject "Record (database)" redirects here, but this page is rather complicated. I recommend an article under "Record (database)", with a link to this page, rather than a redirect. D021317c 05:56, 21 March 2007 (UTC)

Already redirected to Row. --Kubanczyk 19:08, 18 October 2007 (UTC)

UML Notation merged with text after introduction

The final paragraph of introduction had been copied as "UML Notation" (near the end of the article). "Aggregation" section also has an UML diagram, so "UML Notation" must be introduced before. Rjgodoy 01:37, 17 April 2007 (UTC)

No assembler in timeline

Assembler is definately the source of whole idea of "record". Could someone add assembler code as the first item in the timeline? Unfortunately I don't know any pre-COBOL assembler, such as S/360, but it would be perfectly logical here (I guess even zSeries would be better than nothing). --Kubanczyk 19:16, 18 October 2007 (UTC)

IMHO, records in assembler are just a region of memory plus an implicit convention of using such region for storing certain kind of data (nibbles, BCD, bit-flags, etc). I mean there is no assembler notation for declaring "records" besides the directives for reserving memory. Rjgodoy 15:28, 19 October 2007 (UTC)

Well, even if there would be no dedicated assembler notation (and I assure you that in many assemblers there is one), this programming concept (a record) originated around 1950s from the fact that assembly programmers liked to keep related variables close to each other in the memory, not scattered all over the address space. It may seem trivial now, but it's much more important observation than a syntax of some dinosaur languages (with all the respect to the reptiles). --Kubanczyk 17:04, 19 October 2007 (UTC)

Not to mention that the relationship with composition is pretty weak, except to an assembly language programmer. Rp (talk) 16:07, 20 September 2009 (UTC)

Aggregation in COM

This section may benefit from improvement, or possibly an image (see User talk:Rjgodoy/1). Shinobu (talk) 16:10, 7 January 2008 (UTC)

AggregationAndComposition.svg

Image talk:AggregationAndComposition.svg A user has requested that "Ducks" in AggregationAndComposition.svg be spelled "Duck" (singular). I think it makes sense, but I have no tools for editing svg. Rjgodoy (talk) 16:57, 20 February 2008 (UTC)

Right! Saw that this has been corrected in the image.--Sae1962 (talk) 10:07, 11 March 2015 (UTC)

Car example

The example is questionable, especially the way in which it is phrased.

Essential to composition is that the part has a necessary link with a whole, but a wheel can exist separately from a car. The example should therefore make it clear that the wheel being regarded as part of a car is not so much a property of wheels and cars as it is a property of a possible model of cars. I don't think the independent functioning of cars and wheels has much relevance, what matters is how wheels are identified within the system. Agree? Rp (talk) 09:50, 30 March 2009 (UTC)

I don't know nuthin and was reading Has-a and this article. The issue of the car is confusing. Your text makes more sense. The model is not a reality, it is a view of the reality. Same can be said of the human body. In a particular application, the body is a whole and may have an attribute of a good heart or bad one, but if we are swapping body parts in the application, then the heart is it's own object. Thanks for making it clear. — Preceding unsigned comment added by 69.88.64.142 (talk) 15:36, 9 August 2011 (UTC)

So in a DB and address may be an attribute, and though it may e changed, the old address would be lost, Where if it is modeled so that the address is in another table, then though the address can be changed in the Ship To fields, the old one still exists in the other table and may be selected and reported on. The ship to field would just use a reference to it. — Preceding unsigned comment added by 69.88.64.142 (talk) 15:43, 9 August 2011 (UTC)

Structs as composites

The equivocation of composites with "record types" is equally questionable. For instance, the recursive struct example of a binary tree is inconsistent with the definition of a composite relationship as one in which existence of the members depends on existence of the whole. More generally, this is true for values in a record/struct, but if these values are pointers to objects el;sewhere, not for those objects. This should be clarified. Rp (talk) 19:19, 15 March 2010 (UTC)

Create keyword?

In code sample you can see:

 create dept()

AFAIK, there is no create keyword in C++ —Preceding unsigned comment added by Vanuan (talk • contribs) 17:30, 16 September 2010 (UTC)

error in first picture

On the first picture, the reresentation of aggregation and composition are in conflict with the text and code example. Aggregation should be an unfilled diamond, composition should be a filled diamond, but the symbols on the picture seems inverted. —Preceding unsigned comment added by 131.254.10.229 (talk) 16:21, 11 April 2011 (UTC)

Python recursive example is bogus

You cannot construct R due to infinite recursion in __init__. Not sure what this example is trying to illustrate... — Preceding unsigned comment added by 213.152.225.82 (talk) 18:51, 25 September 2012 (UTC)

Confusing article

The article is confusing because it makes no difference with composition and composite object (or structures) that are different things. Composition involves objects declared separately and then composed and that is similar to multiple inheritance. Composite objects are just objects made of other objects. Macaldo (talk) 14:25, 9 June 2014 (UTC)

Good point, but "composition" usually refers to the latter, not the former! The former is an action that can be performed to create an object out of other objects; the latter is a type of relationship that can exist between objects. Rp (talk) 10:51, 23 March 2015 (UTC)

"composition" does not usually refer to composites: it fully depend on the context. Composition over inheritance for example is not about composites but really about composition. This article should acknowledge this ambiguity and give a neutral view instead of making an amalgame and contributing to a lot of confusions (I added a separate section to further detail the arguments and highlight some contradictions). --Christophe (talk) 13:58, 3 October 2020 (UTC)

History of composition

Is it an attempt to show how composition looked in 1984 for C++ for instance? I can't think of a more confusing example in modern C++ (look at the other examples in C++?). Is it the same for other languages? Niberto (talk) 10:53, 15 January 2016 (UTC)

I agree, this is terrible with fixed size arrays instead of modern vectors. I think this history section should be abridged. Wikipedia is not Rosettacode.org ! It could be interesting to keep a couple of examples to show that composition predates OOP, but a couple of representative examples would be more than sufficient. In this regard, the COBOL, and PL/1 examples could be kept. Then one OO example showing something else than a structure made of basic types could be interesting. For anyone interested in composition history in a specific language, a better place would be the article on the language itself, I think --Christophe (talk) 13:49, 3 October 2020 (UTC)

General issues with the article and its objectivity

This article lacks of references when it claims that composition is conceptual and not related to the implementation. It therewith lacks of neutrality, taking a purely conceptual point of view, and disregarding OOP reality, which makes it somewhat inconsistent with the section on object composition in the Object-oriented programming article.

The article should therefore be revised to clarify the difference between:

• object composition viewed as an OOP technique (related to implementation): i.e. making an object by assembling several other objects. Interestingly, the C example and most of the timeline examples is exactly about this. (in UML, this is a simple association)
• object composition viewed as conceptual aggregation (abstract): i.e. the composite/component relationship (which in UML is indeed an aggregation or a composition whole/part relation), but wording in a way to avoid a confusion with the composite design pattern (recursive composition).

-> Was done, renaming "Detail" into "Programming technique" and "UML notation" into "UML modeling" --Christophe (talk) 20:59, 4 October 2020 (UTC)

This article contributes to some confusion, leading people to use aggregation in design models instead of simple associations, just because they intend to use object composition at implementation level, a phenomenon that James Rumbaugh, one of the UML founders use to call "modeling placebo".

-> Seems no longer necessary, since the simpler property and association are included in the UML section --Christophe (talk) 20:59, 4 October 2020 (UTC)

The revision could also be the opportunity to make the second sentence less ambiguous ("related to but ....") and explain the semantic differences in composition using reference types and value types.

-> Was done (second sentence) and seems no longer necessary (last para of programming technique covers the topic indirectly) --Christophe (talk) 20:59, 4 October 2020 (UTC)

Lastly it could remove some contractions such as:

• "refers to the logical or conceptual structure of the information, not the implementation or physical data structure" vs the many examples that are only about implementation and physical data.
• "However, as an object composition, the positions are relevant", which contradicts the claimed conceptual nature of the composition
• the sequence and set explanation, which only apply to composition of multiple objects (one-to-many), and not to flat composition of object of different types (many one-to-one). By the way, the terminology of sequence and sets seems specific to the UML community and not generally used across all OOP communities.

--Christophe (talk) 13:33, 3 October 2020 (UTC)