Yavuz Tas

Consuming Variable Responses in Jackson

Tue, 10 Dec 2019 22:00:00 +0000

In addition to being another popular library of JSON in Java, the Jackson Library is very well known for its ability to offer deep customization in an opinionated way.

In this article, we are going to show an alternate way with the Jackson Library for the same solution which was about how to handle variable responses in Gson.

Adding Dependencies

Before we start, we need to add the Maven dependencies into our project’s pom.xml:

<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-core</artifactId>
    <version>2.9.9</version>
</dependency>

<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <version>2.9.9</version>
</dependency>

We should note that if we already use Spring Boot and Spring Web Starter module enabled in our project then simply, we don’t need to add any extra dependency for Jackson.

Sample Response

Let’s use the sample API response:

{
    "id": 1,
    "name": "sample article",
    "comments": [
        {"id":1, "text":"some comment text"},
        {"id":2, "text":"some another comment text"}
    ]
}

Also, the response changes from Array to Object notation when there is only a single comment:

{
    "id": 1,
    "name": "sample article",
    "comments": {"id":1, "text":"some comment text"}
}

Response Models

We’ll also use the same models from the previous article:

public class ArticleModel {

    private Long id;

    private String name;

    private List<CommentModel> comments;

    // standard getters and setters

}

public class CommentModel {

    private Long id;

    private String text;

    // standard getters and setters

}

Consuming the Response

We defined a collection type for the comment field as List<CommentModel>. Thus, we can map multiple comments into a single field automatically because Jackson already does the heavy lifting for us:

String jsonString = "{
    "id": 1,
    "name": "sample article",
    "comments": [
        {"id":1, "text":"some comment text"},
        {"id":2, "text":"some another comment text"}
    ]
}";

ObjectMapper mapper = new ObjectMapper();
ArticleModel model = mapper.readValue(this.mockResponseMultiValue, ArticleModel.class);

Assert.assertEquals(ArticleModel.class, model.getClass());
Assert.assertEquals(model.getComments().getClass(), CommentList.class);
Assert.assertEquals(model.getComments().get(0).getClass(), CommentModel.class);

Assert.assertEquals(1, model.getId().longValue());
Assert.assertEquals("sample article", model.getName());

Assert.assertEquals(2, model.getComments().size());
Assert.assertEquals(1, model.getComments().get(0).getId().longValue());
Assert.assertEquals("some comment text", model.getComments().get(0).getText());
Assert.assertEquals(2, model.getComments().get(1).getId().longValue());
Assert.assertEquals("some another comment text", model.getComments().get(1).getText());

Certainly, this configuration resolves the multiple comment values unless the response changes to a single value structure. Otherwise, it simply doesn’t work.

Consequently, we need to define a custom deserializer to handle both single and multiple values at once.

Custom Deserializers for Jackson

StdDeserializer is an abstract type and also the base class for common deserializers in Jackson.

Therefore, to implement a custom deserialization behavior, we will create an implementation of StdDeserializer. This behavior will be responsible for adding any single value to the list as the same as multiple values are being added automatically by Jackson.

So, let’s create CommentListDeserializer which inherits the base class StdDeserializer:

public class CommentListDeserializer extends StdDeserializer<List> {

    public CommentListDeserializer() {
        this(null);
    }

    private CommentListDeserializer(JavaType valueType) {
        super(valueType);
    }

    @Override
    public List deserialize(JsonParser p, DeserializationContext ctxt)
      throws IOException, JsonProcessingException {

        return null;
    }

}

We need a TypeReference for Jackson to specify the Collection type and the type of elements in which are involved as well.

So, let’s define a constant for a type of List<CommentModel>:

private static final TypeReference<List<CommentModel>> LIST_OF_COMMENTS_TYPE =
  new TypeReference<List<CommentModel>>() {};

Next, we implement the deserialize method to come up with the expected behavior:

@Override
public List deserialize(JsonParser p, DeserializationContext ctxt)
  throws IOException, JsonProcessingException {

    List<CommentModel> commentList = new ArrayList<>();

    JsonToken token = p.currentToken();

    if (JsonToken.START_ARRAY.equals(token)) {
        List<CommentModel> listOfArticles = p.readValueAs(LIST_OF_COMMENTS_TYPE);
        commentList.addAll(listOfArticles);
    }

    if (JsonToken.START_OBJECT.equals(token)) {
        CommentModel article = p.readValueAs(CommentModel.class);
        commentList.add(article);
    }

    return commentList;
}

Deserialization Features in Jackson

Although writing a custom deserializer offers us great flexibility, there are lots of features bundled in the Jackson Library for conversions. Jackson predefined features provide practical ways to customize both serialization and deserialization.

Hopefully, ACCEPT_SINGLE_VALUE_AS_ARRAY feature does the exact job for our use-case. Certainly, we could use it for the sake of simplicity:

ObjectMapper mapper = new ObjectMapper();
mapper.enable(DeserializationFeature.ACCEPT_SINGLE_VALUE_AS_ARRAY);

Also, an alternate way is to configure the @JsonFormat annotation. In our example, we’ll go with the @JsonFormat annotation to set the ACCEPT_SINGLE_VALUE_AS_ARRAY feature.

Let’s remove our custom deserializer and add a simple @JsonFormat annotation to our comments field in ArticleModel:

@JsonFormat(with = Feature.ACCEPT_SINGLE_VALUE_AS_ARRAY)
private List<CommentModel> comments;

Thus, this will automatically add any single value of CommentModel to our list as if it were already inside an array. Unless we have any further requirement using Jackson features can be the most elegant solution for our use-case.

We can always have a chance to check the full list of features over on the source code.

Going Further with Generic Deserializers

We can write generic deserializers for different requirements that we couldn’t handle by predefined features. Besides, for the benefit of reusability, we can go further to refactor our code not to create new deserializers for each element type.

So, we’ll implement a new class as SingleAwareListDeserializer to handle the deserialization in a more customizable way:

public class SingleAwareListDeserializer extends StdDeserializer<List>
  implements ContextualDeserializer {

    private Class<?> contentClassType;

    public SingleAwareListDeserializer() {
        this(null);
    }

    private SingleAwareListDeserializer(JavaType valueType) {
        super(valueType);
    }

    @Override
    public JsonDeserializer<?> createContextual(
      DeserializationContext ctxt, BeanProperty property) throws JsonMappingException {
        // we use ContextualDeserializer to obtain content class type
        contentClassType = property.getType().getContentType().getRawClass();
        return this;
    }

    @Override
    public List deserialize(JsonParser p, DeserializationContext ctxt)
      throws IOException, JsonProcessingException {

        List list = new ArrayList<>();

        JsonToken token = p.currentToken();
        // if token is array type
        // then perform object deserialization to each element element
        if (JsonToken.START_ARRAY.equals(token)) {
            while (p.nextToken() != null) {
                if (JsonToken.START_OBJECT.equals(p.currentToken())) {
                    list.add(deserializeObject(p));
                }
            }
        }

        // if token is object type
        if (JsonToken.START_OBJECT.equals(token)) {
            list.add(deserializeObject(p));
        }

        return list;
    }

    private Object deserializeObject(JsonParser p) throws IOException {
        // just use jackson default object deserializer by using element type
        return p.readValueAs(contentClassType);
    }

}

