SOLID Principles – Single Responsibility Principle


a class should have only a single responsibility

This is my favorite principle of all. It is the easiest to violate and thus in my opinion, not respecting it is the most common issue I find when I review code. Many people I talk to, mistakenly think that the SRP is trying to keep classes short, but it is much more than that.

Let’s discuss an example. Imagine that we are writing an application for a classic store type business who specializes in selling construction material. We will probably end up having two classes like this.

class Order
{
	IEnumerable<OrderItem> Items { get; set; }
	ClientInformation ClientInfo { get; set; }
	ShippingInformation ShippingInfo { get; set; }
}

class ReportCreator
{
	// Adds an image to specific coordinates
	void AddImage() { }
	// Adds text to specific coordinates
	void AddText() { }
	// Adds table data to specific coordinates
	void AddTable() { }
}
Continue reading

SOLID Principles – Intro

You must be thinking “Great, another schmuck who tries to explain them, the internet doesn’t need another series dedicated to SOLID!” You are right, this topic has been explored many times before, and certainly you will find better explanations out there. Every year thousands of new students enter the workforce in our wonderful industry. Even if there were courses in their University, or made the research themselves, only after they build up more experience can they truly cherish these simple, and in the same time complex principles.

To explain it better, let me use some chess analogy. I love this game and you will see if you follow my writing that I draw great inspiration from it. It heavily influenced the way I work and I apply a lot of habits, which I learned while playing. Try to guess who is better in this position.

Continue reading

How to become a better software developer?

Well isn’t this the million dollar question? I’m a firm believer that, this needs to be answered to each person in a very individual and personalized manner, there is no golden answer to this, and you should search for an answer by discussing to people who you trust and accept feedback from.

That being said, there is something that worked to a certain extent for everybody who tried it out.

Don’t jump to coding right away. This is a mistake done by many, especially at an early stage of their career. After selecting a task, they jump into carrying out the modifications as much as they can, and after that they improvise the rest, or search for help. A reason for this could be that thinking was done while looking at the code instead of a disconnected manner.

Maybe next time start a task by trying to better visualize the outcome of it. Write out the main changes you intend to do in each component, this can serve as a “checklist” later to verify if you forgot anything.

Try drawing how the information will flow between components, not full fledged UML diagrams, just some boxes and lines on a piece of paper will do.

These practices will help you in many ways, for instance

  • You can discover early, which parts of the code you understand, and which parts you don’t. It is a good idea to invest some time to get a deeper understanding of the area you are about to change
  • You will get help a lot easier from more experienced peers, when you reach out to them. Your questions will be more coherent, more precise, plus you will gain a lots of points from them for working out a solution, instead of simply asking, “how should I do this?”
  • You will explain better. When talking to the project manager, client, even in just simple presentations, describing the issue efficiently can leave a very good impression on others. Remember if you look like a professional and sound like a professional …

Change takes time, so be patient with yourself!