Relationships between Classes

1. Association
   • Composition
   • Aggregation
2. Generalization
3. Realization
4. Dependency

Association(Has-A Relationship)

1. Association is a relationship between two separate classes that establish through their objects. Each objects have their own life-cycle and there is no owner. Association can be one-to-one, one-to-many, many-to-one, many-to-many. It isn’t a “has-a” relationship and only means that the objects “know” each other
   

   class Bank  
   { 
       private String name;      
   
       Bank(String name){ 
           this.name = name; 
       } 
         
       public String getBankName(){ 
           return this.name; 
       } 
   }    
   
   class Employee 
   { 
       private String name; 
      
       Employee(String name){ 
           this.name = name; 
       } 
         
       public String getEmployeeName(){ 
           return this.name; 
       }  
   } 
     
   class Association  
   { 
       public static void main (String[] args)  
       { 
           Bank bank = new Bank("Axis"); 
           Employee emp = new Employee("Mani"); 
             
           System.out.println(emp.getEmployeeName() +  
                  " is employee of " + bank.getBankName()); 
       } 
   } 
   

   In above example two separate classes Bank and Employee are associated through their Objects. Bank can have many employees, So it is a one-to-many relationship.

2. Aggregation and Composition are subsets of association meaning they are specific cases of association.Both of them conveys a has-a relationship to strong and weak degree
   1. Composition(Strong has-a relationship)
   2. Aggregation(Weak has-a relationship)
3. has-a relationship simply means that an instance of one class has a reference to an instance of another class or an other instance of the same class
4. Composition denotes a has-a relationship of Strong degree. Relationship among class members are strong.Classes which are grouped by Composition doesnot makes sense when interpreted seperately. I.E. when Person, Heart, Hand were seperated Heart and Hand doesnot make much sense.Objects in a composition relationship cannot, conceptually, exist in isolation. If we destroy the owner object, its members also will be destroyed with it
   
   

   public class WebPage { 
       private final PageHeader header;
       private final PageBody pageBody;
    
       public WebPage(PageHeader header, PageBody pageBody) {
           this.header = header;
           this.pageBody = pageBody;
       }
   }
    
   class PageHeader { 
       private String title;
       private String charset; 
   }
    
   class PageBody { 
       private String body;
   }
   

5. Aggregation denotes a has-a relationship of Weak degree.Relationship among class members are weak. I.E. When trees were seperated from City Class Trees still make perfect sense and stand on it own.Objects on both sides of an aggregation relationship can exist in isolation.
   

   

   public class Team { 
       private List<Player> players = new ArrayList<>();
       public void addPlayer(Player player) {
           this.players.add(player);
           player.setTeam(this);
       }
    
       public void removePlayer(Player player) {
           this.players.remove(player);
           player.setTeam(null);
       }
   }
    
   class Player { 
       private String name;
       private int age;
    
       public void setTeam(Team team) {
           this.team = team;
       }
   }
   

6. In UML notation, a composition is denoted by a filled diamond, while aggregation is denoted by an empty diamond, which shows their obvious difference in terms of strength of the relationship.
   

Composition vs Aggregation

Generalization(Is-A Relationship)

1. In inheritance, a child of any parent can access, update, or inherit the functionality as specified inside the parent object. A child object can add its functionality to itself as well as inherit the structure and behavior of a parent object.This type of relationship collectively known as a generalization relationship.

2. 

   public class Vehicle 
   {    
   
   }
    
   class Truck extends Vehicle 
   {
   
   }
    
   class Boat extends Vehicle 
   {
    
   }
   

Realization(interfaces)

1. In a realization relationship of UML, one entity denotes some responsibility which is not implemented by itself and the other entity that implements them. This relationship is mostly found in the case of interfaces.
2. Realization is a specialized abstraction relationship between two sets of model elements, one representing a specification (the supplier) and the other represents an implementation of the latter (the client).

   

3. class Hyndai implements Car {
   .
   .
   }
   

Dependency

1. In a dependency relationship, as the name suggests, two or more elements are dependent on each other.Dependency relationships exist when classes depend on each other in such a way that a change to one class may affect the other, such as when one class accepts an instance of another class as parameter to a method.
2. Dependency –> A references B (as a method parameter or return type)

   public class A {
       private C c;
       public void myMethod(B b) {
           b.callMethod();
       }
   }
   

3. Dependency relationships are represented by arrows on dashed lines. Dependency represents the weakest of relationship
4. A dependency relationship can exist when we have a Library class that manages Book objects. Since the Library class has a method that returns a Book, changes to the Book class could result in changes to the Library class (based on how Book objects are created).

   

   public class Library
   { 
       public Book findBook(String name) {
           //Do some book stuff.
           return new Book();
       }
   }
    
   class Book { 
       private String name;
       private String author;
   }
   