Now, we can use the same deserializer for different types as well.

Certainly, we should notice the challenge here which is about how to obtain the class type of the element inside our collection. Without the element’s type information, it is not possible for Jackson to initialize the concrete type but only LinkedHashMap.

However, there is a workaround to obtain type-related information inside our deserializer.

We used the ContextualDeserializer interface to inform Jackson that we need information about the bean we are dealing with. Thus, an instance of BeanProperty is automatically injected and we obtained the class type of the collection element.

Finally, to use our generic deserializer, let’s change our comments field:

@JsonDeserialize(using = SingleAwareListDeserializer.class)
private List<CommentModel> comments;

As a result, we can provide the same behavior by the SingleAwareListDeserializer generically for all types as well.

Finally

In this tutorial, we learned how to handle variable responses in Jackson by using the builtin features and custom deserializers as well.

All the source code for the examples shown in this tutorial are available over on GitHub.

Type Based Global Events in Vue.js

Sun, 10 Nov 2019 22:30:00 +0000

In one of the latest freelance projects of mine, my client prefers Vue Framework which is recently super popular on the frontend side.

So, I dived into Vue. I can say that it is very practical and effective on the very first sight.

Besides, when we compare it with other predominant competitors like Angular and Aurelia, we can easily notice Vue has a very slight learning curve.

However, it didn’t take so long for me to stumble on a bad feeling that my code is getting unmanageable and becoming unable to be followed.

Undoubtfully, it wasn’t a big surprise to me because this is mostly what dynamic-typed languages make us resent the harsh trade-off along with their super cool advantages.

Today, I am going to show a practical and effective way of using global events in Vue Framework.

A Simple Event Bus in Vue

The typical way of implementing a global event bus in Vue is just using the Vue object itself:

// create a Vue instance somewhere you can access globally
let eventBus = new Vue()

// register an event handler
eventBus.$on("onAppStarted", () => console.log("App Started!"))

// publish an event
eventBus.$emit("onAppStarted")

// Super easy, right?

The Problem Coming From Strings

As long as our application has more than a couple of lines, sooner or later, we start stressing to follow which components publish and which others listen to them.

Therefore, we can imagine how hard to identify a simple typo like onApStarted instead of onAppStarted as an event name in a large project:

eventBus.$on("onApStarted", () => {
  // some business logic here  
})

Implicit Event Parameters

Moreover, because we don’t define any corresponding type or interface for our event parameters only God knows what and how many parameters might be for the onAppStarted event.

In order to identify we resent doing this kind of tests everytime we confuse:

eventBus.$on("onAppStarted", (...args) => {
  args.forEach(e => console.log(e))    
})

A Proper Solution Comes From ES6+

As being a fan of static-typed Java world, whatever language I do, I prefer using types clearly unless it’s super unconventional for the specific language.

Thus, I will show a solution to get rid of these string-based event names by using the capabilities ECMAScript 6 and later offers.

Defining Event Types

Let’s create a separate file called app-events.js to define our event types:

/**
* Event type to publish when app loads
* ProducedBy: components/preload.js
* ConsumedBy: App.vue, views/MainPanel.vue
**/
export class AppStartEvent {

  constructor(){
    // An event type with no arguments
  }

}

/**
* Event type to publish when code changes
* ProducedBy: views/CodePanel.vue
* ConsumedBy: views/MainPanel.vue
* @param {object} editor   editor instance
* @param {string} code     changed code value inside the editor
**/
export class CodeChangeEvent {

  constructor(editor, code){
    this.editor = editor
    this.code = code
  }

}

As we can notice, defining event type classes and parameters in constructor explicitly offers us great readability.

Although it is optional, we recommend keeping comments updated. This provides a way to follow the components which deal with a certain event type.

Importing Event Types

When we want to use our events, we should import them into our components:

import {AppStartEvent, CodeChangeEvent} from "@/app-events"

As we specify explicitly every event type we need, it brings us another important benefit that we can easily identify what events are involved in a component.

Registering an Event

In order to register our event, simply we use our event types and their static name properties:

import {AppStartEvent} from "@/app-events"

eventBus.$on(AppStartEvent.name, () => console.log("App Started!"))

Plus, we can expect the event type instance itself as a single argument instead of more than one arguments:

import {AppStartEvent, CodeChangeEvent} from "@/app-events"

// we can access the event type instance as a single argument
eventBus.$on(AppStartEvent.name, event => console.log(event))

// also can access to event parameters
eventBus.$on(CodeChangeEvent.name, event => {
  console.log(event.editor)  
  console.log(event.code)  
})

Publishing an Event

Now we can publish our events by creating a new instance of that event type:

// no parameters
eventBus.$emit(AppStartEvent.name, new AppStartEvent())

// with parameters
eventBus.$emit(CodeChangeEvent.name, new CodeChangeEvent(editor, "some code here..."))

Implementing a Wrapper Class

Certainly, we may proceed to define a class as EventBus and wrap the basic methods of Vue instance.

class EventBus {

  $eventbus = new Vue()

  listen (eventClass, handler) {
    this.$eventBus.$on(eventClass.name, handler)
  }

  publish (event) {
    this.$eventBus.$emit(event.constructor.name, event)
  }

}

Therefore, we can use it in a more practical way:

// register an event handler
EventBus.listen(AppStartEvent, () => console.log("App Started!"))

// publish an event
EventBus.publish(new AppStartEvent())

Using as a Plugin

We may prefer to use our EventBus as a Vue Plugin:

export default {

  $eventBus: null,

  install (Vue, options) {
    this.$eventBus = new Vue()
  },

  listen (eventClass, handler) {
    this.$eventBus.$on(eventClass.name, handler)
  },

  listenOnce (eventClass, handler) {
    this.$eventBus.$once(eventClass.name, handler)
  },

  remove (eventClass, handler) {
    if (handler) {
      this.$eventBus.$off(eventClass.name, handler)
    } else {
      this.$eventBus.$off(eventClass.name)
    }
  },

  removeAll () {
    this.$eventBus.$off()
  },

  publish (event) {
    this.$eventBus.$emit(event.constructor.name, event)
  }

}

In order to use the plugin, we should import and register to our Vue instance:

import EventBus from '@/plugin/vue-event-bus';

Vue.use(EventBus)

Consequently, we can simply import and use in any other Vue component as well:

import EventBus from '@/plugin/vue-event-bus';
import {AppStartEvent} from "@/app-events"

// register an event handler
EventBus.listen(AppStartEvent, () => console.log("App Started!"))

// publish an event
EventBus.publish(new AppStartEvent())

Finally

In this short tutorial, I explained how to implement type-based global events and use them in Vue.js.

