![]() apply business rules based on the course type live, online, offline, if any Public bool SaveCourse(Student std, Course cs) use EF to add a new student or update existing student to db Now, look at the following classes redesigned after applying SRP using the above considerations for SRP. So, it's better to create a separate Logger class that is responsible for all the logging activities. For example, if the admin decides to log all activities in the text file then you need to change the Student class. Any changes in the logging requirement would cause the Student class to change. Here, all the activities are logged on the console using the hard-coded Console.WriteLine() method. Sending confirmation emails is also a part of the Subscribe() method, so it will be a part of the Course class now.Īlthough, we will create a separate class EmailManger for sending emails. So it is idle to move the Subscribe() method to the Course class. The Subscribe() method is more suitable for the Course class because a course can have different subscription rules based on the course type. This way if any changes on the DB side then we may need to change only the StudentRepository class. StudentRepository class should be created for all CRUD operations for the Student. ![]() We should move the underlying EF code to another class to do all DB operations e.g. Although, it uses Entity Framework to do the CRUD operation which is another reason to change the Student class. The Save() and Delete() method is also specific to a student. Except for the Subscribe() method, all the properties and methods are related to the student, so keep all the properties. The Student class should contain all the properties and methods which are specific to the student. Start with each responsibility mentioned above and decide whether we should delegate it to other classes or not. Let's change the Student class considering SRP where we will keep only one responsibility for the Student class and abstract away (delegate) other responsibilities to other classes. SRP tells us to have only one reason to change a class. Thus, you have many reasons to change the code because it has many responsibilities. Or, if you need to change the business rules (validation) before deleting a student or subscribing to a course, or change the logging medium from console to file, then in all these cases you need to change the code of the Student class. Or, if you need a change in the database, maybe moving from a local server to a cloud, then you need to change the code of the Student class. If anything in the above responsibility changes, then we will have to modify the Student class.įor example, if you need to add a new property then we need to change the Student class. Send confirmation email to a student upon successful registration. ![]() Apply business rules to subscribe to courses based on the course type.Save a new student, or update an existing student to a database.ĭelete existing students from the database if not subscribed to any course. Holds student's properties such as StudentId, FirstName, LastName, and DoB. The above Student class has the following responsibilities: Let's check how many responsibilities the following Student class has: You can think of these points as functionalities or features or responsibilities.Ĭhange in any functionality leads to change in the class that is responsible for that functionality. ![]() For example, an online e-commerce application has many features such as displaying product lists, submitting an order, displaying product ratings, managing customers' shipping addresses, managing payments, etc.Īlong with these features, it also validates and persists products and customers' data, logs activities for auditing and security purposes, applies business rules, etc. Now, the question is what is responsibility?Īn application can have many functionalities (features). If a class has more than one responsibility, then there will be more than one reason to change the class (code). In other words, a class should have only one responsibility and therefore it should have only one reason to change its code. ![]() Each software module should have one and only one reason to change. ![]()
0 Comments
Leave a Reply. |