Object instances reuse and Eclipse API


Reading one of my colleague’s code I saw this:

GridLayout gl = new GridLayout();
gl .numColumns = 1;
gl .verticalSpacing = 0;
gl .marginHeight = 0;
gl .marginWidth = 0;

Composite c1 = new Composite(parent);
Composite c2 = new Composite(parent);
c1.setLayout(gl);
c2.setLayout(gl);

Personally I always create a new layout for each one of my GUI component. It is in my opinion more easy to read that the piece of code above and because there is a small number of such objects (having a UI with thousands of GUI component needing a layout is bad idea I think ;-)), creating a new one for each component doesn’t impact performances.

To go further in the probleme, reading this code lead me to the following question:

How do I know if a given class instance can be “shared” in several contexts ?

In the particular case of the GridLayout above, I was not able to find the answer in the Javadoc here. After looking at the source code of GridLayout it seems that there is no internal state saved anywhere, and thus it’s possible to use the same layout instance for several components.

May be I missed something or maybe it should be interesting to indicate this information in the Javadoc. For sure, I’ll take care of that when writing the documentation for my own libraries.

Advertisements

5 thoughts on “Object instances reuse and Eclipse API

  1. I bet tons of people (including me) have had your line of thinking concerning GridLayout and others like it. I did exactly what you did: I created one instance and engaged in reuse, after looking through the source to see that it was ok. However, that decision was not “pure”, as I consider I have violated the contract with my assumption, thus making it a low-risk hack, but hack nonetheless. Some things to consider:

    * Control’s getLayoutData and setLayoutData currently do not have any documentation that includes your assumption.
    * Those methods also are not final.
    * Therefore, the door has been open for people to extend Control and have their own implementation of those methods.
    * To change the contract now to be more restrictive on how to use parameters would break backward compatibility on Controls which in fact do change the value of the LayoutData.

    This is yet another case of “you better design your interface right the first time”.

    The best they could do is say, if you yourself created the instance of the control with “new”, and thus you know its concrete implementation, and if that instance is part of the official SWT library, then we henceforth declare that it will not modify the LayoutData. This is acceptable I think with SWT code, which often has less design, but as soon as you’re dealing with types that are created with abstract factories, you wouldn’t be able to take advantage of that clause, because you wouldn’t be creating types with “new”.

  2. The JFace API provides GridLayoutFactory and GridDataFactory to address this issue.

    Composite c1 = new Composite(parent);
    Composite c2 = new Composite(parent);
    GridLayoutFactory.fillDefaults() //
    .spacing(LayoutConstants.getSpacing(), 0) //
    .generateLayout(parent);

  3. Pingback: Object instances reuse and Eclipse API | Eclipse | Syngu

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s