You can find the code of the sample plugin over on GitHub.

Consuming Variable Responses in Gson

Sat, 12 Oct 2019 18:30:00 +0000

No matter being public or private, Restful APIs are the most popular way to integrate our applications with the world outside. This means you do not have a chance to alter the services you consume, instead, you should adapt to them most of the time.

Since Java is a static-typed language, it can be a challenge while you are consuming and mapping the data into your model objects, especially if the response data changes depending on the use case.

In this article, we will show how to handle variable response structures with the Gson Library.

Maven Dependency

Before we start, we need to add the Gson dependency into our project’s pom.xml:

<dependency>
    <groupId>com.google.code.gson</groupId>
    <artifactId>gson</artifactId>
    <version>2.8.5</version>
</dependency>

Sample Response

Let’s pick a sample API for a blog which services detailed information about its articles along with the comments which may be more than one:

{
    "id": 1,
    "name": "sample article",
    "comments": [
        {"id":1, "text":"some comment text"},
        {"id":2, "text":"some another comment text"}
    ]
}

However, if there is only one single comment then its structure changes into object hash form:

{
    "id": 1,
    "name": "sample article",
    "comments": {"id":1, "text":"some comment text"}
}

Writing a Response Model

In order to map the data, we need a POJO as a response model. Let’s start by defining a simple class that matches the main response structure:

public class ArticleModel {

    @Expose
    private Long id;

    @Expose
    private String name;

    @Expose
    private List<CommentModel> comments;

    // standard getters and setters

}

And we need to define another class corresponds to comment response structure:

public class CommentModel {

    @Expose
    private Long id;

    @Expose
    private String text;

    // standard getters and setters

}

Consuming the Response

Since we use List<CommentModel> for the comments field, we can easily map multiple values which Gson already does the heavy lifting for us:

String responseText = "{
  "id": 1,
  "name": "sample article",
  "comments": [
    {"id":1, "text":"some comment"},
    {"id":2, "text":"some another comment"}
  ]}";
Gson gson = new Gson();
ArticleModel model = gson.fromJson(responseText, ArticleModel.class);

Assert.assertEquals(1, model.getId().longValue());
Assert.assertEquals("sample article", model.getName());
Assert.assertEquals(2, model.getComments().size());
Assert.assertEquals(1, model.getComments().get(0).getId().longValue());
Assert.assertEquals("some comment", model.getComments().get(0).getText());
Assert.assertEquals(2, model.getComments().get(1).getId().longValue());
Assert.assertEquals("some another comment", model.getComments().get(1).getText());

Although this configuration works for the multiple values of comments, if it changes to a single value then we need to define a custom TypeAdapter in order to handle both single and multiple values.

Custom TypeAdapter in Gson

In order to achieve a custom JSON deserialization behavior, we need to create a TypeAdapter. This behavior will be responsible for adding any single value to the list as the same as multiple values are being added automatically by Gson.

For the beginning, let’s create a Gson TypeAdapter for this purpose:

public class CommentListTypeAdapter extends TypeAdapter<List> {

	@Override
	public void write(JsonWriter out, List list) throws IOException {

	}

	@Override
	public List read(JsonReader in) throws IOException {

		return null;
	}
}

We need to access Gson instance inside our TypeAdapter to preserve and reuse default deserialization behavior for Object and Collection types.

So, let’s define a constructor and fields of Gson instance and some default adapters:

private Gson gson;
private TypeAdapter<CommentModel> objectTypeAdapter;
private TypeAdapter<List<CommentModel>> listTypeAdapter;

public CommentListTypeAdapter(Gson gson) {
    this.gson = gson;
    this.objectTypeAdapter = gson.getAdapter(CommentModel.class);
    this.listTypeAdapter = gson.getAdapter(new TypeToken<List<CommentModel>>() {});
}

Since we aim to deserialize only, we can omit the write method of our adapter. However, we can implement in any case by simply delegating it to the default adapters.

Next, let’s implement write method by using listTypeAdapter:

@Override
public void write(JsonWriter out, List list) throws IOException {

    listTypeAdapter.write(out, list);

}

Then, we implement the read method of our adapter to come up with our expected deserialization behavior:

@Override
public List read(JsonReader in) throws IOException {

	List<CommentModel> deserializedObject = new ArrayList<>();

	// type of next token
	JsonToken peek = in.peek();

	// if the json field is single object just add this object to list as an
	// element
	if (JsonToken.BEGIN_OBJECT.equals(peek)) {
		deserializedObject.add(deserializeObject(in));
	}

	// if the json field is array then implement normal array deserialization
	if (JsonToken.BEGIN_ARRAY.equals(peek)) {
		deserializedObject.addAll(deserializeList(in));
	}

	return deserializedObject;
}

TypeAdapterFactory in Gson

We may consider using TypeAdapterFactory in Gson. There are two benefits of this; one of them is we can implement a generic factory method to create different TypeAdapter classes for different types. The other one is we can access the underlying Gson instance and reuse it which we are primarily looking for now.

So, let’s create a custom TypeAdapterFactory:

public class CommentListTypeAdapterFactory implements TypeAdapterFactory {

	@Override
	public <T> TypeAdapter<T> create(Gson gson, TypeToken<T> type) {

		return (TypeAdapter<T>) new CommentListTypeAdapter(gson);
	}

}

As we can see, we delegated the existing Gson instance to our CommentListTypeAdapter by the help of our custom TypeAdapterFactory.

Registering TypeAdapterFactory into Gson

Finally, we need to register our custom TypeAdapterFactory into the Gson context to make it work.

Let’s update our ArticleModel:

@JsonAdapter(CommentListTypeAdapterFactory.class)
@Expose
private List<CommentModel> comments;

Now we can consume single value structures like multiple values with the same ArticleModel:

String responseText = "{
  "id": 1,
  "name": "sample article",
  "comments": {"id":1, "text":"some comment"}
  }";
Gson gson = new Gson();
ArticleModel model = gson.fromJson(responseText, ArticleModel.class);

Assert.assertEquals(1, model.getId().longValue());
Assert.assertEquals("sample article", model.getName());

Assert.assertEquals(1, model.getComments().size());
Assert.assertEquals(1, model.getComments().get(0).getId().longValue());
Assert.assertEquals("some comment", model.getComments().get(0).getText());

Further Improvements With the Power of Generics

We can go further by refactoring our code with the help of generics and reflection in the benefit of reusability. To prevent creating a new adapter for each type it might be essential to follow this method on some occasions.

Similarly, we implement another TypeAdapter because we need to handle it in a generic way:

public class SingleAwareListTypeAdapter extends TypeAdapter<List> {

	private Gson gson;
	private TypeAdapter<?> objectTypeAdapter;
	private TypeAdapter<List> listTypeAdapter;

