SOLID Principles -> Single Resposibility

[banchiang]

Description

As I was revising for PE2 (which I got destroyed by), I understood a bit more about the SOLID principle but am still unsure about the (S)ingle Responsibility principle. I know that a responsibility can be made up of many methods (1 method != 1 responsibility). So my questions are:

1. What exactly is a responsibility? Does anyone know a website that explains well or anyone can explain it in layman terms or with good examples?

2. For my labs, I have minimum classes and each class is doing a few things. For example for Lazy class in lab7 it contains methods get(), compareTo(Lazy), map(function), flatmap(function), toString() , test(Predicate), equals(object). Is it defying the (S) in the SOLID principle? If it is, how exactly could I have done it?

https://www.baeldung.com/solid-principles

Topic:

SOLID Principles (OOP)

Screenshots (if any):

NIL

[jedlwk]

Similar, I got rekt real hard by PE2 real bad... I am not very accurate on this either but this is my 2cents to share! Please do correct me if I am mistaken too!

From my understanding, the Single Responsibility Principle essentially means that every class you have should only have 1 job to do! However, the confusing part would be: What is that 1 job? That 1 job usually points towards having 1 purpose. However, that does not mean that it can only mean 1 method! Which probably explains why you can have so many methods in your Lab 7. (Second Point)

For example, in your Circle Class, you can have a few methods such as getPerimeter or getArea. However, what would violate the Single Responsibility Principle, is that if you have separate responsibilities. For example, for a Parking Class, you have methods like get(VehicleID), calculate(ParkingFee), compare(ParkingRates). This principle encourages you to split the class into 3 and each having one responsibility.

I hope this clarifies a little! :)

[leeleonard98]

I think we cannot really apply this to the labs because it is slightly different and the more important part of lab is about learning the methods and functions etc. It may be more applicable to like our Project, where sometimes they will not give u the classes required. So u need to come up with like ur own classes and ensure that it serves only 1 purpose which could be like returning just a server or maybe just a customer. We could have just put all the events together and use it as a string etc, but it wont be clear and will not have a single purpose... So i think thats generally how the single responsibility principle is

[jj-weng]

I feel that our labs are generally too short for us to really appreciate SOLID principles. Firstly, cause I don't think CodeCrunch will detect if you have more than one responsibility in a class and secondly, we are working on our project and lab on our own, so even when we violate SRP and we are required to change any methods, we know exactly where to find it! However, in larger scale projects where we are working with others, then violating SRP will be a much more annoying issue. If another of your teammate wants to change a method in Circle but you have placed that method under Point (exaggerated example but yeah), then there will be more issues.

[GnohChengYi]

From my understanding, "responsibility" in our context just means the class is responsible with what it is being named as. A "responsibility" can be further broken down into multiple small "responsibilities", which could be handled by other classes. Each class provides an abstraction to the level of responsibility, and only does things that is of the same abstraction level. Feel free to correct me if I am wrong.

[tomjoju]

The more responsibilities your class has, the more often you need to change it and your classes will no longer be independent of each other. As long as one of its responsibilities change, you need to change the class (which is more than if it only had one responsibility). This becomes a big deal in larger-scale projects as it also affects all classes that depend on the changed class. The effect of a change can multiply as your project becomes bigger and more complex, making it super troublesome and inconvenient.

For example, you could have a Book class whose only responsibility is to store information about books. Now, if you add a method to print the text of the book to the console, you would be violating this principle. Using this principle, you should split the responsibilities and create a new class, BookPrinter, that is concerned with only printing of text.

In practice, this is much harder to follow through; when do you know what method will be violating this principle and how do you know which responsibilities to split into smaller ones? I am still not too sure about this myself and I think the more projects we undertake, the better we will get. These are a few links that may help you: https://www.baeldung.com/solid-principles https://www.edureka.co/blog/solid-principles-in-java/ https://stackify.com/solid-design-principles/

[limyingying2000]

It means that ideally, we should design our class such that each class is in-charge of one main purpose, but we can have multiple small methods in the class to support and help to meet this purpose. Similar to how we can have multiple workers or teammates to accomplish a project or task or job!