UML Class Diagram Relationships, Aggregation, Composition

There are five key relationships between classes in a UML class diagram : dependency, aggregation, composition, inheritance and realization. These five relationships are depicted in the following diagram:

UML Class Relationships

The above relationships are read as follows:

• Dependency : class A uses class B
• Aggregation : class A has a class B
• Composition : class A owns a class B
• Inheritance : class B is a Class A  (or class A is extended by class B)
• Realization : class B realizes Class A (or class A is realized by class B)

What I hope to show here is how these relationships would manifest themselves in Java so we can better understand what these relationships mean and how/when to use each one.

Dependency is represented when a reference to one class is passed in as a method parameter to another class. For example, an instance of class B is passed in to a method of class A:

?

1 2 3

public class A {     public void doSomething(B b) {

Now, if class A stored the reference to class B for later use we would have a different relationship calledAggregation. A more common and more obvious example of Aggregation would be via setter injection:

?

1 2 3 4 5

public class A {     private B _b;     public void setB(B b) { _b = b; }

Aggregation is the weaker form of object containment (one object contains other objects). The stronger form is called Composition. In Composition the containing object is responsible for the creation and life cycle of the contained object (either directly or indirectly). Following are a few examples of Composition. First, via member initialization:

?

1 2 3

public class A {     private B _b = new B();

Second, via constructor initialization:

?

1 2 3 4 5 6 7

public class A {     private B _b;     public A() {         _b = new B();     } // default constructor

Third, via lazy init (example revised 02 Mar 2014 to completely hide reference to B):

?

1 2 3 4 5 6 7 8 9 10

public class A {     private B _b;     public void doSomethingUniqueToB() {         if (null == _b) {             _b = new B();         }         return _b.doSomething();     } // doSomethingUniqueToB()

Inheritance is a fairly straightforward relationship to depict in Java:

?

1 2 3 4 5 6 7 8 9 10 11

public class A {     ... } // class A public class B extends A {     .... } // class B

Realization is also straighforward in Java and deals with implementing an interface:

?

1 2 3 4 5 6 7 8 9 10 11

public interface A {     ... } // interface A public class B implements A {     ... } // class B

Note: (added 3/2/14 in response to comments) Let me point out that in the above composition examples ‘new’ could be replaced with a factory pattern as long as the factory does not return the exact same instance to any two different containing/calling objects, which would violate the key tenet of composition which is that the aggregated objects do not participate in a shared aggregation (two different container objects sharing the same component part object). The builder pattern could also be used as long as the distinct ‘parts’ are not injected into more than one containing object.

6/29/2014 – here’s a good article on class diagrams and answers Ivan’s question below in the comments:
http://www.ibm.com/developerworks/rational/library/content/RationalEdge/sep04/bell/

http://usna86-techbits.blogspot.de/2012/11/uml-class-diagram-relationships.html

Difference between ascii and unicode

ASCII defines 127 (maybe 128) characters, which map to the numbers 0–126. Unicode defines (less than) 2²¹characters, which, similarly, map to numbers 0–2²¹ (though not all numbers are currently assigned, and some are reserved).

Unicode is a superset of ASCII, and the numbers 0–126 have the same meaning in ASCII as they have in Unicode. For example, the number 65 means “Latin capital ‘A'”.

Because Unicode characters don’t generally fit into one 8-bit byte, there are numerous ways of storing Unicode characters in byte sequences, such as UTF-32 and UTF-8.

http://stackoverflow.com/questions/19212306/difference-between-ascii-and-unicode

Eclipse gives “Java was started but returned exit code 13”

In your eclipse.ini file simply put

–vm
/home/aniket/jdk1.7.0_11/bin(Your path to JDK 7)

before -vmargs line.

http://stackoverflow.com/questions/19721290/eclipse-gives-java-was-started-but-returned-exit-code-13

Checking for a null int value from a Java ResultSet

The default for ResultSet.getInt when the field value is NULL is to return 0, which is also the default value for your iVal declaration. In which case your test is completely redundant.

If you actually want to do something different if the field value is NULL, I suggest:

int iVal;
ResultSet rs = magicallyAppearingStmt.executeQuery(query);
if (rs.next()) {
    iVal = rs.getInt("ID_PARENT");
    if (rs.wasNull()) {
        // handle NULL field value
    }
}

http://stackoverflow.com/questions/2920364/checking-for-a-null-int-value-from-a-java-resultset

When to use stubs and mocks?

Martin Fowler has a good discussion here.

From his article:

Meszaros uses the term Test Double as the generic term for any kind of pretend object used in place of a real object for testing purposes. The name comes from the notion of a Stunt Double in movies. (One of his aims was to avoid using any name that was already widely used.) Meszaros then defined four particular kinds of double:

• Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.
• Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).
• Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it ‘sent’, or maybe only how many messages it ‘sent’.
• Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

Of these kinds of doubles, only mocks insist upon behavior verification.

http://stackoverflow.com/questions/1288168/when-to-use-stubs-and-mocks

what is the difference between loose coupling and tight coupling in object oriented paradigm?

Tight coupling is when a group of classes are highly dependent on one another.

This scenario arises when a class assumes too many responsibilities, or when one concern is spread over many classes rather than having its own class.

Loose coupling is achieved by means of a design that promotes single-responsibility and separation of concerns.

A loosely-coupled class can be consumed and tested independently of other (concrete) classes.

Interfaces are a powerful tool to use for decoupling. Classes can communicate through interfaces rather than other concrete classes, and any class can be on the other end of that communication simply by implementing the interface.

Example of tight coupling:

class CustomerRepository
{
    private readonly Database database;