	public SingleAwareListTypeAdapter(Gson gson, Class elementClassType) {

		this.gson = gson;
		// we need to carry element's type by passing the element class type to object
		// type adapter otherwise gson deserialize our objects as LinkedTreeSet which we
		// do not expect that.
		this.objectTypeAdapter = gson.getAdapter(elementClassType);
		// list adapter for only serializing do not need the type of element inside list
		// here since all the output will be String at the end.
		this.listTypeAdapter = gson.getAdapter(List.class);
	}

	@Override
	public void write(JsonWriter out, List list) throws IOException {

		// Since we do not serialize our comment list with gson we can omit this part
		// but anyway we can simply implement by reusing gson list type adapter
		listTypeAdapter.write(out, list);
	}

	@Override
	public List read(JsonReader in) throws IOException {

		List deserializedObject = new ArrayList<>();

		// type of next token
		JsonToken peek = in.peek();

		// if the json field is single object just add this object to list as an
		// element
		if (JsonToken.BEGIN_OBJECT.equals(peek)) {
			deserializedObject.add(deserializeObject(in));
		}

		// if the json field is array then deserialize the objects inside
		if (JsonToken.BEGIN_ARRAY.equals(peek)) {
			in.beginArray();
			while (in.hasNext()) {
				if (JsonToken.BEGIN_OBJECT.equals(in.peek())) {
					deserializedObject.add(deserializeObject(in));
				}
			}
			in.endArray();
		}

		return deserializedObject;
	}

	private Object deserializeObject(JsonReader in) throws IOException {
		// just use gson object type adapter
		return objectTypeAdapter.read(in);
	}
}

Thus, we can use the same adapter for different element types when we need the same behavior.

We should also create another TypeAdapterFactory implementation which will use our new generic SingleAwareListTypeAdapter:

public class SingleAwareListTypeAdapterFactory implements TypeAdapterFactory {

	@Override
	public <T> TypeAdapter<T> create(Gson gson, TypeToken<T> type) {

		// proceed only if the incoming type is a parameterized type
		if (!ParameterizedType.class.isInstance(type.getType())) {
			return null;
		}

		ParameterizedType parameterizedType = ParameterizedType.class.cast(type.getType());
		Type elementType = parameterizedType.getActualTypeArguments()[0];
		Class rawElementType = Class.class.cast(elementType);

		return (TypeAdapter<T>) new SingleAwareListTypeAdapter(gson, rawElementType);
	}

}

It is important to let the Gson know the list element’s type information in runtime otherwise our models are deserialized as LinkedTreeSet by default.

Since we need the runtime class of incoming list elements, first we obtained the ParameterizedType, then the runtime Class type of the element inside the Collection.

In this way, we passed the type information of the element into the SingleAwareListTypeAdapter as a parameter in the constructor.

Finally, let’s change our ArticleModel to use our new generic adapter factory:

@JsonAdapter(SingleAwareListTypeAdapterFactory.class)
@Expose
private List<CommentModel> comments;

As a result, with the help of generics and reflection, we can use the same adapter, SingleAwareListTypeAdapterFactory, for the other properties with different element types as well.

Consequently, this will provide an effective way of reusability and lead us to our goal.

Conclusion

In this tutorial, we learned how to implement custom adapters to handle variable responses in Gson.

All the source code of examples shown in this tutorial are available over on GitHub.

ApplicationContext in Spring Framework

Mon, 26 Aug 2019 15:15:00 +0000

Overview

This is the third article of the series Spring Framework Fundamentals.

When we deal with the business requirements in enterprise world, IoC containers can be a life saver in software development. They provide us a frictionless orchestration for our application components by default.

However, most of the time developers need more than just containers. Separating property sources and configuration files, application-wide event publishing mechanisms, loosely coupled pre/post processors and many more can be a grind of our daily work unless we choose a modern application framework to properly delegate this heavy lifting.

Hopefully, today’s IoC containers in most of the modern frameworks bring us the remedy for many enterprise-level requirements.

In this article, we are going to explain ApplicationContext in Spring Framework.

What is meant by ApplicationContext?

ApplicationContext is a central Spring container that provides many ready to use business features for enterprise-level applications.

The basic service of ApplicationContext is exposing another container BeanFactory, which are managing the lifecycle of a Spring Bean such as creating, wiring, assembling and accessing them up to their destruction.

ApplicationContext is a higher-level container than BeanFactory, already contains its features by implementing the various BeanFactory interfaces.

Beyond these bean-related abilities, ApplicationContext provides more features like;

Providing application level configurations
Reading textual messages from convenient MessageSource properties
Publishing application events
Providing automatic pre/post processor registrations like BeanPostProcessor and BeanFactoryPostProcessor.

On some occasions, like mobile environments where you have limited memory resources and performance requirements, you may consider using BeanFactory instead of ApplicationContext. However, the latter is more appropriate and we prefer for server-based applications in most cases.

You can check the description over on spring java doc for more details.

Creating an ApplicationContext

Spring Framework has many special ApplicationContext implementations for different needs but creating a new ApplicationContext is as simple as initializing just a simple java class.

Let’s give an example of creating a FileSystemXmlApplicationContext instance:

FileSystemXmlApplicationContext appContext = new FileSystemXmlApplicationContext(
  "src/main/resources/beans.xml");

SampleBean sampleBean = appContext.getBean("sampleBean", SampleBean.class);
sampleBean.saySomething("Hello World!");

Also, there are different ApplicationContext implementations like:

ClassPathXmlApplicationContext appContext = new ClassPathXmlApplicationContext(
  "beans.xml");

SampleBean sampleBean = appContext.getBean("sampleBean", SampleBean.class);
sampleBean.saySomething("Hello World!");

And this is the XML file for our configuration:

<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
      http://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean id="sampleBean" class="dev.yavuztas.spring.context.SampleBean">
        <property name="message" value="Initial value" />
    </bean>

</beans>

Lifecycle of a Spring Bean in an ApplicationContext

Spring beans are managed and orchestrated by the IoC container BeanFactory which is already available in ApplicationContext. There are many stages for a spring bean from creation to destruction when we go through deep.

However, we keep it simple by grouping into 5 sections.

These sections are;

Aware interfaces for injecting infrastructure components
@PostConstruct and @PreDestroy annotations
InitializingBean and DisposableBean for callback execution
init-method and destroy-method configurations
BeanPostProcessor for altering beans before or after initialization

After constructor execution and setting properties, first of all Aware interfaces come into play like BeanNameAware, BeanFactoryAware.

Let’s give an example of how to use these Aware interfaces:

public class SampleBean implements BeanNameAware, BeanFactoryAware {

    private String message;

    @Override
    public void setBeanName(String name) {

        System.out.println("--- setBeanName executed ---");

    }

    @Override
    public void setBeanFactory(BeanFactory beanFactory) throws BeansException {

        System.out.println("--- setBeanFactory executed ---");

    }

    // getters and setters

}

When we initialize the spring context we will see that setBeanName method executed before the setBeanFactory method. This indicates that there is also an execution order between Aware interfaces. For more details and a full list of them, you may check over on spring docs

For the second step, the bean methods which are marked by @PostConstruct annotation are executed.

