Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

UML Relations & Java Implementation

 
Prasma Kankut
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How are the following relationships typically implemented in a Java program?

  • Generalization
  • Realization
  • Association
  • Aggregation
  • Composition
  • Dependency


  • For example, Generalization is implemented as



    and Realization is implemented as



    What about the other relations? Can someone throw some examples?
     
    Prasma Kankut
    Greenhorn
    Posts: 21
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Also is it possible to find the types of relations from a Java code?

    Code 1:


    Code 2:


    Code 3:


    I guess the Code 3 is an example for Dependency relationship. Is my understanding correct?
    What about Code 1 & Code 2? Aggregation? Association?
     
    Ilja Preuss
    author
    Sheriff
    Posts: 14112
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Association, Aggregation and Composition can't easily be distinguished in code. The most straightforward implemention is an instance variable, but other ways are possible.

    Generalization/Realization more or less translate to inheritance. Of course it depends on what kind of diagram you see it in whether it will directly translate to code at all.

    Dependency could be all kinds of things. If A depends on B it typically means that if B changes, A needs to be recompiled together with B.
     
    Damon Jasperson
    Greenhorn
    Posts: 2
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Composition can be easily identified in Java code. Remember that composition refers to the parts that make up the whole, so without the whole, there are no parts!

    If a Car composes an Engine, then the following code will result:

    public class Car {
    private Engine engine;

    public Car() {
    engine = new Engine();
    }

    public void startEngine() {
    engine.start();
    }

    protected void finalize() {
    engine = null;
    super.finalize();
    }
    }

    The main thing to take away here is that there is no direct access to the Engine object. Ultimately, it should be understood that composition is a specialized form of aggregation (strong aggregation), which strictly defines the lifetime of a composed object.
    [ March 19, 2008: Message edited by: Damon Jasperson ]
     
    Ilja Preuss
    author
    Sheriff
    Posts: 14112
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by Damon Jasperson:

    The main thing to take away here is that there is no direct access to the Engine object.


    That's not required for a Composition. It's true, though, that this is a quite strong indicator for a Composition relationship.
     
    Ulf Dittmer
    Rancher
    Posts: 42968
    73
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Some useful explanations on this topic can also be found in http://faq.javaranch.com/java/AssociationVsAggregationVsComposition
     
    Damon Jasperson
    Greenhorn
    Posts: 2
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    QUOTE]That's not required for a Composition. It's true, though, that this is a quite strong indicator for a Composition relationship.

    I disagree, here's why:

    If composition implies lifecycle management by the composer (it does), then any outside object that can obtain a handle to the composed object (the Engine, in the example) can prevent garbage collection of an Engine that has been made available for garbage collection by virtue of its composer (the Car) being made available for garbage collection. In other words, by gaining access to the Engine explicitly, you've violated the contract of composition by subverting the lifecycle management defined by composition.

    So, in this case, by destructing the car, you may not be able to destruct the engine because you've allowed outside access to the engine.
     
    Scott Ambler
    author
    Ranch Hand
    Posts: 608
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    At my java articles I have links to a series of articles that I wrote 5-6 years ago on this topic.

    - Scott
     
    Ilja Preuss
    author
    Sheriff
    Posts: 14112
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Originally posted by Damon Jasperson:
    If composition implies lifecycle management by the composer (it does),


    Well, it not only implies it, it actually is *the* defining criteria.

    then any outside object that can obtain a handle to the composed object (the Engine, in the example) can prevent garbage collection of an Engine that has been made available for garbage collection by virtue of its composer (the Car) being made available for garbage collection. In other words, by gaining access to the Engine explicitly, you've violated the contract of composition by subverting the lifecycle management defined by composition.


    - in a language with garbage collection, you simply have much less control over the lifecycle of an object. The best the "whole" actually can do is *prevent* garbage collection as long as it needs to. (That also means that Composition is much less important in a language with a garbage collector than in a language where you actively need to destroy an object.)

    - one object having the responsibility of lifecycle management for another object doesn't necessarily mean that it's also the object's responsibility to prevent other objects from fulfilling that responsibility. It could just be the *developer's* responsibility to not make other objects intervene.

    - Composition actually allows for the responsibility to be passed around. That is, there may only be one object be responsible for it at any time through the life of the "part", but it doesn't have to be the same object all the time.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic