Friendly REST APIs with Swagger

With this screencast I want to show you how to document your REST APIs with Swagger specification. Simply, your code synchronized with your documentation.

Until next post.

Defining your application model

When you start a project, one of the first task to do is to design the application model. Some people associate this task with the design of the relational database model. When you have the model designed, you have the 80% of the application done. In fact, if you are working with a Oriented Object language, you should design your model in terms of objects first.  Relational databases are one option to implement the persistency requirement, but as you know is not the only way. Hence, if you are thinking your model in terms of tables and so on, you are coupling your business with a concrete technology. Then if you choose a OO language like Java, you have to design the model in terms of objects. In fact , for this reason exist tools like ORMs (hibernate, Ibatis,...) or APIs like JPA, to decouple your model from the persistence technology chosen.

I think that they are some key questions to help you to do a good choice:

• Do you need ACID transactions ? Is it critical for your business the inconsistency (for example ghost reads) ? If not NoSQL could be a good option.
• Do you need storage procedures or triggers at the persistency tool level? If you can manage this from your code, NoSQL could be a good option.
• Do you need a rigid scheme? If not NoSQL could be a good option.
• Is the consistency critical? If not NoSQL could be a good option.
• Do you need to support a very large data loads? NoSQL can scale better than RDBMS. Normally RDBMS scales with more hardware. 
• Do you need to support a lot of concurrent users? NoSQL again.
• Do you need a very consistent performance ? NoSQL again.

Think in your requirements, imagine you are a driver. If you want to win a race, your skills are important, but also your car. You need a competitive car. You don't need a comfortable car, with radio, alarm , leather seats, or whatever else. What you need is a faster car, with good brakes and powerful engine, nothing more. Something similar happens with a RDBMS and  a NoSQL system. 

What kind of car do you need for your trip?

Until next post.

Dependency Injection vs Service Locator

Dependency Injection and Service Locator, two different ways to implement Inversion of control principle.

A dependency injector container acts as an assembler of objects, decoupling your business logic from their dependencies. But sometimes is more complex to debug when we have a issue.

On the other hand, Service Locator hides the implementation details too, but your class has dependency with the Service Locator class. Only, when this dependency is not a problem, the Service Locator pattern is a good choice.

Most important of all, is to split the configuration code from the use code. Take it into account , and  analyze when one option is better than the other.

Until next post!

Thanks lambdas

With this post, I want to show you step by step the process of transforming a static and rigid code, to something more flexible and reusable using lambda expressions. Let's stop talking, let's to see code.

Imagine you have a selling car business, and you want an application to filtering the cars by brand. Then your business logic could look like this.

	// business logic
	public static List<Car> filterCarsByBrand(List<Car> cars, String brand) {
	ArrayList<Car> filteredCars = new ArrayList<Car>();
	for (Car car : cars) {
	if (brand.equals(car.getBrand())) {
	filteredCars.add(car);
	}
	}
	return filteredCars;
	}
	...
	// from your programm, you can call it from this way
	List<Car> filteredCars = filterCarsByBrand(cars, "Ferrari");

view raw FilterCarByBrandApproach1.java hosted with ❤ by GitHub

That it's ok. But now you want to filtering by brand and color too. You have to add a new method in order to support the new functionality. In this case, we can do it easily.

	// business logic
	public static List<Car> filterCarsByBrandAndColor(List<Car> cars, String brand, String color) {
	// we can reuse the method to filtering by brand
	List<Car> filteredCarsByBrand = filterCarsByBrand(cars, brand);
	ArrayList<Car> filteredCars = new ArrayList<Car>();
	for (Car car : cars) {
	if (color.equals(car.getColor())) {
	filteredCars.add(car);
	}
	}
	return filteredCars;
	}
	...
	// from your programm, you can call it from this way
	List<Car> filteredCars = filterCarsByBrand(cars, "Ferrari", "red");

view raw FilterCarByBrandApproach2.java hosted with ❤ by GitHub

