Showing posts with label singleton. Show all posts

Tuesday, August 12, 2014

Programming Design Pattern - Singleton Pattern Applied - Best Practise

Hi there!

Today i'm gonna show the singleton design pattern in action. The singleton design pattern is a largely used and common programming design pattern while dealing with uniqueness in your application.

I'm assuming here you already know the concepts and i'll be focusing on practise. The example i will provide is a nice way to show it how it could looks like. You can always come back here, take it, adapt it and use it in your applictions as you may need. So be sure you bookmark it or join the group here on the right side of this post subscribing it.

First of all, let's take a look at the UML diagram of it. After that we will take the analogy for our example.

The simpliest UML - Singleton Pattern

Pay close attention, because once you understand that, everything will become clear and simple to understand. That's the reason I'm putting always the UML first. That way you'll get an eye for it with the time.

The Singleton

This is a very common design pattern and largely used with most applications out there. It's important to know this pattern, because you'll see it a lot of times during your programming life. There are, so far as i know, four categories of singletons. Synchronized, not synchronized, lazy, and not lazy initialized. The way you can construct it is largely discussed. You may use an enum or a normal class. In the example bellow i used a normal class.

public final class Session 
{
    private static Session instance;
    /** singleton */
    private Session() {}
    /** if you do not need synchronization do not mark it as synchronized */
    public synchronized static Session getInstance() 
    {
        return (instance == null) ? instance = new Session() : instance;
    }
    /** your methods goes here... */
 }

That's all! Hope you like it!

😱👇 PROMOTIONAL DISCOUNT: BOOKS AND IPODS PRO 😱👇

Be sure to read, it will change your life!

Show your work by Austin Kleon: https://amzn.to/34NVmwx

This book is a must read - it will put you in another level! (Expert)

Agile Software Development, Principles, Patterns, and Practices: https://amzn.to/30WQSm2

Write cleaner code and stand out!

Clean Code - A Handbook of Agile Software Craftsmanship: https://amzn.to/33RvaSv

This book is very practical, straightforward and to the point! Worth every penny!

