How to eliminate If-Statements and InstanceOf with the Visitor-Pattern

Using the visitor pattern to eliminate If-Statements and InstanceOf


We all know the visitor pattern from the book GoF (gang of four) or from other famous books. The examples in there are usually associated with trees or composite structures. I was always searching for real life examples, where this pattern could be used, making software reusable and more readable. During a refactoring task, a collegue of mine had a really good idea, that i want to share with you.


Here is the code fragment from the method we want to refactore. The method has a lot of if-statements and instanceOf in there. It maps contacts to data transfer objects (DTO)

public static void mapKontakte(ContactType contactType, List<ErweiterteKontakt<? extends StringDomainEnum>> kontakte) {
        ch.abraxas.tax.register.registerimport.parser.ech0046.v10.ObjectFactory ech0046Factory =
                new ch.abraxas.tax.register.registerimport.parser.ech0046.v10.ObjectFactory();
        for (ErweiterteKontakt<? extends StringDomainEnum> kontakt : kontakte) {
            if (kontakt instanceof Telefon) {
                PhoneType phoneType = ech0046Factory.createPhoneType();
                phoneType.setPhoneCategory(new BigInteger( ((Telefon) kontakt).getKategorie().key()));
                phoneType.setPhoneNumber(kontakt.getDetail());
                contactType.getPhone().add(phoneType);
            } else if (kontakt instanceof Email) {
                EmailType emailType = ech0046Factory.createEmailType();
                emailType.setEmailCategory(new BigInteger( ((Email) kontakt).getKategorie().key()));
                emailType.setEmailAddress(kontakt.getDetail());
                contactType.getEmail().add(emailType);
            } else if (kontakt instanceof Internet) {
                InternetType internetType = ech0046Factory.createInternetType();
                internetType.setInternetCategory(new BigInteger( ((Internet) kontakt).getKategorie().key()));
                internetType.setInternetAddress(kontakt.getDetail());
                contactType.getInternet().add(internetType);
            }
            // Should we use an else branch to verify that we are mapping all Kontakte?
        }
    }

here is the same method after refactoring:

public static void mapKontakte(ContactType contactType,
   List<ErweiterteKontakt<? extends StringDomainEnum>> kontakte) {

  ErweiterterKontaktVisitor visitor = new BindingObjectFromKontaktVisitor(contactType);
  for (ErweiterteKontakt<? extends StringDomainEnum> kontakt : kontakte) {
   // calls the Kontakt to use the visitor
   kontakt.accept(visitor);
  }
 }

Well here is how to do it. In the abstract class ErweiterteKontakt we define following method:

public abstract void accept(ErweiterterKontaktVisitor visitor);

Then we implement this abstract method in the classes Email, Telefon and Internet. They all extends ErweiterkeKontakt.

 @Override
 public void accept(ErweiterterKontaktVisitor visitor) {
  visitor.visit(this);
 }

Defining the visitor interface

public interface ErweiterterKontaktVisitor {

 /**
  * Visit the telefon
  * 
  * @param telefon
  */
 public void visit(Telefon telefon);

 /**
  * visit the email
  * 
  * @param email
  */
 public void visit(Email email);

 /**
  * visit the internet
  * 
  * @param internet
  */
 public void visit(Internet internet);
}

Then Implementing the Visitor itself:

public class BindingObjectFromKontaktVisitor implements ErweiterterKontaktVisitor {

 private ch.abraxas.tax.register.registerimport.parser.ech0046.v10.ObjectFactory ech0046Factory = new ch.abraxas.tax.register.registerimport.parser.ech0046.v10.ObjectFactory();

 private ContactType contactType;

 /**
  * Konstruktor
  */
 public BindingObjectFromKontaktVisitor(ContactType contactType) {
  this.contactType = contactType;
 }

 /**
  * {@inheritDoc}
  */
 @Override
 public void visit(Telefon telefon) {
  PhoneType phoneType = ech0046Factory.createPhoneType();
  phoneType.setPhoneCategory(new BigInteger(telefon.getKategorie().key()));
  phoneType.setPhoneNumber(telefon.getDetail());
  contactType.getPhone().add(phoneType);
 }

 /**
  * {@inheritDoc}
  */
 @Override
 public void visit(Email email) {
  EmailType emailType = ech0046Factory.createEmailType();
  emailType.setEmailCategory(new BigInteger(email.getKategorie().key()));
  emailType.setEmailAddress(email.getDetail());
  contactType.getEmail().add(emailType);

 }

 /**
  * {@inheritDoc}
  */
 @Override
 public void visit(Internet internet) {
  InternetType internetType = ech0046Factory.createInternetType();
  internetType.setInternetCategory(new BigInteger((internet).getKategorie().key()));
  internetType.setInternetAddress(internet.getDetail());
  contactType.getInternet().add(internetType);

 }
}

Done!
No more If-Statements, no more InstanceOf and the code is now extandable and more flexible.

😱👇 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 😱👆

When do we need DataTransferObjects - DTOs (indicators)

Indicators for DTOs (Data Transfer Objects)


DTO should be used with care. Generally we decide case by case, whether we shall introduce DTO layers which generates more complexity, or whether we work directly with the domain objects (DOs). The list below will assist us by our decission.


When can i use DomainObjects(DOs) direct to visualize details in the GUI?


Case 1: 
you can do it (and shall do it) by readonly views and if the domain object doesn't need to go back to the database. During this process the client may change values of the domain object if necessary. The only condition: The domain object is not returned to the database.


Case 2: 
If other software parts use the same service needing the whole content of a domain object. In this case you may get and use the whole domain object. But if you wanna change some values of it and store it back into the database, then you'll need new objects called: prefixDTOData. why that? Because otherwise we would force the service which writes the attributes into database to iterate over the whole domain object looking and comparing for changes before writing down in the database. 


When shall i better use DTOs? 


Case 1:
Use DTO's if the domain object is huge, but you just need a few attributes of it! For large domain objects, in which the client visualize, change or display only a few of its attributes. In this case we recommend to use the notation: prefixDTO. This is the object which the client uses to do its works. The service gets the Domain Object, creates the DTO and gives it back. If this DTO is used in a wizard or kind of formular in which the user may type something in setting values, which means that you have to store the typed information into database, then you should use in addtion to the DTOs new objects called: prefixDTOData. why that? Because otherwise we would force the service which writes the attributes into database to iterate over the whole domain object (remember that the domain object is huge) looking and comparing for changes before writing down in the database.


Case 2:
Use DTOs if the client has to show fields from different domain objects. In this special case you may consider putting all the needed attributes together already in the database creating the DTO in the server which is passed to the service going to the client. The client creates analoque to Case 1 a prefixDTOData an gives it back to the service. the reasons are the same as in explained in Case 1.


What are the disadvantages of DTOs?

You have/create additional complexities, which means that if things has to be changed, you have to make the changes everywhere in your code.

😱👇 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 😱👆

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. 

😱👇 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 😱👆