What can we say about this code? In front of any new requirement, a new method is implemented. Then we have the phenomenon of method explosion.

We can try to do it better with a new interface called CarChecker.

	// new interface
	public interface CarChecker {
	boolean check(Car car);
	}
	...
	//business logic
	public static List<Car> filterCars(List<Car> cars, CarChecker carChecker) {
	ArrayList<Car> filteredCars = new ArrayList<Car>();
	for (Car car : cars) {
	if (carChecker.check(car)) {
	filteredCars.add(car);
	}
	}
	return filteredCars;
	}
	...
	// from your program
	List<Car> filter1 = filterCars(input, new BrandCarChecker());
	List<Car> filter2 = filterCars(input, new BrandAndColorCarChecker());

view raw FilterCarByBrandApproach3.java hosted with ❤ by GitHub

Yes, I know what are you thinking. Now we have a generic method, but now we have class explosion instead of method explosion. You are right. We can try to do it with anonymous classes.

	List<Car> cars = filterCars(input, new CarChecker() {
	public boolean check(Car car) {
	return "Ferrari".equals(car.getBrand()) && "red".equals(car.getColor());
	}
	});

view raw FilterCarByBrandApproach4.java hosted with ❤ by GitHub

But CarChecker it's a functional interface. We can use lambda expressions.

	List<Car> filteredCars = filterCars(input, car -> {
	return "Ferrari".equals(car.getBrand()) && "red".equals(car.getColor());
	});

view raw FilterCarByBrandApproach5.java hosted with ❤ by GitHub

At this point, our code looks cool. But Java 8 includes something called Predicate. Then we can rewrite our business logic to this.

	// business logic
	public static List<Car> filterCars(List<Car> cars, Predicate<Car> carPredicate) {
	ArrayList<Car> filteredCars = new ArrayList<Car>();
	for (Car car : cars) {
	if (carPredicate.test(car)) {
	filteredCars.add(car);
	}
	}
	return filteredCars;
	}
	...
	// from your program
	List<Car> cars = filterCars(input, car -> {return "Ferrari".equals(car.getBrand()) && "red".equals(car.getColor());});

view raw FilterCarByBrandApproach6.java hosted with ❤ by GitHub

Usually, when you filter a collection of objects then you want to do something with the result. We can try to generalize a function to processing the result of cars filtering using Consumer interface, included also by Java 8.

	// business logic
	public static void processCars(List<Car> cars, Predicate<Car> carPredicate, Consumer<Car> carConsumer) {
	for (Car car : cars) {
	if (carPredicate.test(car)) {
	carConsumer.accept(car);
	}
	}
	}
	...
	// from your program
	processCars(input, c -> { return "Ferrari".equals(c.getBrand()); }, c -> System.out.println(c));

view raw FilterCarByBrandApproach7.java hosted with ❤ by GitHub

And that's all. Code more flexible and reusable.

Thanks lambdas.

More functional programming for Java 8 with Javaslang

Java 8 has introduced three new features about functional programming.

• Lambda expressions.
• Higher-order functions.
• Streams API.

I think that Java 8 did a great step to integrate functional programming in its platform. But if you want to codify in a declarative way, or in other words, you want to tell to your computer what you want to compute instead of how, you need  more expressiveness or abstractions. Maybe Java 9 will provide new features to make our programs more declarative. But until now, libraries like Javaslang fills this gap, giving steroids to Java 8.

Javaslang provides structures like Tuple, Either, Match, Laizy, Promise, Try, and so on. Most of them available in languages like Scala, Haskell,...

We will see what happens with Java 9 ;)

Don't waste memory, Flyweight pattern

Take a look to this class.

	public class Car {
	private String engine;
	private String color;
	private long frameNumber;
	public Car(long frameNumber, String engine, String color) {
	this.engine = engine;
	this.color = color;
	this.frameNumber = frameNumber;
	}
	public String getEngine() {
	return engine;
	}
	public String getColor() {
	return color;
	}
	public long getFrameNumber() {
	return frameNumber;
	}
	}