Kotlin for Android App Development (Developer's Library): https://amzn.to/33VZ6gp

Needless to say, these are top right?

Apple AirPods Pro: https://amzn.to/2GOICxy

😱👆 PROMOTIONAL DISCOUNT: BOOKS AND IPODS PRO 😱👆

Monday, November 4, 2013

How to lock state to synchonize transitions java android

Hi there!
Today i'm gonna share one of many possible ways to acquire a lock with the intent of synchronize transitions or whatever task you may have. I use it to synchronize complex animation transition sequences in Android.

import java.util.HashSet;
import java.util.Set;

/**
 * Use this class to synchronize transitions, animations or whatever you want.

 * It is designed to acquire and release a synchronized lock state, coordinating

 * the access of it in a multi thread environment.
 * 
 * @author Ricardo Ferreira 04/11/2013
 */
public class StateLock {

 private final static StateLock INSTANCE = new StateLock();
 private Set lockSet = new HashSet();
 private boolean lock = false;
 
 private StateLock() {
  // singleton
 }

 /** Synchronized because the lock state should be acquired and released in a controlled way */
 public synchronized static StateLock getInstance() {
  return StateLock.INSTANCE;
 }

 public synchronized boolean isStateLocked() {
  return lock;
 }
 
 public synchronized boolean hasStateAlreadyLocked(String stateSimpleClassName) {
  return lockSet.contains(stateSimpleClassName);
 }

 /** Returns true if the state lock was acquired by the given class, false otherwise */
 public synchronized boolean acquireLockState(String stateSimpleClassName) {
  boolean operationResult = false;
  if (lockSet.isEmpty()) {
   lockSet.add(stateSimpleClassName);
   lock = true;
   operationResult = true;
  }
  return operationResult;
 }

 /** Returns true if the lock was released or no state was locked, false otherwise */
 public synchronized boolean releaseLockState(String stateSimpleClassName) {
  boolean operationResult = false;
  if (lockSet.contains(stateSimpleClassName)) {
   lockSet.clear();
   lock = false;
   operationResult = true;
  } else if (lockSet.isEmpty()) {
   lock = false;
   operationResult = true;
  }
  return operationResult;
 }

 protected Object clone() throws CloneNotSupportedException {
  throw new CloneNotSupportedException();
 }

}

😱👇 PROMOTIONAL DISCOUNT: BOOKS AND IPODS PRO 😱👇

Be sure to read, it will change your life!
Show your work by Austin Kleon: https://amzn.to/34NVmwx

This book is a must read - it will put you in another level! (Expert)
Agile Software Development, Principles, Patterns, and Practices: https://amzn.to/30WQSm2

Write cleaner code and stand out!
Clean Code - A Handbook of Agile Software Craftsmanship: https://amzn.to/33RvaSv

This book is very practical, straightforward and to the point! Worth every penny!
Kotlin for Android App Development (Developer's Library): https://amzn.to/33VZ6gp

Needless to say, these are top right?
Apple AirPods Pro: https://amzn.to/2GOICxy

😱👆 PROMOTIONAL DISCOUNT: BOOKS AND IPODS PRO 😱👆

Monday, March 5, 2012

How to write a singleton? (pros and contras)

A singleton for each situation and the pros and contras of it?

Lazy synchronized initialization

public final class Session 
  {
      private static Session instance;
 
      /** singleton */
      private Session() {}
 
      /** if you do not need synchronisation do not mark it as synchronized */
      public synchronized static Session getInstance() 
      {
          return (instance == null) ? instance = new Session() : instance;
      }
      /** your methods goes here... */
   }

PRO: can be initialized lazy the first time it is used
CONTRA: Singletons shall be avoid because they are hard to test and debug. Futher they contribute to less cohesive designs.

No Lazy initialization needed

public class Session 
  {
    private final static Session INSTANCE = new Session();

    private Session() {}

    public static Session getInstance() 
    { 
      return Session.INSTANCE; 
    }

    protected Object clone() 
    {
      throw new CloneNotSupportedException();
    }

    /** your methods goes here... */
  }

PRO: Immediate allocation of the needed resource
CONTRA: Needs "more" resource as nescessary + CONTRA from first case

No Lazy initialization needed (the elegant, modern way)

public enum Session 
   {
       INSTANCE;
       private int session;

       public int getSession() {
           return ++session;
       }

       /** your methods goes here... */
   }

PRO: Very simple, modern way. Immediate allocation of the needed resource
CONTRA: Needs "more" resource as nescessary + CONTRA from first case

2GOICxy

😱👆 PROMOTIONAL DISCOUNT: BOOKS AND IPODS PRO 😱👆

Friday, February 3, 2012

How to use the "Builder Pattern" in factories?

Using the "Builder Pattern" in Factories making your classes testable

Hi there! In this blog i want show to you how we can combine the builder pattern with the factory pattern making our classes testable.

Common Problem

In many cases we have (must) separate Domain Objects (DOs) from the objects we use to visualize something in der GUI. For this reason we create in most of the cases Domain Transfer Objects (DTO's) which hold the values from the DO's in it. With a DTO Factory we would be able to create and fill up all attributes of it with default values. This is a good practise because this way we can use the factory to create DTO's also while testing it. That's when the builder pattern comes in. Combining the builder pattern with the factory pattern allow us to create default DTO's as well specific DTO's. Important: If you don't know when the usage of DTO's is appropriate, then you may read this post first: "When do we use DTO's"

UML of the example:

Example Address

Let's say we have the domain object (class) called Address that looks like this:

// Domain Object
public class Address {

    // only a few attributes to show the idea behind it
    private String street;
    private String land;

    public String getStreet() {
        return this.street;
    }

    public void setStreet(String street) {
        this.street = street;
    }

    public String getLand() {
        return this.land;
    }

    public void setLand(String land) {
        this.land = land;
    }

}

The DTO could look like this:

public class AddressDTO {

    private Address address;

    public AddressDTO() {
        this.address = new Address();
    }

    public Address getAddress() {
        return this.address;
    }

    public void setAddressDTO(Address address) {
        this.address = address;
    }
}

Then we would also need a mapper. It could look like this:

public class AddressMapper {

    Address domainAddress;
    AddressDTO addressDTO;

    public AddressMapper(Address domainAddress, AddressDTO addressDTO) {
        this.domainAddress = domainAddress;
        this.addressDTO = addressDTO;
    }

    public AddressDTO mapDomainToDto() {
        this.addressDTO.getAddress().setLand(this.domainAddress.getLand());
        this.addressDTO.getAddress().setStreet(this.domainAddress.getStreet());
        return this.addressDTO;
    }

    public Address mapDtoToDomain() {
        this.domainAddress.setLand(this.addressDTO.getAddress().getLand());
        this.domainAddress.setStreet(this.addressDTO.getAddress().getStreet());
        return this.domainAddress;
    }
}

The factory could be implemented like this:

public class AddressDTOFactory {

    private AddressDTO addressDTO;
    private boolean instanceObserver;
    private static AddressDTOFactory factory;

    // factory pattern knows how to create the DTO
    private AddressDTOFactory() {
        super();
        this.instanceObserver = true;
        this.addressDTO = create();
    }

    // singleton pattern instantiates the factory
    public static AddressDTOFactory getInstance() {
        return (factory == null) ? (factory = new AddressDTOFactory()) : factory;
    }

    // public mock values for testing purposes
    public static String DEFAULT_STREET = "MyStreet";
    public static String DEFAULT_LAND = "USA";

    // builder pattern can be used to mock tests
    public AddressDTOFactory street(String street) {
        createNewObjectIfNotObserved();
        this.addressDTO.getAddress().setStreet(street);
        return factory;
    }

    public AddressDTOFactory land(String land) {
        createNewObjectIfNotObserved();
        this.addressDTO.getAddress().setLand(land);
        return factory;
    }

    public AddressDTOFactory defaultFilling() {
        createNewObjectIfNotObserved();
        this.addressDTO.getAddress().setLand(DEFAULT_LAND);
        this.addressDTO.getAddress().setStreet(DEFAULT_STREET);
        return factory;
    }

    public AddressDTOFactory fillMandatoryFields() {
        createNewObjectIfNotObserved();
        // let's assume that land is a mandatory field in GUI and database
        this.addressDTO.getAddress().setLand(DEFAULT_LAND);
        return factory;
    }

    public AddressDTO getObject() {
        if (this.instanceObserver) {
            this.instanceObserver = false;
        } else {
            this.addressDTO = create();
        }
        return this.addressDTO;
    }

    // ensure right instance
    private void createNewObjectIfNotObserved() {
        if (!this.instanceObserver) {
            this.instanceObserver = true;
            this.addressDTO = create();
        }
    }

    private AddressDTO create() {
        return new AddressMapper(new Address(), new AddressDTO()).mapDomainToDto();
    }

}

Now we have a testable AddressDTO with deterministic character that can be reused for several tests according to your needs. The test could look like this:

import junit.framework.Assert;
import org.junit.Before;
import org.junit.Test;

public class AddressDTOFactoryTest {

    AddressDTO defaultAddressDTO;
    AddressDTO mandatoryAddressDTO;
    AddressDTO emptyAddressDTO;
    AddressDTO customizedAddressDTO;
    AddressDTO totallyEmptyAddressDTO;

    public AddressDTOFactoryTest() {
        super();
    }

    @Before
    public void setUp() throws Exception {
        AddressDTOFactory factory = AddressDTOFactory.getInstance();
        this.defaultAddressDTO = factory.defaultFilling().getObject();
        this.mandatoryAddressDTO = factory.fillMandatoryFields().getObject();
        this.emptyAddressDTO = factory.getObject();
        this.customizedAddressDTO = factory.street("Av. Copacabana").land("Brazil").getObject();
        this.totallyEmptyAddressDTO = factory.getObject();
    }

    @Test
    public void testDefaultAddressDTO() {
        Assert.assertEquals(AddressDTOFactory.DEFAULT_LAND, this.defaultAddressDTO.getAddress().getLand());
        Assert.assertEquals(AddressDTOFactory.DEFAULT_STREET, this.defaultAddressDTO.getAddress().getStreet());
    }

    @Test
    public void testMandatoryAddressDTO() {
        String empty = null;
        Assert.assertEquals(AddressDTOFactory.DEFAULT_LAND, this.mandatoryAddressDTO.getAddress().getLand());
        Assert.assertEquals(empty, this.mandatoryAddressDTO.getAddress().getStreet());
    }

    @Test
    public void testEmptyAddressDTO() {
        String empty = null;
        Assert.assertEquals(empty, this.emptyAddressDTO.getAddress().getLand());
        Assert.assertEquals(empty, this.emptyAddressDTO.getAddress().getStreet());
    }

    @Test
    public void testCustomizedAddressDTO() {
        Assert.assertEquals("Brazil", this.customizedAddressDTO.getAddress().getLand());
        Assert.assertEquals("Av. Copacabana", this.customizedAddressDTO.getAddress().getStreet());
    }

    @Test
    public void testTotallyEmptyAddressDTO() {
        String empty = null;
        Assert.assertEquals(empty, this.totallyEmptyAddressDTO.getAddress().getLand());
        Assert.assertEquals(empty, this.totallyEmptyAddressDTO.getAddress().getStreet());
    }

}

Conclusion

A simple re-adjust or a little more class design can save you a lot of unnecessary, duplicated code and time. It makes the maintenance easier. Think always about how to test it while writing new classes. JUnit tests can be written faster and more consistent. This simple example is a very simplified class. In the real life an Address class is much bigger with a lot more attributes used inside.