There are two common ways to initialize class attributes:

1. Provide value in declaration, i.e. you set the value as you introduce data field
2. Set value in constructor

public class Testy {
    private int a = 12; // you set value in declaration
    private int b;
    private int c;

    public Testy()
    {
        this.b = 21;      // you set value in constructor
    }
}

However, there’s actually a third way:

3. Use initialization block

public class Testy {
    private int a = 12; // you set value in declaration
    private int b;
    private int c;

    public Testy()
    {
        this.b = 21;      // you set value in constructor
    }

    // object initialization block
    // executed every time object of the class is constructed
    {
        this.c = 44;
    }
}

What benefit this structure has over other methods? You can use this to abstract common construction logic (when you have several constructors relying on some common initialization). But, the same effect could be achieved by calling common constructor via this() as the first statement to every constructor requiring prior call to common constructor. Overall, I can hardly think about any use case that initialization block could resolve better than using constructors directly. It might be issue of preference.

However, initialization blocks could still be very useful. When? In situations where constructors do not provide a solution: yes I am talking about static fields. If you need some complex logic initializing your static fields, static initialization block resolves the issue neatly:

public class Testy {
    protected static int x;

    // static initialization block
    static   // Note the word "static" before initialization block curly braces.
    {
        Random generator = new Random();
        Testy.x = generator.nextInt(100);
    }
}

NB:
Initialization blocks are executed before constructors and after fields are initialized to their default values (which are either values provided in field declaration or one of true, 0, null depending on type). Static initialization takes place only once – when class is loade

Overall, I don’t understand the whole idea of implementing simple and easy-to-learn language, get popular, and then redesign the language to include all the goodies from “real languages like C/C++, Java”. But that’s topic for another post, I guess

So, now when I have a little more time to experiment with Java, and as it is as object-oriented as one might dream, I wanted to study patterns in details. I plan to post number of articles later this month, but for now, I wanted to capture one (important if you are planning to use UML and Patterns) simple concept – that’s difference between Aggregation and Composition. As simple as it might seem, there quite a lot of people who don’t understand it.

First of all, both Aggregation and Composition are Associations, and actually share characteristics, so I wouldn’t bother you with “has a”, “is a”, “is part of” cliches, which aren’t as helpful as it’s believed.

Very good definition of Aggregation, goes as following:

Aggregation is a whole/part association where a client object contains one or more server objects, but the client object can be defined with or without the creation of the server object. For instance, a car can contain golf clubs in its back trunk but the car is still a car with or without the golf clubs.

Let me translate. Aggregation is a “whole/part” association, and is used to describe object relationship where object A (client, aggregate, whole) contains object(s) B (server, component, part). Here, important word is “contains” – client literally contains the server object(s), it’s not composed of them.

Actually, that’s the sole difference between Aggregation and Composition, where later is a special case of former.

Before I provide some code examples, here is similar definition of Composition (do compare it with definition of Aggregation):

Composition is a stronger whole/part association where a client object is composed of one or more server objects, such that without the creation of the one or more server objects the client object could not be created. For instance, a car’s composition consists of an engine among other objects. However, the car would not be considered a car if it did not have an engine.

So, Aggregation vs. Composition is really a matter of control over life-cycle of parts within the whole. With Aggregation you can attach parts to whole at any time – for the whole to be initialized presence of parts that the whole might contain is not required. With Composition you have another story: since parts constitute the logical whole with the main object i.e. object is considered to be the sum of all its parts, you have to initialize parts at a time the container object is initialized.

Let’s have a look at examples.

As Aggregation refers to containment, and in Java code might look as following:

import java.util.ArrayList;
 
public class Aggregation {
    public static void main(String[] args)
    {
        Player Kaka = new Player();
        Team team = new Team();
        team.addPlayer(Kaka); // Kaka is now contained!
    }
}
 
/**
 * Client, Aggregate, Whole
 */
class Team {
    private ArrayList players;
 
    public Team() {
        // player list is empty, we can attach players via addPlayer(), so
        // that team CONTAINS players, however our team object is not dependant
        // on players for initialization - we can initialize Team objects even
        // if we have no intention to put players into them
        players = new ArrayList();
    }
 
    public void addPlayer(Player p)
    {
        players.add(p);
    }
}
 
/**
 * Dump Part class
 */
class Player {}

As you see Team object can exist without any players, and we can attach Player objects at any point after Team’s initialization.

Now, lets turn our attention to Composition example. Here parts should be initialized (generally within constructor of container class) prior to full initialization of container. Do understand that decision on which association is more appropriate depends on our aims, and we can re-write the Team/Player example to express composition if we believe that Team is composed of Players (so no entity could be called Team if it hasn’t got players):

import java.util.ArrayList;
 
public class Composition {
    public static void main(String[] args)
    {
        // player objects life-cycle is totally under container class controll
        Team team = new Team();
    }
}
 
/**
 * Client, Aggregate, Whole
 */
class Team {
    private ArrayList players;
 
    public Team() {
        players = new ArrayList();
        players.add(new Player());
    }
}
 
/**
 * Dump Part class
 */
class Player {}

As you see the difference is more conceptual. Indeed, when it comes to code, we can use the same constructs (member variables in this case) quite differently. If we have Aggregation in mind, then our container class can hold/contain components, while it doesn’t interested in initialization of those components (and destruction – which is not an issue in Java, due to garbage collection, but should be taken into consideration for, say, C++). If what we mean is Composition, then our container object is literally composed of those parts, and as such initializes them at construction time.

What I want to stress: despite the fact that difference between Aggregation and Composition might be academical at times, their conceptual difference is not that small. And on conceptual level you should understand what you are dealing with. You might be wrong thinking that Aggregation is a better abstraction for a Team/Player concept, but you should understand what aggregation means.

Sorry for such a lengthy explanation of what in essence is quite a simple concept.

String laf = "com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel"; // определяем новый LaF
UIManager.setLookAndFeel(laf);  // устанавливаем новый LaF
SwingUtilities.updateComponentTreeUI(this);  // обновляем вн. вид компонентов

Для того чтобы посмотреть какие LaF у вас имеются в наличии, делаем следующее:

UIManager.LookAndFeelInfo[] lafs = UIManager.getInstalledLookAndFeels();
for (UIManager.LookAndFeelInfo info : lafs) {
    System.out.println(info);
}

Вот так вот все просто!