2. Single Responsibility Principle (SRP)

Question 1

What are the SOLID principles comprised of?

Answer 1

Five individual principles for writing better software, especially in object-oriented languages.

Question 2

What does the SRP state?

Answer 2

Each software module should have one and only one reason to change.

Question 3

What is a module in the context of a C# program?

Answer 3

A module in C# might refer to a class or even a single function.

Question 4

How can we improve the design of our software when it comes to the proximity between what the application does and how it does it, and how?

Answer 4

By separating the “what” from the “how”. We do this through delegation and encapsulation.

Question 5

How can we improve the design of our software when it comes to the proximity between what the application does and how it does it, and how?

Answer 5

By separating the “what” from the “how”. We do this through delegation and encapsulation.

Question 6

What should the classes encapsulate?

ps. Encapsulation in the general sense.

Answer 6

Doing a particular task in a particular way.

Question 7

What can be said about single-purpose classes?

Answer 7

They do a single particular task in a particular way, and they are easy to use.

Question 8

What can be said about the performance of multipurpose tools vs dedicated tools?

Answer 8

Multipurpose tools don’t perform as well as dedicated tools.

Question 9

What can be said about the performance of multipurpose tools vs dedicated tools?

Answer 9

Multipurpose tools don’t perform as well as dedicated tools.

Question 10

What is a responsibility in the context of the SRP?

Answer 10

It’s the answer to the question of how something is done.

It’s a decision our code is making about the specific implementation details of some part of what the application does.

Question 11

What are some examples of responsibilities?

Answer 11

1. Persistence
2. Logging
3. Validation
4. Business Logic

Question 12

What do responsibilities in our code represent in regards to change and the SRP?

Answer 12

Responsibilities represent things that may change at different times and for different reasons — each responsibility is a different axis of change.

Question 13

What happens when two or more details are intermixed in the same class?

Answer 13

It introduces tight coupling between these details.

Question 14

What is tight coupling?

Answer 14

Binding two or more details together in a way that’s difficult to change.

Question 15

What’s the difficulty that tight coupling brings?

Answer 15

If the tightly coupled details change at different times for different reasons, it’s likely to cause problems in the future with code churn in the class in question.

Question 16

What’s the difficulty that tight coupling brings?

Answer 16

If the tightly coupled details change at different times for different reasons, it’s likely to cause problems in the future with code churn in the class in question.

Question 17

What does loose coupling offer?

Answer 17

A modular way to choose which details are involved in a particular operation.

Question 18

What is a typical example of loose coupling?

Answer 18

One class being responsible for some high-level concern and delegating to other classes who are responsible for the details of how to perform low-level operations.

Question 19

What is a typical example of loose coupling?

Answer 19

One class being responsible for some high-level concern and delegating to other classes who are responsible for the details of how to perform low-level operations.

Question 20

What does the seperation of concerns state?

Answer 20

That programs should be separated into distinct sections, each addressing a separate concern or set of information that affects the program.

Question 21

What can be thought frequently of as low-level plumbing code?

Answer 21

The specific implementation details of how a program does something.

Question 22

What is the key benefit of following the separation of concerns?

Answer 22

That high-level business logic avoids having to deal with low-level code.

Question 23

What should ideally be the case in regards to high-level and low-level code’s knowledge of one another?

Answer 23

High-level code should not know about how low-level implementation details are implemented, nor should it be tightly coupled to the specific details.

Question 24

What does cohesion describe?

Answer 24

How closely related the elements of a class or module are to one another.

Question 25

What makes a class less cohesive?

Answer 25

The fact that its methods don’t share much data or behaviour with one another.

Question 26

What makes a class less cohesive?

Answer 26

The fact that its methods don’t share much data or behaviour with one another.

Question 27

What do relationships between classes represent?

Answer 27

Coupling.

Question 28

What do relationships within each class (between methods, properties, etc.) represent?

Answer 28

Cohesion.

Question 29

Why is loose coupling favoured over tight coupling?

Answer 29

Because it results in code that is easier to change and test.

Question 30

What can be said about responsibilities in relation to testability?

Answer 30

As many responsibilities a class have, as difficult it is to test them — especially when single methods are doing a lot of different things.

Question 31

What do tests become for a given class when that class have many responsibilities?

Answer 31

1. Longer
2. More complex
3. Brittle
4. Coupled to implementation

Question 32

What are the four main takeaways of this module?

Answer 32

1. Practice Pain-Driven Development (PDD)
2. Each class should have a single responsibility or reason to change
3. Strive for high cohesion and loose coupling
4. Keep classes small, focused, and testable