Let’s define another method for our bean configured as @PostConstruct:

@PostConstruct
public void postConstruct() {

    System.out.println("--- @PostConstruct executed ---");

}

To make @PostConstruct and @PreDestroy annotations work, we need to define CommonAnnotationBeanPostProcessor as registered in our spring configuration.

<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
      http://www.springframework.org/schema/beans/spring-beans.xsd">

    <bean
      class="org.springframework.context.annotation.CommonAnnotationBeanPostProcessor" />

    <bean id="sampleBean" class="dev.yavuztas.spring.context.SampleBean">
        <property name="message" value="Initial value" />
    </bean>

</beans>

Another way to make it out is configuring <context:annotation-config/> either in XML or Java configuration.

As for the third step, InitializingBean interface comes in with its single afterPropertiesSet callback function.

Let’s make our bean to implement InitializingBean:

public class SampleBean implements BeanNameAware, BeanFactoryAware, InitializingBean {

    // rest of the class omitted

    @Override
    public void afterPropertiesSet() throws Exception {

        System.out.println("--- afterPropertiesSet executed ---");

    }

}

As the step four, init-method configuration shows up. We can define any method and mark it in our bean configuration.

Let’s create another method for our bean:

public void initMethod() {

    System.out.println("--- init-method executed ---");

}

And mark it as init-method:

<bean id="sampleBean" init-method="initMethod"
  class="dev.yavuztas.spring.context.SampleBean">
    <property name="message" value="Initial value" />
</bean>

As for the last step, we can define a BeanPostProcessor to run a custom operation before a spring bean initializes or after. We should pay attention that BeanPostProcessor classes are executed for every bean defined in our spring context.

Let’s create a BeanPostProcessor:

public class CustomBeanPostProcessor implements BeanPostProcessor {

    @Override
    public Object postProcessBeforeInitialization(Object bean, String beanName)
      throws BeansException {

        System.out.println("--- postProcessBeforeInitialization executed ---");

        return BeanPostProcessor.super.postProcessBeforeInitialization(bean, beanName);
    }

    @Override
    public Object postProcessAfterInitialization(Object bean, String beanName)
      throws BeansException {

        System.out.println("--- postProcessAfterInitialization executed ---");

        return BeanPostProcessor.super.postProcessAfterInitialization(bean, beanName);
    }

}

Of course, we need to register our new post-processor as a spring bean to make it work:

<bean class="dev.yavuztas.spring.context.CustomBeanPostProcessor" />

When we boot our spring context, we will see that our CustomBeanPostProcessor’s postProcessBeforeInitialization method is executed right before the @PostConstruct and the other method postProcessAfterInitialization is executed after init-method.

For the destruction stage of spring beans, we can also configure @PreDestroy, DisposableBean and destroy-method.

Let’s define these methods for our bean:

public class SampleBean implements
  BeanNameAware, BeanFactoryAware, InitializingBean, DisposableBean {

    // rest of the class omitted

    @PreDestroy
    public void preDestroy() {

        System.out.println("--- @PreDestroy executed ---");

    }

    @Override
    public void destroy() throws Exception {

        System.out.println("--- destroy executed ---");

    }

    public void destroyMethod() {

        System.out.println("--- destroy-method executed ---");

    }

}

And do not forget to configure destroy-method in our bean config:

<bean id="sampleBean" init-method="initMethod" destroy-method="destroyMethod"
  class="dev.yavuztas.spring.context.SampleBean">
    <property name="message" value="Initial value" />
</bean>

Finally, if we close our running spring-context, we will see our destruction methods are executed in the order as;

@PreDestroy
DisposableBean
destroy-method

Closing an ApplicationContext

We can close Spring’s ApplicationContext by simply calling the method close of the context:

appContext.close();

Besides, we do not have to manually close, instead, we can easily configure ApplicationContext to automatically close itself on JVM shutdown:

appContext.registerShutdownHook();

Furthermore, if we are using Spring Boot, we do not need to do anything to close our application context because it is automatically configured to be closed in the shutdown stage.

Conclusion

In this article of our series, we learned what the ApplicationContext is and how it works in Spring Framework.

As always, you can check the related code examples over on Github.

After we talked about ApplicationContext, in our next article, we will go on with the Component Scanning and Auto-Injection of spring beans.

Writing a Utility Class for Collections in Java 8

Sat, 10 Aug 2019 18:00:00 +0000

One of the fluent APIs that Java 8 brings us, is the Java 8 Stream API, which provides a practical and minimal interface to code, especially with the help of Java 8 Lambdas.

Today, we are going to write a simple utility class to convert and modify java collections with ease, by using the power of Java 8 Streams.

Utility Classes

Utility classes are structures that contain reusable and stateless helper methods. We implement these methods for handling any kind of specific operations for specific purposes. Because of their stateless nature, we mostly prefer to define them as static.

First of all, let’s define a simple class:

public class UtilsForCollections {

}

Static Classes in Java

Static classes are classes that cannot be instantiated. As utility classes do not need to hold any state, it is appropriate to define them as static to prevent creating instances of them.

Unlike some other languages, in Java, we cannot use the static modifier for classes. Instead, we will use a private constructor to give the same ability to our utility classes:

public class UtilsForCollections {

    private UtilsForCollections() {

    }

}

Array to Collection Conversion

The first method of our utility class will be a generic method that simply converts a given array structure to java.util.Collection type.

We have two different behavioral types to return as java collections, one of them is List that is used when we need to preserve the order of the elements, the other one is Set that is used when we need to preserve the uniqueness of the elements.

First, let’s define a generic method that handles array to List conversion:

public static <T> List<T> toList(T[] array) {
    // TODO implement but how?
}

Power of Java 8 Stream API

Normally to implement this kind of method, we need to traverse the elements of an array and populate each of them to a newly created ArrayList object. However, thanks to the Java 8 Stream API, we can easily get rid of this sort of boilerplates.

So let’s implement our toList method:

public static <T> List<T> toList(T[] array) {
    return Arrays.stream(array).collect(Collectors.toList());
}

We use the Arrays.stream() method to open a stream over the given array. Once we acquire the stream instance, we may operate over the stream by many provided methods like collect, filter, map, etc. We choose the method collect here to copy elements from an array to another structure with the help of predefined stream collectors.

Like toList method, let’s define a separate method for array to Set conversion:

public static <T> Set<T> toSet(T[] array) {
    return Arrays.stream(array).collect(Collectors.toSet());
}

Handling Primitive Types

With the help of generics we successfully handled for all object types but when it comes to primitive types of java we cannot use our generic methods. We see an error when we try to use with primitive-typed arrays and our java compiler complains about the argument types which are not applicable:

int[] intArray = new int[] { 1, 2, 3 };
UtilsForCollections.toList(intArray); // this line gives us a compile error!

One of the ways of solving this problem is simply defining separate methods with primitive-typed arguments. We will use boxed method of streams to box every primitive element to its wrapper objects:

