SRP exercise

#
# SRP - Single Responsibility Principle
#

Each software module should have only one reason to change.

Gather together those things that change for the same reason, and separate those things that change for different reasons. - Robert C. Martin

Example:
Imagine you took your car to a mechanic in order to fix a broken electric window. He calls you the next day saying it is fixed. When you pick up your car, you find the window works fine; but the car won’t start.

That’s how customers feel when we break things they care about that they did not ask us to change.

This principle is about people: When we write a software module, we want to make sure that when changes are requested, those changes can only originate from a single person (or the same group of people).

Do not mix together code that different people care about for different reasons.

Conclusion:
* It could mean breaking code apart, violating traditional OOP rules, or introducing duplicate code. It's taking one step backward to go two steps forward.
* Unfortunately, we usually don't find out what that one thing is until we've reached the end of it.


#
# Bad Example
#

* changes in ICustomer may be requested from at least two different people: logging, user registration, sending email 
* when the logging aspect changes, then it also has an impact on the business code (user registration, sending email)

interface ICustomer
{
	bool Register(string email, string username, string password);
	bool Login(string username, string password);
	void LogError(string error);
	void LogInfo(string error);
	void LogDebug(string error);
	bool SendEmail(string email, string content);
}

#
# Good Example
#

* by separating all aspects into separate interfaces we make sure that changes effect only small parts in the code base

interface ICustomer
{
	bool Register(string email, string username, string password);
	bool Login(string username, string password);
}

interface ILogger
{
	void LogError(string error);
	void LogInfo(string error);
	void LogDebug(string error);
}

interface IEmail
{
	bool SendEmail(string email, string content);
}


#
# Exception to the rule
#

* separating every little peace into a tiny interfaces/classes/functions, may lead to ravioli code - code that is easy to understand in isolation, but difficult to understand as a whole
* mixing certain aspects may actually improve readability and make it easier to work with the code

interface ICustomer
{
	bool Register(string email, string username, string password);
	bool Login(string username, string password);
	bool SendEmail(string email, string content);
}

interface ILogger
{
	void LogError(string error);
	void LogInfo(string error);
	void LogDebug(string error);
}