view raw MyCoolCar.java hosted with ❤ by GitHub

It looks like a regular POJO. And you are right, it's regular POJO, until here all it's ok.

Now, imagine your main program needs to instantiate our class Car 10 times. Then, the java heap memory will look like something like that.

What if I tell you that there are only two types of engines and two different colors ? Do you think that the memory allocation can be optimized to something that looks like the following picture ?

The answer is yes, with the Flyweight pattern. First of all, we have to design our light car with the common attributes.

	public class LightCar {
	private String engine;
	private String color;
	public LightCar(String engine, String color) {
	this.engine = engine;
	this.color = color;
	}
	public String getEngine() {
	return engine;
	}
	public void setEngine(String engine) {
	this.engine = engine;
	}
	public String getColor() {
	return color;
	}
	public void setColor(String color) {
	this.color = color;
	}
	}

view raw LightCar.java hosted with ❤ by GitHub

After that, the next step is the container which contains all different types of light cars. It shall contain 4 different car types (2 engines x 2 colors).

	public class LightCarContainer {
	private static HashMap<String,LightCar> lightCars = new HashMap<String, LightCar>();
	public static LightCar getLightCar(String engine, String color) {
	String key = engine + color;
	if (!lightCars.containsKey(key)) {
	lightCars.put(key, new LightCar(engine,color));
	}
	return lightCars.get(key);
	}
	}

view raw LightCarContainer.java hosted with ❤ by GitHub

Then our Car class looks like something like that (pay attention to the new interface created Car and the delegation through LightCar).

	public class CarFlyWeight implements Car {
	private long frameNumber;
	private LightCar lightCar;
	public CarFlyWeight(long frameNumber, LightCar lightCar) {
	this.frameNumber = frameNumber;
	this.lightCar = lightCar;
	}
	@Override
	public String getEngine() {
	return lightCar.getEngine();
	}
	@Override
	public String getColor() {
	return lightCar.getColor();
	}
	@Override
	public long getFrameNumber() {
	return frameNumber;
	}
	}

view raw MyCoolCarFlyWeight.java hosted with ❤ by GitHub

And finally, our Factory to create cars.

	public class CarFactory {
	Car create(long frameNumber, String engine, String color) {
	return new CarFlyWeight(frameNumber, LightCarContainer.getLightCar(engine, color));
	}
	}

view raw MyCarFactory.java hosted with ❤ by GitHub

I think this is a great pattern, sometimes forgotten ;) .

You can see the original article at www.arquitecturajava.com

Avoiding nulls using Optional

Let me show you guys this code:

	String audioSystemVersion = "UNKNOWN";
	if (myCar != null) {
	AudioSystem audioSystem = myCar.getAudioSystem();
	if (audioSystem != null) { // the card has audio system.
	audioSystemVersion = audioSystem.getVersion();
	}
	}

view raw NullChecking.java hosted with ❤ by GitHub

Is this boilerplate code familiar for you? Null checking everywhere.

To give some historical context, Tony Hoare - one of the giants of computer science - wrote, "I call it my billion-dollar mistake. It was the invention of the null reference in 1965. I couldn't resist the temptation to put in a null reference, simple because it was so easy to implement."

What can you do to prevent unintended null pointer exceptions ? You can be defensive and add checks to prevent null references like you see in the above code, or you can use one of the amazing stuffs of Java 8 like the Optional pattern. We are going directly to the action, let me show you some code!

1. Creating Optional objects
   
   An empty Optional.
   
   

   Optional<AudioSystem> sc = Optional.empty();

   view raw EmptyOptional.java hosted with ❤ by GitHub
   
   A non null Optional. If audioSystem were null, a NullPointerException would be thrown. Take it into account.
   
   

   	AudioSystem audioSystem = new AudioSystem();
   	Optional<AudioSystem> as = Optional.of(audioSystem);

   view raw NonNullValue.java hosted with ❤ by GitHub
   
   Finally, you can create an Optional from a null reference. If audioSystem were null, the resulting Optional would be an empty Optional.
   
   

   Optional<AudioSystem> as = Optional.ofNullable(audioSystem);

   view raw NullableOptional.java hosted with ❤ by GitHub