public static List<Integer> toList(int[] array) {
    return Arrays.stream(array).boxed().collect(Collectors.toList());
}

public static List<Long> toList(long[] array) {
    return Arrays.stream(array).boxed().collect(Collectors.toList());
}

public static List<Double> toList(double[] array) {
    return Arrays.stream(array).boxed().collect(Collectors.toList());
}

Similarly, we can define more methods in the same way for other remaining primitives like boolean, byte, char, short, float, etc.

And also we can define their Set versions that are pretty same:

public static Set<Integer> toSet(int[] array) {
    return Arrays.stream(array).boxed().collect(Collectors.toSet());
}

public static Set<Long> toSet(long[] array) {
    return Arrays.stream(array).boxed().collect(Collectors.toSet());
}

public static Set<Double> toSet(double[] array) {
    return Arrays.stream(array).boxed().collect(Collectors.toSet());
}

Ordered Sets

Sometimes it might be important to preserve both the order and the uniqueness of the elements and we need to handle this with a single collection type. If we encounter this problem in java the LinkedHashSet collection type comes to rescue.

Let’s add an optional parameter to our ToSet method in order to return LinkedHashSet type instead of unordered HashSet:

public static <T> Set<T> toSet(T[] array) {
    return UtilsForCollections.toSet(array, false);
}

public static <T> Set<T> toSet(T[] array, boolean preserveOrder) {
    if (preserveOrder) {
        return Arrays.stream(array)
            .collect(Collectors.toCollection(LinkedHashSet::new));
    }
    return Arrays.stream(array).collect(Collectors.toSet());
}

The former method here simply uses the overloaded method of itself. By doing this, we not only provide a default value for preserveOrder parameter but also protect the backward compatibility of our utility methods. We set false to preserveOrder as default value here.

Collection to Collection Conversions

Conversion from a collection type to another collection type is also easily possible with streams. We can get streams from collections as well and we can perform List to Set conversion and vice versa.

Let’s define some methods to add this ability to our utility class:

public static <T> List<T> toList(Collection<T> collection) {
    return collection.stream().collect(Collectors.toList());
}

public static <T> Set<T> toSet(Collection<T> collection) {
    return UtilsForCollections.toSet(collection, false);
}

public static <T> Set<T> toSet(Collection<T> collection, boolean preserveOrder) {
    if (preserveOrder) {
        return collection.stream()
            .collect(Collectors.toCollection(LinkedHashSet::new));
    }
    return collection.stream().collect(Collectors.toSet());
}

Filtering Arrays and Collections

One of the handy methods of Stream API is filter method. This provides a comfortable way of filtering an array or collection and creating subsets of theirs. With the power of lambdas we can also customize the behavior.

Let’s define two methods to perform filtering on arrays or collections:

public static <T> List<T> filterArray(T[] array, Predicate<? super T> predicate) {
    return Arrays.stream(array).filter(predicate)
        .collect(Collectors.toCollection(ArrayList::new));
}

public static <T> List<T> filterCollection(Collection<T> collection, Predicate<? super T> predicate) {
    return collection.stream().filter(predicate)
        .collect(Collectors.toCollection(ArrayList::new));
}

Next, let’s use this method to filter an array of strings by their first letters as the character ” a “:

String[] array = new String[] { "apple", "banana", "orange", "avocado", "mango" };
List<String> filtered = UtilsForCollections.filterArray(array, v -> v.startsWith("a"));
filtered.forEach(System.out::println);

Now, by running this code, we will see the outputs of the filtered elements:

[apple, avocado]

Concatenate Elements into a String

Another ability that may be useful is printing the elements of collections or arrays. Most of the time, we use it for debugging purposes.

We can extend our utility class by adding some methods to simply joining the string representations of the elements. Plus, a custom separator and an optional limit parameter may be useful.

So, let’s define our join methods:

public static <T> String join(T[] array, String separator) {
    return UtilsForCollections.join(array, separator, 0);
}

public static <T> String join(T[] array, String separator, int limit) {
    if (limit > 0 && array.length > limit) {
        return Arrays.stream(array).limit(limit).map(String::valueOf)
            .collect(Collectors.joining(separator)) + separator + "...";
    }
    return Arrays.stream(array).map(String::valueOf)
        .collect(Collectors.joining(separator));
}

public static <T> String join(Collection<T> collection, String separator) {
    return UtilsForCollections.join(collection, separator, 0);
}

public static <T> String join(Collection<T> collection, String separator, int limit) {
    if (limit > 0 && collection.size() > limit) {
        return collection.stream().limit(limit).map(String::valueOf)
            .collect(Collectors.joining(separator)) + separator + "...";
    }
    return collection.stream().map(String::valueOf)
        .collect(Collectors.joining(separator));
}

Then, let’s use our join method with a separator of comma and a limit parameter of 3:

String[] array = new String[] { "apple", "banana", "orange", "avocado", "mango" };
String joined = UtilsForCollections.join(array, ", ", 3);
System.out.println(joined);

Last, we will see the output, maximum of 3 elements joined:

apple, banana, orange, ...

Finally

In this tutorial, we explained how to implement a simple utility class for collections by the help of Java 8 Stream API.

There are many possible methods to implement which are likely to come in handy when we are dealing with collections.

So, what do you think about any other useful methods to include in our utility class? Just feel free to comment below!

All the code samples given in this tutorial are available over on GitHub.

Containers, Inversion of Control and Dependency Injection

Sat, 27 Jul 2019 14:45:00 +0000

Overview

This is the second article of the series Spring Framework Fundamentals.

In this article, we will explain Containers, what Inversion of Control is and how it is implemented by Dependency Injection with given examples in a simple way.

What is Containers?

Containers in computer science, are special structures that contain child objects as well as are responsible for managing their life-cycle. Although there may be different types of containers classified by how they access, store and traverse the objects inside, the most common behavior is, they create, alter and remove these child objects on purpose.

On the wild, this purpose is mostly to be a framework for solving specific business problems or at least providing a way to solve them with ease.

The ApplicationContext types from Spring Framework is a good example for a container class:

private GenericWebApplicationContext applicationContext;

public void setApplicationContext(GenericWebApplicationContext webApplicationContext){
    this.applicationContext = webApplicationContext;
    // register a bean to context
    this.applicationContext.registerBean(SomeComponent.class, () -> new SomeComponent());
    // and get an instance of that bean
    SomeComponent component = this.applicationContext.getBean(SomeComponent.class);
}

What is Inversion of Control?

There is a well-known term as cohesion in computer science, which defines the relations of objects and how they can act together in a container class.

Most of the time it is mentioned by high cohesion. This means acting well of objects together with great solidarity while keeping complexity low and maintainable.

Besides, while we keep these objects cohesive, we also need to keep them loosely coupled because every object should independently operate their own single responsibility.

Hence, this provides some critical benefits such as; maintainability, reusability and testability.

When it comes to Inversion of Control, indeed better to call it as a principle, a way of implementing highly cohesive and loosely coupled objects. In OOP, it literally means to convert the flow of controlling a child object by delegating its creation logic to another class.