    public CustomerRepository(Database database)
    {
        this.database = database;
    }

    public void Add(string CustomerName)
    {
        database.AddRow("Customer", CustomerName);
    }
}

class Database
{
    public void AddRow(string Table, string Value)
    {
    }
}

Example of loose coupling:

class CustomerRepository
{
    private readonly IDatabase database;

    public CustomerRepository(IDatabase database)
    {
        this.database = database;
    }

    public void Add(string CustomerName)
    {
        database.AddRow("Customer", CustomerName);
    }
}

interface IDatabase
{
    void AddRow(string Table, string Value);
}

class Database : IDatabase
{
    public void AddRow(string Table, string Value)
    {
    }
}

Another example here.

http://stackoverflow.com/questions/2832017/what-is-the-difference-between-loose-coupling-and-tight-coupling-in-object-orien

What is high cohesion and how to use it / make it?

High cohesion is when you have a class that does a well defined job. Low cohesion is when a class does a lot of jobs that don’t have much in common.

Let’s take this example:

You have a class that adds two numbers, but the same class creates a window displaying the result. This is a low cohesive class because the window and the adding operation don’t have much in common. The window is the visual part of the program and the adding function is the logic behind it.

To create a high cohesive solution, you would have to create a class Window and a class Sum. The window will call Sum’s method to get the result and display it. This way you will develop separately the logic and the GUI of your application.

http://stackoverflow.com/questions/10830135/what-is-high-cohesion-and-how-to-use-it-make-it

How to destroy Programmer Productivity

George Stocker

The following image about programmer productivity is making its rounds on the internet:

As Homer Simpson might say, it’s funny because it’s true.

I haven’t figured out the secret to being productive yet, largely because I have never been consistently productive. Ever. Joel Spolsky talks about this in one of his blog posts:

Sometimes I just can’t get anything done.

Sure, I come into the office, putter around, check my email every ten seconds, read the web, even do a few brainless tasks like paying the American Express bill. But getting back into the flow of writing code just doesn’t happen.

These bouts of unproductiveness usually last for a day or two. But there have been times in my career as a developer when I went for weeks at a time without being able to get anything done. As they say, I’m not in flow. I’m not in the…

View original post 614 more words