5. A dependency typically (but not always) implies that an object accepts another object as a method parameter, instantiates, or uses another object. A dependency is very much implied by an association.

UML Diagrams

1. Structure Diagrams
   • Class Diagrams
   • Deployment Diagrams
2. Behaviour Diagrams
   • Use Case Diagrams
   • Activity Diagrams
   • State Machine Diagrams
3. Interaction Diagrams
   • Sequence Diagrams

Class Diagrams Basics

1. Class Contains ClassName, Attributes and Operations
2. Class Names are written in Bold or Italic if class is Abstract
3. Attributes

    <Visibility><Name>:<Type>=<Defaultvalue><{Modifier}>
   

        
     Visibility 
       + - Public
       - - Private 
       ~ - Package
       # - Protected 	
     Name   
       Name of Variable
     Type 
       Integer, String, Boolean
     DefaultValue 
       Value by DefaultValue
     Modifier
       ReadOnly
   

4. Operations

    <Visibility><Name>(<ParameterList>):<ReturnType>	
   

     Visibility 
       + - Public
       - - Private 
       ~ - Package
       # - Protected 	
     Name   
       Name of Operations
     ParameterList		
       List of Parameters - Comma Seperarted or Empty
     ReturnType
       Integer, String or Another Class  
   

5. Static Elements – Static Operations and Attributes are underlined in UML Diagram

Relationships

Relationship	Depiction	Interpretation	Example
Dependency		A depends on B This is a very loose relationship and so I rarely use it, but it’s good to recognize and be able to read it.
Association		An A sends messages to a B Associations imply a direct communication path. In programming terms, it means instances of A can call methods of instances of B, for example, if a B is passed to a method of an A.
Aggregation		An A is made up of B This is a part-to-whole relationship, where A is the whole and B is the part. In code, this essentially implies A has fields of type B.
Composition		An A is made up of B with lifetime dependency That is, A aggregates B, and if the A is destroyed, its B are destroyed as well.

Are Dependency Injection and Depencency are Different?
Yes, They are. The Closest one to DI is aggregation. In Aggregation, we deal with direct objects. i.e. objects which maintain a state, life-cycle, etc.
But in Dependency Injection, we focus on class level interactions. This is diverged with pure OOP practice. Actually, in DI we tend to inject stateless classes(worker classes) into some other classes. Though they look like objects they are actually just stateless classes that are being injected. And instances of that class can stand independently too.

Assume a stateless worker class called StringUtils. It can be injected into classes called NounUtils, VerbUtils, etc. And also instances of StringUtils can also exist.

Which one is Close to Dependency(Not DI)
An association almost always implies that one object has the other object as a field/property/attribute (terminology differs).

A dependency typically (but not always) implies that an object accepts another object as a method parameter, instantiates, or uses another object. A dependency is very much implied by an association.

Association --> A has-a C object (as a member variable)
Dependency --> A references B (as a method parameter or return type)

public class A {
    private C c;
    public void myMethod(B b) {
        b.callMethod();
    }
}

Simple Example of Dependency, Association, Aggregation and Composition
Dependency (references)
It means there is no conceptual link between two objects. e.g. EnrollmentService object references Student & Course objects (as method parameters or return types)

public class EnrollmentService {
    public void enroll(Student s, Course c){}
}

Association (logical relationship) It means there is almost always a link between objects (they are associated). Order object has a Customer object

public class Bank {
}

public class Employee{
}

class Association 
{
    public static void main (String[] args) 
    {
        Bank bank = new Bank("Axis");
        Employee emp = new Employee("Mani");
           
        System.out.println(emp.getEmployeeName() + " is employee of " + bank.getBankName());
    }
}

Aggregation (has-a relationship of weak degree)
Special kind of association where there is whole-part relation between two objects. they might live without each other though.

public class PlayList {
    private List<Song> songs;
}

OR

public class Computer {
    private Monitor monitor;
}

Note: the trickiest part is to distinguish aggregation from the normal association. Honestly, I think this is open to different interpretations.

Composition (has-a relationship of strong degree+ ownership or Part-Of)
Special kind of aggregation. An Apartment is composed of some Rooms. A Room cannot exist without an Apartment. when an apartment is deleted, all associated rooms are deleted as well.

public class Apartment{
    private Room bedroom;
    public Apartment() {
       bedroom = new Room();
    }
}