Thus, the parent object does not need to worry about how its dependent objects should be initialized and the coupling becomes loose.

There are many design patterns in order to implement the IoC principle, some of these patterns are Service Locator, Factory, Abstract Factory, Template Method, Strategy, Dependency Injection.

Let’s imagine we have a simple UserService as a container:

public class UserService {

    private UserDao userDao = new UserDao();

}

Then, change the code like below by using Factory pattern:

public class DaoFactory {

    public static UserDao createUserDao(){
        return new UserDao();
    }

}

public class UserService {

    private UserDao userDao = DaoFactory.createUserDao();

}

So, we have implemented a basic IoC and made the dependency between UserService and UserDao less strict which means loose coupling.

What is Dependency Injection?

Dependency Injection is a popular design pattern to implement IoC. It is a mechanism that scans object hierarchy, resolves dependencies and assigns the instances properly to dependent objects.

For example in Spring Framework, this is clearly provided by the well-known annotation @Autowired. Spring’s ApplicationContext makes a component scan on startup and handles the injection of dependent instances internally among its managed objects.

Let’s show a simple DI over a spring bean defined as UserService:

@Service
public class UserService implements IUserService {

    @Autowired
    private IUserDao userDao;

}

Note that we need to depend on abstract types in order to make loosely coupled connections. This is also an obvious rule of Dependency Inversion Principle which we explained in our previous article.

Consequently, we can say that DIP is a well-fit design to implement a practicle IoC Container. This is why we use an interface called IUserDao instead of a concrete UserDao type.

Conclusion

After we mentioned about containers, inversion of control and dependency injection, in our next article, we will continue with the ApplicationContext and explain the basics of Spring Framework.

Java Algorithm Questions

Tue, 16 Jul 2019 18:04:00 +0000

Today, I would like to share one of my repositories which is about some interesting java algorithm questions and my solutions to them.

These questions are;

Path
Folders
Sorted Search
Palindrome
Train Composition
Circular Primes
Truncatable Primes

You can check the questions and solutions from the repository over on Github.

Feel free to comment if you have something to share. Cheers!

Object Oriented Programming and SOLID Principles

Sat, 22 Jun 2019 16:33:00 +0000

Overview

This article is the first one of the series Spring Framework Fundamentals.

In this very first article, we will explain Object Oriented Programming and some basic principles both with definitions and code samples.

Object Oriented Programming

One of the popular programming paradigms is called Object Oriented Programming, generally abbreviated as OOP, suggests that objects should be used in computer programs.

Objects are special structures in programming contain data in forms of their properties, also named as attributes.

Besides, they contain procedures that are responsible for altering this data which are mostly called as functions.

Hopefully, Java is a clean implementation of the object oriented programming and contains many high-level structures for developers which are formed by objects. Thus we do not need to worry about most of the low-level operations.

However, there are further principles to learn to apply OOP correctly. These are widely known as solid principles in the programming world. When we say solid, this is because they literally form the SOLID. It is a funny story about that our former computer scientists culminated with an acronym for five OOP design principles intended to make software designs better and understandable.

What are these SOLID principles?

We have five principles each of them stands for each letter S-O-L-I-D. They are Single Responsibility Principle, Open Closed Principle, Liskov Substitution Principle, Interface Segregation Principle and Dependency Inversion Principle.

Single Responsibility Principle

Single Responsibility Principle in software programming suggests that an object should only have single responsibility. We usually refer any module, class or function here. In this way, one object can only modify one part of the software’s specifications.

Objects trying to handle more than one responsibility will eventually ensue fragility and become impossible to maintain. Thus, it is highly possible, the violation of this principle causes us the famous God Object anti-pattern in time.

An example to indicate a violation of the single responsibility principle:

LoginManager.java

if(LoginType.LOCAL_DB.equals(type)){

    // authenticating user from local db

} else if(LoginType.REMOTE_DB.equals(type)){

    // authenticating user from remote db

} else if(LoginType.LDAP.equals(type)){

    // authenticating user from ldap

} else if(LoginType.SOCIAL.equals(type)){

    // authenticating user from social network accounts

}
// and this conditional cases can go on...

So this code seems to start smelling like becoming a god object. Although it looks like a semi-god for now, it definitely intends to become bigger in time unless we do not stop it by refactoring:

LoginManager.java

public LoginManager() {
    // registering our manager implementations
    loginManagers.add(new LocalDBLoginManager());
    loginManagers.add(new RemoteDBLoginManager());
    loginManagers.add(new LdapLoginManager());
    loginManagers.add(new SocialLoginManager());
}

public void authenticate(User user, LoginType type) {
    // getManager method returns the right implementation
    // according to login type we need
    ILoginManager loginManager = getManager(type);
    loginManager.authenticate(user);
}

You can check the source code for this sample over here.

Besides, you can read single responsibility principle over on Wikipedia for further details.

Open Closed Principle

Open Closed Principle in software programming means that an ideal software application should be open for extensions but closed for modifications. Doing modification here is thought for changing the existing codes of pre-made modules, classes, etc.

On the other hand, what is mentioned when we say extension is; adding new classes, modules or even functions without touching the rest of the codebase.

Some implications of modification:

Increases fragility, decreases maintainability.
Causes strictly tight modules and classes.
Hard to test, leads to unexpected bugs.

A clear example to show a piece of code which will probably need modifications later:

ModificationManager.java

if(ModificationType.LESS.equals(type)){

    // less modification :)

} else if(ModificationType.MEDIUM.equals(type)){

    // medium modification :(

} else if(ModificationType.QUITE.equals(type)){

    // quite a lot modification :O

} else if(ModificationType.ENORMOUS.equals(type)){

    // vast modification >:O

}
// and this conditional cases can go on...

One proper solution to this problem is Chain of Responsibility pattern which is also a good example of design by extensions, can be achieved like the code below:

ModificationManager.java

public ModificationManager() {
    // new modifier implementations can be easily added
    // without touching the rest of the code
    modifiers.add(new LessModifier());
    modifiers.add(new MediumModifier());
    modifiers.add(new QuiteModifier());
    modifiers.add(new EnormousModifier());
}

// main part of the code that handles the logic
// is not affected by adding or removing different type of modifiers
public boolean modifySystem(ModificationType type) {

    for (IModifier modifier : modifiers) {
        // each modifier instance knows that they can modify it
        // or not and returns the result as boolean
        if (modifier.modify(type)) {
            return true;
        }
    }

    // if we are here then it seems no modification is done
    return false;

}

You can check the source code for this sample over here.

How the OCP can be used in Java?

One of the best practices is programming to interface when it comes to applying OCP into java. Programming to interface means to prefer using interfaces instead of concrete types unless you specifically need to.

Interfaces are the contracts to expose the behavior type of our program to the outer world. With the help of well-defined interfaces, you always have a chance to create new implementations and easily extend your project without affecting the world outside. This technically means adding an extension.

