Posted on September 23, 2017September 24, 2017 by sexysoftwareengineer

Things I like about Java: Anonymous classes

Everybody that knows me in real life knows that my favourite jokes are always those about Java being slow and bloated. But still, in all fairness, Java has some good things.

One of them, rendered obsolete by Java 8’s Lambda Expressions, that I always liked and that I really wish was possible in Swift, is Anonymous classes.

The way I see it, an anonymous class is just a syntax shortcut to declare and instantiate, inline, an instance of a specific interface. It is a quick way to create lightweight objects at the moment they are going to be used, or passed to another object.

interface Command {
    public void execute();
}

class AThing {
    public void doAThing(Command command) {
        command.execute();
    }
}

class Untitled {
    public static void main(String[] args) {
        AThing thing = new AThing();
        thing.doAThing(new Command() {
            public void execute() {
                System.out.print("Hello");
            }   
        });
    }
}

interface Command {

public void execute();

}

class AThing {

public void doAThing(Command command) {

command.execute();

}

class Untitled {

public static void main(String[] args) {

AThing thing = new AThing();

thing.doAThing(new Command() {

public void execute() {

System.out.print("Hello");

}

});

}

Anonymous classes have access to the members of its enclosing class, and local variables in its enclosing class marked as final, which makes them great candidates to be used, in particular, to declare callbacks in particular.

To me, their greatest advantage is that anonymous classes allow you to encapsulate behaviour in a way that you only declare implicit types when you expect to actually reuse them.

Still, Lambda Expressions, similar if not equal to what in Swift we know as closures, might make code more concise in some situations. So, as usual, it comes down to knowing your tools, and careful considering which tool is the best for the job.

Updated on Sept 24th.

Joe Fabisevich points out that something similar to what the sample code does could be achieved in Swift by typealias-ing a closure, and typing AThing’s doAThing parameter as said typealias.

typealias Command = () -> Void

class AThing {
    func doAThing(_ command: Command) {
        command()
    }
}

let thing = AThing()
thing.doAThing {
    print("hello")
}

typealias Command = () -> Void

class AThing {

func doAThing(_ command: Command) {

command()

}

let thing = AThing()

thing.doAThing {

print("hello")

}

Which is quite similar to a solution based on Java lambdas.

If we need to declare more than one method in the Command interface, though, this approach would fall sort.

Joe also suggests another option in Swift:

protocol Command {
    func execute()
}

struct AThing {
    func doAThing(command: Command) {
        command.execute()
    }
}

class Main {
    init() {
        struct Commander: Command {
            func execute() {
                print("Hello")
            }
        }

        let thing = AThing()
        thing.doAThing(command: Commander())
    }
}

Main()

protocol Command {

func execute()

}

struct AThing {

func doAThing(command: Command) {

command.execute()

}

class Main {

init() {

struct Commander: Command {

func execute() {

print("Hello")

}

let thing = AThing()

thing.doAThing(command: Commander())

}

Main()

This still requires making a type, but it is (or can be) private to the Main class, which in a way achieves the same goal as an anonymous class. It would be a concrete type, yes, but known only to the type enclosing it.

Posted on September 17, 2017September 17, 2017 by sexysoftwareengineer · 1 Comment

Elegant Swift: Default Parameters vs The Builder Pattern

I was re-reading Effective Java (it is a rainy Sunday afternoon in Vancouver, and if you are stuck at home, and you happen to be European, and therefore you don’t really care about what Americans call “football”, re-reading Effective Java is not as bad as it sounds) when I soon stumbled upon an example that I think highlights the elegance of Swift (and, to be completely fair, also Kotlin’s).

Effective Java’s Item #2 says: Consider a builder when faced with many constructor parameters. Which makes total sense, if you ask me.

I am not going to discuss or justify the Builder Pattern now, but let’s just assume that it is more than justified.

The canonical implementation of the pattern, and I am going to take the liberty of using the code sample used in Effective Java without any modification, would read like the following (servings and servingSize are the only mandatory parameters, the rest are all optional)

public class NutritionFacts {
    private final int servingSize; //required
    private final int servings; //required  
    private final int calories; //optional
    private final int fat; //optional
    private final int sodium; //optional
    private final int carbs; //optional
    
    public static class Builder {
        //Required
        private final int servingSize;
        private final int servings;
        
        //Optional
        private int calories = 0;
        private int fat = 0;
        private int sodium = 0;
        private int carbs = 0;
        
        public Builder(int servingSize, int servings) {
            this.servingSize = servingSize;
            this.servings = servings;
        }
        
        public Builder calories(int val) {
            calories = val;
            return this;
        }
        
        public Builder fat(int val) {
            fat = val;
            return this;
        }
        
        public Builder sodium(int val) {
            sodium = val;
            return this;
        }
        
        public Builder carbs(int val) {
            carbs = val;
            return this;
        }
        
        public NutritionFacts build() {
            return new NutritionFacts(this);
        }
        
    }
    
    private NutritionFacts(Builder builder) {
        servingSize = builder.servingSize;
        servings = builder.servings;
        calories = builder.calories;
        fat = builder.fat;
        sodium = builder.sodium;
        carbs = builder.carbs;
    }
}

class Untitled {
    public static void main(String[] args) {
        NutritionFacts cocaCola = new NutritionFacts.Builder(240,8)
.calories(100)
.sodium(35)
.carbs(27)
.build();
    }
}

public class NutritionFacts {

private final int servingSize; //required

private final int servings; //required

private final int calories; //optional

private final int fat; //optional

private final int sodium; //optional

private final int carbs; //optional

public static class Builder {

//Required

private final int servingSize;

private final int servings;

//Optional

private int calories = 0;

private int fat = 0;

private int sodium = 0;

private int carbs = 0;

public Builder(int servingSize, int servings) {

this.servingSize = servingSize;

this.servings = servings;

}

public Builder calories(int val) {

calories = val;

return this;

}

public Builder fat(int val) {

fat = val;

return this;

}

public Builder sodium(int val) {

sodium = val;

return this;

}

public Builder carbs(int val) {

carbs = val;

return this;

}

public NutritionFacts build() {

return new NutritionFacts(this);

}

private NutritionFacts(Builder builder) {

servingSize = builder.servingSize;

servings = builder.servings;

calories = builder.calories;

fat = builder.fat;

sodium = builder.sodium;

carbs = builder.carbs;

}

class Untitled {

public static void main(String[] args) {

NutritionFacts cocaCola = new NutritionFacts.Builder(240,8)

.calories(100)

.sodium(35)

.carbs(27)

.build();

}

If we follow the pattern to the letter, it translates into Swift like this:

final class NutritionFacts {
    private let servingSize: Int
    private let servings: Int
    private let calories: Int
    private let fat: Int
    private let sodium: Int
    private let carbs: Int

    init(builder: Builder) {
        servingSize = builder.servingSize
        servings = builder.servings
        calories = builder.calories
        fat = builder.fat
        sodium = builder.sodium
        carbs = builder.carbs
    }

    class Builder {
        let servingSize: Int
        let servings: Int

        private(set) var calories = 0
        private(set) var fat = 0
        private(set) var carbs = 0
        private(set) var sodium = 0

        init(servingSize: Int, servings: Int) {
            self.servingSize = servingSize
            self.servings = servings
        }

        func calories(value: Int) -> Builder {
            calories = value
            return self
        }

        func fat(value: Int) -> Builder {
            fat = value
            return self
        }

        func carbs(value: Int) -> Builder {
            carbs = value
            return self
        }

        func sodium(value: Int) -> Builder {
            sodium = value
            return self
        }

        func build() -> NutritionFacts {
            return NutritionFacts(builder: self)
        }
    }
}

let facts = NutritionFacts.Builder(servingSize: 10, servings: 1)
    .calories(value: 20)
    .carbs(value: 2)
    .fat(value: 5)
    .build()

final class NutritionFacts {

private let servingSize: Int

private let servings: Int

private let calories: Int

private let fat: Int

private let sodium: Int

private let carbs: Int

init(builder: Builder) {

servingSize = builder.servingSize

servings = builder.servings

calories = builder.calories

fat = builder.fat

sodium = builder.sodium

carbs = builder.carbs

}

class Builder {

let servingSize: Int

let servings: Int

private(set) var calories = 0

private(set) var fat = 0

private(set) var carbs = 0

private(set) var sodium = 0

init(servingSize: Int, servings: Int) {

self.servingSize = servingSize

self.servings = servings

}

func calories(value: Int) -> Builder {

calories = value

return self

}

func fat(value: Int) -> Builder {

fat = value

return self

}

func carbs(value: Int) -> Builder {

carbs = value

return self

}

func sodium(value: Int) -> Builder {

sodium = value

return self

}

func build() -> NutritionFacts {

return NutritionFacts(builder: self)

}

let facts = NutritionFacts.Builder(servingSize: 10, servings: 1)

.calories(value: 20)

.carbs(value: 2)

.fat(value: 5)

.build()

Which is a lot of boilerplate, no matter how you look at it.

We have discussed Swift’s Default Parameters before in this blog, but in the context of Dependency Injection, in particular when focusing on testability.

But the thing is that Default Parameters, like many other Swift artifacts (or constructs, or whatever is the right word to refer to “stuff that Swift provides and makes your life easier”) can make code much more concise, readable and easier to understand and reason about while removing some of the bloating that certain languages (I’m looking at you, Java) are known for.

Because when providing default values to all the optional parameters, this is how our NutritionFacts look.

final class NutritionFacts {
    private let servingSize: Int
    private let servings: Int
    private let calories: Int
    private let fat: Int
    private let sodium: Int
    private let carbs: Int
    
    init(servingSize: Int, servings: Int, calories: Int = 0, fat: Int = 0, sodium: Int = 0, carbs: Int = 0) {
        self.servingSize = servingSize
        self.servings = servings
        self.calories = calories
        self.fat = fat
        self.sodium = sodium
        self.carbs = carbs
    }
}

let facts = NutritionFacts(servingSize: 10, servings: 1, calories: 500)
let otherFacts = NutritionFacts(servingSize: 10, servings: 1, calories: 1500, sodium: 2)

final class NutritionFacts {

private let servingSize: Int

private let servings: Int

private let calories: Int

private let fat: Int

private let sodium: Int

private let carbs: Int

init(servingSize: Int, servings: Int, calories: Int = 0, fat: Int = 0, sodium: Int = 0, carbs: Int = 0) {

self.servingSize = servingSize

self.servings = servings

self.calories = calories

self.fat = fat

self.sodium = sodium

self.carbs = carbs

}

let facts = NutritionFacts(servingSize: 10, servings: 1, calories: 500)

let otherFacts = NutritionFacts(servingSize: 10, servings: 1, calories: 1500, sodium: 2)

Much better, eh?

Posted on September 13, 2015 by sexysoftwareengineer

Primitive obsession

If you have been following this blog (hi, mom!) you might have noticed a recurrent obsession of mine: stop looking at the wrong abstraction.

There is one case when looking at the wrong abstraction can be particularly dangerous: dealing with primitives.

Primitive what!?

Martin Fowler (bow) already explained this, better that me obviously, in Refactoring. “Replace Data Value with Object”, Mr Fowler wrote. “Apply this refactoring when you have a data item that needs additional data or behaviour”.

But what does than mean? Let’s see it with an example.

Often times, primitives (strings and numbers in particular) have special meaning. Phone numbers, addresses, email addresses, usernames… all of those are either numbers of strings, but those are numbers or strings with some associated “behaviour”, specially in terms of how they are represented or validated.

For example, consider a class that models a User. The proper way of modelling an User using a POJO would be something like this:

class User {
	private final String name;
	private final String surname;
	private final String userId;
	private final String emailAddress;
	
	public User(String name, String surname, String userId, String emailAddress) {
		this.name = name;
		this.surname = surname;
		this.userId = userId;
		this.emailAddress = emailAddress;
	}
	
	public String getName() {
		return name;
	}
	
	public String getSurname() {
		return surname;
	}
	
	public String getEmail() {
		return emailAddress;
	}
}

class User {

private final String name;

private final String surname;

private final String userId;

private final String emailAddress;

public User(String name, String surname, String userId, String emailAddress) {

this.name = name;

this.surname = surname;

this.userId = userId;

this.emailAddress = emailAddress;

}

public String getName() {

return name;

}

public String getSurname() {

return surname;

}

public String getEmail() {

return emailAddress;

}

That class would pass 99% of code reviews without a single comment. It is immutable, it encapsulates the user data properly, and it does not expose anything it should not expose.

Now, let’s say we create a User like this:

final User cesar = new User("Cesar", "Tardaguila", "001", "name@domain.com");		
System.out.println("name " + cesar.getName());

1 2	final User cesar = new User("Cesar", "Tardaguila", "001", "name@domain.com"); System.out.println("name " + cesar.getName());

And now, let’s say we create it like this.

final User cesar = new User("Cesar", "Tardaguila", "001", "not an email address, LOL!");		
System.out.println("name " + cesar.getName());
System.out.println("email " + cesar.getEmail());

final User cesar = new User("Cesar", "Tardaguila", "001", "not an email address, LOL!");

System.out.println("name " + cesar.getName());

System.out.println("email " + cesar.getEmail());

Boom. Name and surname are swapped, and the user has an invalid email address.

Promoting primitives to objects

I have already discussed a similar approach to the one I am going to suggest now. However, there are some subtle differences.

Let’s discuss first the email address. An email address can be represented as a string, but there is some behaviour associated to it, because not all strings are valid email addresses. Email addresses need to be validated!

So, representing an email address as a string means that it will need to be validated every time it is going to be used.

However, if we have an EmailAddress class, we can either guarantee that instances of that class will only be created when they are provided a valid email address (as a string) or declare a method that validates the address.

If we did that, the previous constructor could be rewritten as:

public User(String name, String surname, String userId, Email emailAddress){
	this.name = name;
	this.surname = surname;
	this.userId = userId;
	this.emailAddress = emailAddress;
}

public User(String name, String surname, String userId, Email emailAddress){

this.name = name;

this.surname = surname;

this.userId = userId;

this.emailAddress = emailAddress;

}

Now, what about the name and surname? Well, we might want to add some behaviour to them as well, but I think the most compelling reason to promote them to objects would be type safety. Check this out:

public User(Firstname name, Surname surname, String userId, Email emailAddress) {
	this.name = name;
	this.surname = surname;
	this.userId = userId;
	this.emailAddress = emailAddress;
}

public User(Firstname name, Surname surname, String userId, Email emailAddress) {

this.name = name;

this.surname = surname;

this.userId = userId;

this.emailAddress = emailAddress;

}

Now, it is impossible to mess up the order of the arguments. The compiler will complain loudly as soon as you do not pass the right thing at the right place.

Isn’t that unnecessary complexity?

I wouldn’t say so. I would say that it is proper object orientation. A first name is not a string, although it is usually represented as a string, the same way an email address is not a string, but something with semantic value that, yes, can be represented as a string.

Now, obviously, this means more classes and most likely more objects living within the application cycle. True.

But software engineering is all about considering and balancing the trade-offs. And in this case, an extra class is a price I’m willing to pay in exchange for safer, more robust, and more cohesive code.

Posted on April 14, 2015April 14, 2015 by sexysoftwareengineer

Sometimes nothing is something. Or the null object pattern with a touch of the decorator pattern

Or why if clauses should die in a fire.

This post has been lingering, locked up in my drafts folder (which is not an actual folder, but all the cool kids say that, so bear with me on this) for some time.

Yesterday, I stumbled upon this talk by Sandi Metz, because, yes, sometimes I search Youtube looking for recordings of talks about OOD. I am a big fun on Sandi’s talks, and this one did not disappoint me, as usual. And it also gave me the push needed to publish this post

If clauses breed, and sometimes, nothing is something

I am not a big fan of if clauses. I know they are necessary, but I try to avoid them as much as possible, specially when they are type checks.

Type checks are bad

Period. There is always someone that will tell you that type checks might be necessary sometimes, but truth is they are one of the biggest and stinkiest code smells.

“What is a type check?” you might ask. Fair enough; this is a type check:

This is the quintessential example of why type checks are wrong, and you will find a thousand slightly different variations of it on the interwebs.

What’s wrong with that? Simple

Type checks are a sign of bad design

if (aAnimal instanceof Fish) {
    Fish fish = (Fish)aAnimal;
    fish.swim();
} else if (aAnimal instanceof Spider) {
    Spider spider = (Spider)aAnimal;
    spider.crawl();
}

if (aAnimal instanceof Fish) {

Fish fish = (Fish)aAnimal;

fish.swim();

} else if (aAnimal instanceof Spider) {

Spider spider = (Spider)aAnimal;

spider.crawl();

}

The previous code sample is the perfect example of how a type check is a symptom of a bad abstraction. A Fish and a Spider are both animals, so they both should implement an interface declaring a move() method. Clients of Fishes and Spiders would only be aware of that abstraction and call the move() method. Period.

There is a particularly bad type of the check

And that is the one that does not look like one. It is usually in disguise, pretending to be a null check.

Here is an elaborate example. Consider a Car class:

class Car {
    private final String name;
	
    public Car(final String name) {
        this.name = name;
    } 
	
    public String getName() {
        return name;
    }
}

class Car {

private final String name;

public Car(final String name) {

this.name = name;

}

public String getName() {

return name;

}

And a CarWarehouse class:

class CarWarehouse {
    private final Map<String, Car> stock;
	
    public CarWarehouse() {
        stock = new HashMap<String, Car>();		
        buildStock();
    }
	
    private void buildStock() {
        stock.put("Porsche", new Car("Porsche"));
        stock.put("Ferrari", new Car("Ferrari"));	
    }
		
    public Car getCar(final String model) {
        return stock.get(model);
    }
}

class CarWarehouse {

private final Map<String, Car> stock;

public CarWarehouse() {

stock = new HashMap<String, Car>();

buildStock();

}

private void buildStock() {

stock.put("Porsche", new Car("Porsche"));

stock.put("Ferrari", new Car("Ferrari"));

}

public Car getCar(final String model) {

return stock.get(model);

}

Now, clients of the CarWarehouse want to checkout cars by name:

class Cars {
    public static void main(String[] args) {		
        final List<String> ids = Arrays.asList("Porsche", "Renault", "Volvo", "Ferrari");
		
        final CarWarehouse warehouse = new CarWarehouse();
		
	final List<Car> cars = ids.stream().map(model-> warehouse.getCar(model)).collect(Collectors.toList());
		
	cars.stream().forEach(car -> System.out.println(car.getName()));
    }
}

class Cars {

public static void main(String[] args) {

final List<String> ids = Arrays.asList("Porsche", "Renault", "Volvo", "Ferrari");

final CarWarehouse warehouse = new CarWarehouse();

final List<Car> cars = ids.stream().map(model-> warehouse.getCar(model)).collect(Collectors.toList());

cars.stream().forEach(car -> System.out.println(car.getName()));

}

The forEach method will crash, because it is trying to call getName on something that is null.

Fine, you might think, I will just filter the stream to remove the objects that are null:

cars.stream().filter(car -> car != null ).forEach(car -> System.out.println(car.getName()));

1	cars.stream().filter(car -> car != null ).forEach(car -> System.out.println(car.getName()));

But that’s just bad.

Type checks breed

Once you need to start filtering your results, once a client of a class A needs to start performing a type check on the values returned to it by that class, you are going to need to repeat those checks every single time you want to use that class A.

Why? Because you expect the values returned by A to be of at least two different types: null and whatever it should actually be returning.

So, how what can I avoid those type checks?

Making your classes meet the expectations they set. Simple as that.

Which, of course, happens to be not that simple. But seriously, if clients of your class are expecting a collection of entities that respond to a particular message (note the Smalltalk-speak), make sure that all the entities your class returns respond to that message. Again, simple as that.

In the previous example, what do I want exactly? I want all the objects returned by CarWarehouse to respond to getName. Then all I have to do is return a collection of objects that respond to getName. And if there is no object to return, then I will return something else that still responds to that message.

The Decorator pattern. Sort of.

Here come the big guns! Design patterns to the rescue! Not too long ago, I ranted about how design patterns are abused.

In this particular case, I m going to adapt one of the patterns in the catalog, the Decorator Pattern, to wrap my Car objects:

class Car {
    private final String name;
	
    public Car(final String name) {
	this.name = name;
    } 
	
    public String getName() {
	return name;
    }
}

class SafeCar extends Car {
    private final Car actualCar;
		
    public SafeCar(final Car car) {
	super(car.getName());
	this.actualCar = car;
    }
	
    public String getName() {
	return actualCar.getName();
    }	
}

class Car {

private final String name;

public Car(final String name) {

this.name = name;

}

public String getName() {

return name;

}

class SafeCar extends Car {

private final Car actualCar;

public SafeCar(final Car car) {

super(car.getName());

this.actualCar = car;

}

public String getName() {

return actualCar.getName();

}

Notice how SafeCar extends Car. That allows me to do the following:

class CarWarehouse {
    private final Map<String, Car> stock;
	
    public CarWarehouse() {
	stock = new HashMap<String, Car>();		
	buildStock();
    }
	
    private void buildStock() {
	stock.put("Porsche", new Car("Porsche"));
	stock.put("Ferrari", new Car("Ferrari"));
    }
		
    public Car getCar(final String model) {
	final Car valueInStock = stock.get(model);
	Car returnValue;
	if(valueInStock == null ) {
	    final Car nullCar = new Car(model+ " is out of stock");
		returnValue = new SafeCar(nullCar);
	}
	else {
		returnValue = new SafeCar(valueInStock);
	}
		
	return returnValue;
    }
}

class CarWarehouse {

private final Map<String, Car> stock;

public CarWarehouse() {

stock = new HashMap<String, Car>();

buildStock();

}

private void buildStock() {

stock.put("Porsche", new Car("Porsche"));

stock.put("Ferrari", new Car("Ferrari"));

}

public Car getCar(final String model) {

final Car valueInStock = stock.get(model);

Car returnValue;

if(valueInStock == null ) {

final Car nullCar = new Car(model+ " is out of stock");

returnValue = new SafeCar(nullCar);

}

else {

returnValue = new SafeCar(valueInStock);

}

return returnValue;

}

Which, as you can see, is basically creating a null object, sort of. Again, I am taking the liberty of adapting the pattern to my needs.

And now, clients of my CarWarehouse can conduct their business merrily:

final List<String> ids = Arrays.asList("Porsche", "Renault", "Volvo", "Ferrari");
		
final CarWarehouse warehouse = new CarWarehouse();
		
final List<Car> cars = ids.stream().map(model-> warehouse.getCar(model)).collect(Collectors.toList());	
cars.stream().forEach(car -> System.out.println(car.getName()));

final List<String> ids = Arrays.asList("Porsche", "Renault", "Volvo", "Ferrari");

final CarWarehouse warehouse = new CarWarehouse();

final List<Car> cars = ids.stream().map(model-> warehouse.getCar(model)).collect(Collectors.toList());

cars.stream().forEach(car -> System.out.println(car.getName()));

Summary

What matters are not the tools you have, but how you use them. Over-abstraction is bad. Over-engineering is bad. Knowing the tools in your belt, knowing how to adapt them and how to let them work together to solve your needs is what matters.

Oh, and sometimes, you need something to help you deal with nothing.

Posted on April 7, 2015 by sexysoftwareengineer

Principle of least surprise

Another Principle! I am on a roll! Although, to be honest, this is not an actual principle.

If you work for a serious company, you would most likely have one of these printed out and hanging from one of your office’s walls. If you don’t have it, now you have something to do today.

wtfm

When it comes to source code, this principle can be summarised as:

Don’t try to be a smartass. Write code that is easy to understand.

Oh, noes! Is this another rant about semantic code?

Actually, no, it is not, thanks for asking. I would not say it is a rant, I would say it is a more like unwanted advice, but about something else.

The offending code.

This code, slightly edited to protect the innocent, was extracted from an actual codebase my team has to maintain.

import java.util.Map;
import java.util.HashMap;

class SmartClass {
	public static void smartMethod(Map<String, String> metadata) {
		for(Map.Entry<String, String> entry : metadata.entrySet()) {
			if(entry.getKey().equals("key1")) {
				/* Do whatever you need to do with the value 
				that corresponds to key1
				*/
				System.out.println(entry.getKey() + " - " + entry.getValue());
			}
			if(entry.getKey().equals("key3")) {
			/* Do whatever you need to do with the value 
			that corresponds to key3
			*/				
				System.out.println(entry.getKey() + " - " + entry.getValue());
			}			
		}
	}
}

class Surprise {
	public static void main(String[] args) {
		Map<String, String> metadata = new HashMap<String, String>();
		metadata.put("key1", "value1");
		metadata.put("key2", "value2");
		metadata.put("key3", "value3");		
		
		SmartClass smartClass = new SmartClass();
		smartClass.smartMethod(metadata);
	}	
}

import java.util.Map;

import java.util.HashMap;

class SmartClass {

public static void smartMethod(Map<String, String> metadata) {

for(Map.Entry<String, String> entry : metadata.entrySet()) {

if(entry.getKey().equals("key1")) {

/* Do whatever you need to do with the value

that corresponds to key1

System.out.println(entry.getKey() + " - " + entry.getValue());

}

if(entry.getKey().equals("key3")) {

/* Do whatever you need to do with the value

that corresponds to key3

System.out.println(entry.getKey() + " - " + entry.getValue());

}

class Surprise {

public static void main(String[] args) {

Map<String, String> metadata = new HashMap<String, String>();

metadata.put("key1", "value1");

metadata.put("key2", "value2");

metadata.put("key3", "value3");

SmartClass smartClass = new SmartClass();

smartClass.smartMethod(metadata);

}

There are plenty of WTFs here. But the one that stands out the most is on smartMethod: why on earth would I loop all the entries in a Map only to act upon those that match a set of constant, immutable, known keys?

Isn’t our life complicated enough, as it is? Why do we want to make our code more difficult to read and understand, for the shake of a flexibility that may or might not be necessary? A flexibility that, at least in this example, is not even flexibility at all?

Do the simple thing first.

Instead of looping the map keys looking for something we already know is there… why not just ask for it?

import java.util.Map;
import java.util.HashMap;

class SmartClass {
	public static void smartMethod(Map<String, String> metadata) {
		/* Do whatever you need to do with the value 
		that corresponds to key1
		*/		
		System.out.println("key1" + " - " + metadata.get("key1"));
		/* Do whatever you need to do with the value 
		that corresponds to key3
		*/				
		System.out.println("key3" + " - " + metadata.get("key3"));
	}
}

class LeastSurprise {
	public static void main(String[] args) {
		Map<String, String> metadata = new HashMap<String, String>();
		metadata.put("key1", "value1");
		metadata.put("key2", "value2");
		metadata.put("key3", "value3");		
		
		SmartClass smartClass = new SmartClass();
		smartClass.smartMethod(metadata);
	}	
}

import java.util.Map;

import java.util.HashMap;

class SmartClass {

public static void smartMethod(Map<String, String> metadata) {

/* Do whatever you need to do with the value

that corresponds to key1

System.out.println("key1" + " - " + metadata.get("key1"));

/* Do whatever you need to do with the value

that corresponds to key3

System.out.println("key3" + " - " + metadata.get("key3"));

}

class LeastSurprise {

public static void main(String[] args) {

Map<String, String> metadata = new HashMap<String, String>();

metadata.put("key1", "value1");

metadata.put("key2", "value2");

metadata.put("key3", "value3");

SmartClass smartClass = new SmartClass();

smartClass.smartMethod(metadata);

}

Now, if you look at that code carefully, if you look at any piece of simple, dumb code, carefully, you will instantly hear it screaming at you, shouting everything is wrong with itself.

In this example, the smartMethod has an expectation on which keys in a Map it will need to use. That tells you that a Map is not the right type for that parameter: maybe two strings would do?

Summary

Keep it simple. Do not try to impress anyone. Seriously, your skills as developer are not directly proportional to how obscure your code is.

The Amazing Adventures of a Sexy Software Engineer

Category: Java

Things I like about Java: Anonymous classes

Elegant Swift: Default Parameters vs The Builder Pattern

Primitive obsession

Primitive what!?

Promoting primitives to objects

Isn’t that unnecessary complexity?

Sometimes nothing is something. Or the null object pattern with a touch of the decorator pattern

If clauses breed, and sometimes, nothing is something

Type checks are bad

Type checks are a sign of bad design

There is a particularly bad type of the check

Type checks breed

So, how what can I avoid those type checks?

The Decorator pattern. Sort of.

Summary

Principle of least surprise

Oh, noes! Is this another rant about semantic code?

The offending code.

Do the simple thing first.

Summary