Design principles

Question 1

KISS

Answer 1

The main concept of this pattern is to keep as simple code as possible.
That means each method, class, interface should be names as clear as possible and also logic inside functions, method etc. should be clear and simple as it can be.

Question 2

DRY

Answer 2

Do not repeat yourself
This concept is advising us to divide code that does the same thing to small parts.
Sometimes we have multiple lines of code basically doing the same: like filter by array with specified criteria, adding some things to object etc.
Usually good practice is to get rid of it.

Question 3

TDA: Tell don’t ask

Answer 3

This principle suggest that we should write code in a way that object behave rather then in what state they are in.
This can avoid unnecessary dependencies between classes and thanks to that have more maintainable code. It is strongly related to code encapsulation.

Question 4

SoC: Separation of Concerns

Answer 4

This principle is telling us to separate responsibility of a single class to this class and this class only. Objects should not share what they do.
Each class should be unique and separated from the rest.

Question 5

YAGNI: You ain’t gonna need it

Answer 5

That principle is not telling us how to do something in code directly, but rather how to code effectively.
In general it says that we should code only things that are required from us in this particular moment.
For example: when we will have to do validation of email and password field, we shouldn’t do validation of name, because we may never need it.
It is really as TDD : we write test only for micro feature and write minimal code required to work on that.
YAGNI is trying to save us time and focus on most important things in our sprint.

Question 6

S - Single Responsibility Principle

Answer 6

A module should be responsible to one, and only one, actor

While we all agree that focusing on a single responsibility is important, it’s difficult to determine what a class’s responsibility is. Generally, it is said that anything that gives a class a reason to change can be viewed as a responsibility. By change I am talking about structural changes to the class itself (as in modifying the code in the class’s file, not the object’s in-memory state)

Question 7

0 - Open/Closed Principle

Answer 7

The Open/Closed Principle states that classes or methods should be open for extension, but closed for modification. This tells us we should strive for modular designs that make it possible for us to change the behavior of the system without making modifications to the classes themselves. This is generally achieved through the use of patterns such as the strategy pattern.

Question 8

DI

Answer 8

Модный механизм отделения конструирования от использования