The Practical Difference Between Abstract Classes and Traits in Scala

This short article will compare abstract classes and traits as means of inheritance. This is for the beginner Scala programmer who is just getting started with Scala's inheritance model. If you're trying to figure out which is the best way to create OO-style type hierarchies and abstract classes seem too similar to traits, this article is for you.

You can read this article over at Rock the JVM or watch it on YouTube or in the video below:

SOLID code, the Silver Bullet

SOLID is one of those words we developers throw around us, implying some deeper meaning, hopefully helping us to create better software systems. It should be second hand nature to all (OO) developers, but unfortunately is often misunderstood, or used to defend a decision, based upon flawed logic. Hence, in this article, I will try to "dumb it down" and use analogies for each of its 5 items, in an attempt at making it more easily understood, to avoid confusion.

Single Responsibility Principle

The "S" I'm solid implies that each class should only do one thing. It often helps to break down your flow into verbs to make sure you follow this principle. For instance, imagine you have a task scheduler, that should implement the ability to create tasks for execution at some point into the future. Maybe you want it to have the ability to persist tasks, in case the process is recycled, without dropping tasks. Imagine Hangfire here as an example. Well, ask yourself how many verbs you have in the above feature requirement, and then try to group them into related actions. I could find the following.