2. Do something if value present
   
   Instead of this
   
   

   	AudioSystem as = ....;
   	if (as != null) {
   	Sysmte.out.println(as);
   	}

   view raw NullCheckBeforeAccess.java hosted with ❤ by GitHub
   
   better this (functional style).
   
   

   	Optional<AudioSystem> as = ...;
   	as.ifPresent(System.out::println);

   view raw IfPresentOptional.java hosted with ❤ by GitHub
   
   or you can use it the imperative way (not recommended)
   
   

   	Optional<AudioSystem> audioSystem = ...;
   	if(audioSystem.isPresent()){
   	System.out.println(audioSystem.get());
   	}

   view raw ImperativeWayOptional.java hosted with ❤ by GitHub
3. Filter values using filter method
   
   Instead of this
   
   

   	AudioSystem as = ...;
   	if(as != null && "Pionner".equals(as.getBrand())){
   	System.out.println(as);
   	}

   view raw FilteringCheckingNull.java hosted with ❤ by GitHub
   better this (using the class Predicate).
   
   

   	Optional<AudioSystem> maybeAudioSystem = ...;
   	maybeAudioSystem.filter(as -> "Pionner".equals(as.getBrand())
   	.ifPresent(as -> System.out.println(as));

   view raw FilteringOptional.java hosted with ❤ by GitHub
4. Extracting and transforming values using the map method
   
   Instead of this
   
   

   	if(car != null){
   	AudioSystem as = car.getAudioSystem();
   	if(as != null && "Pionner".equals(as.getBrand()){
   	System.out.println("ok");
   	}
   	}

   view raw TransformingUsingChecksNull.java hosted with ❤ by GitHub
   better this
   
   

   	maybeCar.map(Car::getAudioSystem)
   	.filter(as -> "Pionner".equals(as.getBrand())
   	.ifPresent(() -> System.out.println("ok"));

   view raw TransformingUsingOptional.java hosted with ❤ by GitHub

The purpose of Optional is not to replace every single null reference in your codebase but rather to help design better APIs in which—just by reading the signature of a method—users can tell whether to expect an optional value. In addition, Optional forces you to actively unwrap an Optional to deal with the absence of a value; as a result, you protect your code against unintended null pointer exceptions.

Killing the nulls!

Don't test Private Methods

I would like to share with you guys an article that form me is pretty interesting. The sentence to remember is the following one:

Private methods are for hiding implementation and we don’t want to test implementation details when we do TDD, that’s better achieved as part of a QA effort, if needed.

You can read the complete article here.

Good unit tests are the backbone of successful TDD. Keep the following in mind as you write unit tests: ‚

• Each unit test should be independent. ‚ 
• Each unit test should test one aspect or behavior and document the expected behavior. ‚ 
• Each unit test should not verify too much functionality. ‚ 
• Each unit test should not be dependent on interface.

Have a nice day!

You can see the original article at java Dzone

Bintray, a social platform binaries

This is the new trend. Where something works, the next step is socialize it.
In other words, Bintray is like a "Maven Central" but with a social layer. I have to say that it works very well, it is very easy to deploy your own repositories following a simple guided steps. Also is very easy to pass your atifacts to JCenter or Maven Central.

Take a look at here.

Command framework

Today, I want to show you guys an API which I developed to create commands in a fluent way. This API is based on the Builder pattern, to provide us something similar to a DSL (Domain Specific Language), in this case to create commands.

Note that this API provides a model based on Command, ErrorHandler and CommandRepository objects. With these three classes, you can build any complex command you want, applying patterns like Decorator, Composite, Visitor and so on.

Take a look command framework. And feel free to branch the project.

Until next time.
Happy codding :)