Hence, we can say that interfaces really play nice with the OCP.

A simple example to show an advantage of using interfaces over concrete types:

CoffeeMachine.java

public interface Coffee {
    public void taste();
}

Coffee coffee = new FilterCoffee();

// you taste filter coffee!
coffee.taste();

// After some time we discover a new taste and add our new coffee formula!
Coffee coffee = new EspressoCoffee();

// now you taste espresso, we do not need to modify the code below!
coffee.taste();

Besides, you can read open closed principle over on Wikipedia for further details.

Liskov Substitution Principle

Liskov Substitution Principle suggests that objects in a software program should be replaceable with the instances of their subtypes without need to change properties of theirs.

Another use case of interfaces transpires here, since we need a behavioral similarity between subtypes, also called as strong behavioral subtyping. Different behaviors can output different results so we need to group subtypes with similar behavior by using interfaces not to break our program’s communication with the outside.

An example to demonstrate this problem:

public class Fish {
    public void swim(){
        System.out.println("I'm swimming")
    }
}

public class DeadFish extends Fish {
    public void swim(){
        System.out.println("Cannot swim because I'm dead!")
    }
}

// Let's say that we need a fishing pool which every Fish instance should swim.
// However as you can see some instances will not be able to swim because they are dead.
List<Fish> pool = new ArrayList<>();
pool.add(new Fish());
pool.add(new Fish());
pool.add(new DeadFish());

for(Fish fish:pool){
    fish.swim();
}

An elegant solution comes with the help of interfaces to discriminate subtypes according to their behaviors:

public interface Alive {
    public void swim();
}

public interface Dead {
    public void sink();
}

public class AliveFish extends Fish implements Alive {

    @Override
    public void swim() {
        System.out.println("I'm swimming because I'm alive :)");
    }
}

public class DeadFish extends Fish implements Dead {

    @Override
    public void swim() {
        System.out.println("Cannot swim because I'm dead!");
    }

    public void sink() {
        System.out.println("I'm sinking :(");
    }
}

// So we need only alive fish for our fishing pool.
// Now we are sure that every Fish instance in our pool can swim!
List<Alive> pool = new ArrayList<>();
pool.add(new AliveFish());
pool.add(new AliveFish());
pool.add(new AliveFish());
// compilation error prevents us to add DeadFish instances by mistake!
// pool.add(new DeadFish());

for(Alive fish:pool){
    fish.swim();
}

You can check the source code for this sample over here.

Besides, you can read liskov substitution principle over on Wikipedia for further details.

Interface Segregation Principle

Interface Segregation Principle in software simply tells us that instead of one general-purpose interface, it is better to use many client-specific ones. One obvious problem we can encounter when we violate this principle, is the boilerplate invasion of meaningless, empty methods.

Let us show this problem with an example:

public interface Animal {

    public void swim();
    public void fly();
    public void run();

}

public class SwimmingAnimal implements Animal {

    public void swim(){
        System.out.println("Oh it's swimming, I know how to swim :)");
    }

    // Ideally we do not need to implement the methods below
    public void fly(){
        System.out.println("What am i going to do?");
    }

    public void run(){
        System.out.println("What am i going to do?");
    }

}

And the solution would be splitting our general interface into more specific ones:

public interface Animal {
    // let this be just a marker interface
}

public interface CanSwim extends Animal {
    public void swim();
}

public interface CanFly extends Animal {
    public void fly();
}

public interface CanRun extends Animal {
    public void run();
}

// no need to implement unnecessary methods
public class SwimmingAnimal implements CanSwim {
    public void swim(){
        System.out.println("Oh it's swimming, I know how to swim :)");
    }
}

You can check the source code for this sample over here.

Besides, you can read interface segregation principle over on Wikipedia for further details.

Dependency Inversion Principle

Dependency Inversion Principle states that in a software program high-level objects should not depend on low-level objects, on the contrary, both should depend on abstractions.

Similarly, concrete classes should depend on abstractions, but abstract ones should not. After these explanations, let’s be a little bit more explanatory.

An example of a DIP violation:

public class OperatingSystem {

    private HttpService httpService = new HttpService();
    private SmtpService smtpService = new SmtpService();

    public void runOnStartup() {
        httpService.startHttpd();
        smtpService.startSmtpd();
    }

}

Instead of depending on concrete classes we should definitely make an abstraction by the help of interfaces and refactor our tiny operating system to accept only abstract services in order to initiate on the os startup.

See the code below:

public class HttpService implements IService {
    public void start(){
        System.out.println("Starting httpd service...");
    }
}

public class SmtpService implements IService {
    public void start(){
        System.out.println("Starting smtpd service...");
    }
}

public class OperatingSystem {

    private List<IService> services = new ArrayList<>();

    public OperatingSystem() {
        register(new HttpService());
        register(new SmtpService());
    }

    public void register(IService service){
        this.services.add(service);
    }

    public void runOnStartup() {
        this.services.forEach(s -> s.start());
    }

}

You can check the source code for this sample over here.

Besides, you can read dependency inversion principle over on Wikipedia for further details.

Conclusion

After we explained OOP and the solid principles shortly we will go on Containers, Inversion of Control and Dependency Injection and give some examples about how they are applied in our next article.

Spring Framework Fundamentals

Sat, 15 Jun 2019 14:52:00 +0000

I have created an educational repository that aims to provide fundamental information and code samples with Java. My project primarily focuses on Spring Framework and attempts to prepare such a repository not only to refresh potential knowledge and practice but also to contribute, for developing the open-source community. So feel free to drop comments about your opinion and any contributions are welcome!

Please note that this guide does not like regular how-to guides explaining every detail from scratch. My goal is to touch every important topic about the core of the Spring Framework instead of writing about specific topics in detail. It is a collection of simple answers to the most common questions about the framework. Thus, it might not be for totally beginners or who do not have any experience with Spring Framework before.

You can check the repository over on Github

Before Start

First of all, before we dive into Spring, we should get familiar with some basic programming principles which are highly accepted in Java world and moreover strictly followed in Spring Framework.

In this way, I believe this guide will be much more effective and easily understandable.

So, I will start with the topic Object Orient Programming and SOLID Principles as my first article.

Welcome to My Blog!

Thu, 13 Jun 2019 13:00:00 +0000

A momentous occasion for me, so many years passed until I launched my own blog. Under the burden of my daily work, I thought I couldn’t share my experience because I was a fairly busy guy. Man, I was wrong!

Developers — especially the lazy ones like me — always tend to cop out quickly when it comes to writing, simply anything than code. Even though the output doesn’t have to be perfect, it feels way harder than coding most of the time.

But believe me, the trick is a bit of time management and self-discipline, nothing more. We, developers, owe so many things to the public community. And we, developers, have so much to share.

From now on, I’m writing.

public class MyBlogApplicationStarter {

    public static void main(String args[]){

        MyBlog myBlog = MyBlogFactory.create("https://yavuztas.dev");
        myBlog.start();

    }

}