![]() This gives us the best of both worlds! !commentForm -r You simply put the methods that change for different reasons into different source files. And yet we can also keep the methods in the same class, and therefore in the same object! So, in Ruby, there is a way to put the methods in a class that belong in that class, without having to violate the SRP. But with a little care and abstraction we can keep the source files quite nicely decoupled. We could couple these source files being clumsy with access to variables. Clearly one has to be careful with variables. This means that the concepts in these three source files are not coupled. Indeed, the three source files know nothing about each other at all. And yet no single source file contains the three different functions. In the main program we miight see something like: require 'employeeBusinessRules.rb' require 'employeeDatabaseSave.rb' require 'employeeHourlyReport.rb' Thus, the class will be complete before the rest of the program begins to execute. The code above is part of the program execution) classes may be opened up at any time during program execution and more methods and variable may be added to them. end end Since classes in ruby are constructed at run time (i.e. end end employeeHourlyReport.rb class Employee def reportHours. end end employeeDatabaseSave.rb class Employee def save. Consider the following three files: employeeBusinessRules.rb class Employee def calculatePay. However, in Ruby the situation is a little different. We don't want business rules coupled to report formats, and so we need to put these functions in different classes. However, decoupling tends to trump ideals like this. Of course this seems to fly in the face of OO concepts since a good object should contain all the methods that manipulate it. Rather, we want to separate these functions out into different classes so that they can change independently of each other. We don't want to modify the Employee class every time the accounts decide to change the format of the hourly report, or every time the DBAs make a change to the database schema, as well as every time the managers change the payroll calculation. We don't want a single class to be impacted by these three completely different forces. The third is the format of the string that reports hours. The first is the business rules having to do with calculating pay. As an example, imagine the following class in Java: class Employee This class violates the SRP because it has three reasons to change. ![]() To say this a different way, the methods of a class should change for the same reasons, they should not be affected by different forces that change at different rates. ![]() SRP in RubyThe Single Responsibility Principle (SRP) says that a class should have one, and only one, reason to change. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |