Composition over inheritance

Composition over inheritance is recently animating the debate on the web. In the previous session, we talked about the the SOLID principles, and also about Liskov:

LSP – Liskov Substitution Principle: inherited objects must have the same properties of the main object (and each property the same characteristics). Can Rectangle inherits from Square? And Square from Rectangle? The answer is use a common base class: Rectangle ← Shape, Square ← Shape [jump to the video]

let’s see how composition could fit to this principles.

Here you have a classic example about inheritance:

We face the first issues with the Kiwi, a cute bird from New Zeland that is know for his inability to fly. We also have issues with the Bat, that can fly but he’s inheriting from Mammal, who can’t.

What about moving the fly method out of Bird, and put it directly to each animal who can fly?

This will introduce lots of duplication, that it’s evil.

Another solution is to put the fly method inside the Animal, in order to avoid code duplication. This exposes all animal to it, also the ones who shouldn’t be able to fly.

So, until now we saw how using inheritance leads to issues that produces code hard to maintain. Let’s try to structure the animal in a different way, to compose them.

Swift allows you to use Protocols, something similar to interfaces in Java. The ability to fly moves from the Animal subclasses to the protocol. Also, with Swift 2 you have the ability to add protocol extensions, that can be used to define default behaviours. In this case, composition helps to assign the ability to fly just to the animals that needs it. That’s sound reasonable, but do we really need all these classes that defines all animals in the entire Earth? Can’t we try to extracts the abilities they have and build different animals that could share same abilities?

The idea is to create as much protocols you need: in our case, a Mover (for flying, walking, etc.) and a SoundMaker (for animal noises). The animals can now be initialised with  a name, a soundMaker and mover during initialisation. This is composition: instead of trying to fit all the abilities  of a class or object into inheritance, we now during instantiation inject abilities themselves, so we can put together our birds, swifts or dogs objects without having a class that defines them.

In the previous example we got rid of inheritance at all, but we can bring back subclasses in a useful way. Inheritance is used basically for two purposes:

  • taxonomy: a mammal is an animal, a dog is mammal, etc.
  • factories: create factory methods with standard behaviours

This is the final example. The code is basically the same, but we created something that has nothing to do with animals, even if we can still use the protocols created in precedence.

Breaking up stuff in fine grained protocols rather than rusty inheritance hierarchies gives us code that is not only easy to maintain, but also very likely easy to be reused.

It’s hard to specify rules for composition over inheritance. Enthusiasts would say to start always from composition and avoid inheritance. The truth is that inheritance is useful when defining relationships, but doesn’t make sense for abilities, code with logic.

In general, for taxonomy approach is fine using inheritance, but abilities and logic should use the composition approach.

Thanks again to vikingosegundo that manage to prepare these nice snippets.

That’s it for this session. As always, if you have any hint, please drop us a line here.
Stay tuned.
Have fun.

SOLID: The single most important Software Design Principles

For this episode of TKSS we’ll share with you an extract of the recorded session we had here at Blinkist.

We wanted to have a session about software quality and tools that helps improving it, but then vikingosegundo thought was a good idea to have all the developers aligned on what he thinks are the most important software design principles.

Here the blinked version of the presentation: we suggest you to quickly read trough it before watching at the recording. The presentation explains the 5 principles and provides some examples in Swift from our iOS projects.

SOLID stays for Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion and is a mnemonic acronym introduced by Uncle Bob for the “first five principles”.

SRP – Single Responsibility Principle: you should define the functionalities you want from your software, and link each class to one clear responsibility. [jump to the video]

OCP – Open / Closed Principle: two definitions of this principle exists, but you should probably refer to the Polymorphic open/closed principle. When you create a class, keep in mind you could need to extend it via inheritance (OPEN), but you should never change the basic interface (CLOSE). [jump to the video]

LSP – Liskov Substitution Principle: inherited objects must have the same properties of the main object (and each property the same characteristics). Can Rectangle inherits from Square? And Square from Rectangle? The answer is use a common base class: Rectangle ← Shape, Square ← Shape [jump to the video]

ISP – Interface Segregation Principle: splits interfaces which are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them. [jump to the video]

DIP – Dependency Inversion Principle: use dependency injection and you’ll follow this principle. [jump to the video]

That’s it for this session. As always, if you have any hint, please drop us a line here.
Stay tuned.
Have fun.

React, Flux and Reflux

Last week we hosted a short introduction to React and Flux.


React is a library for building composable user interfaces. It encourages the creation of reusable UI components which present data that changes over time, that works with a mocked DOM and updates it when needed

  • render() method returns a virtual DOM structure which is, upon state changes, reconciled against the real DOM

DOM mutations are slow, and this is why React creates a virtual copy of the DOM to work with. Even if the idea of refreshing the entire DOM intimidates you, the framework is using a diff mechanism in order to ensure to update the minimum amount of changes. React conceptually hits the “refresh” button, and knows to only update the changed parts.

  • Instagram is a “single page” web app built entirely with React and Backbone.Router. Designers regularly contribute React code with JSX

Screen Shot 2015-10-19 at 12.38.03


Flux is a new sw architecture paradigm that moves away from the MVC ( MVVC ): adding features to a realtime web app increases complexity in a way that becomes difficult to handle all interactions between data and visualisation. With Flux, data moves in one direction through your application. Flux keeps things predictable – A Flux Diagram for a complex system is just as complex as MVC. But as the flow is unidirectional, it is more predictable.


These are the main components:

  • Actions – Helper methods that facilitate passing data to the Dispatcher
  • Dispatcher – Receives actions and broadcasts payloads to registered callbacks
  • Stores – Containers for application state & logic that have callbacks registered to the dispatcher
  • Controller Views – React Components that grab the state from Stores and pass it down via props to child components.
  • API – If you have external API access, then its probably better to use this with Actions and then Stores

Now let’s look at the flow:

  1. The component handles the form submission by calling its own callback
  2. The component callback calls a method on the ToDoActionCreator
  3. The ToDoActionCreator creates an action of the type TODO_CREATE 
  4. The Dispatcher passes the action to all registered callbacks from Stores 
  5. The ToDoStore has a registered callback that listens for the TODO_CREATE action, and updates its own data 
  6. The ToDoStore fires a change event after updating its data 
  7. The ToDoApp component is listening for change events from the ToDoStore, and re-renders the UI based on the latest data from the ToDoStore  

Flux Cons:

  1. It involves writing more boilerplate code
  2. Migrating existing resources can be a big task
  3. For big applications, a good structure is essential
  4. Unit testing can be difficult


Reflux takes the flux approach and streamlines it, making it both easier to work with and easier to grasp. Let’s first have a look on some code.

The main advantage of Reflux is that each action acts like a dispatcher and also eliminates action creators. Actions are functions themselves. Each store listen to actions; this means that they are no longer receiving all the actions that occur in the application and filter them with a switch statement. Moreover, listening to store’s state changes in React components is very easy using Reflux.connect method.


Hope that you find useful information about React, Flux and Reflux here. This was the first post from Blinkist’s dev team. If you have any hint, please drop us a line here.

Special thanks to dinks that presented the concept internally at Blinkist.


ReactJS fiddle

ReactJS Chrome extension to debug

Atlasssian Blog (Flux)

What is Flux

Getting to know Flux

What is the Flux Application Architecture

Flux vs. Reflux

Flux > Reflux?

Github Reflux

Comparing RefluxJS with Facebook Flux