Search Results

Search found 3 results on 1 pages for 'user1483278'.

Page 1/1 | 1 

• Something confusing about Single Responsibility Principle

  - by user1483278

  1) In fact if two responsibilities are always expected to change at the same time you arguably should not separate them into different classes as this would lead, to quote Martin, to a "smell of Needless Complexity". The same is the case for responsibilities that never change - the behavior is invariant, and there is no need to split it. I assume even if non-related responsibilities are always expected to change for the same reason ( or if they never change ), we still shouldn't put them in the same class, since this would still violate high cohesion principle? 2) I've found two quite different definitions for SRP: Single Responsibility Principle says that a subsystem, module, class, or even a function, should not have more than one reason to change. and There should never be more than one reason for a class to change Doesn't the latter definition narrow SRP to a class level? If so, isn't first quote wrong by claiming that SRP can also be applied at subsystem, module and function levels? thank you

  Read the article

• How to determine if class meets single responsibility principle ?

  - by user1483278

  Single Responsibility Principle is based on high cohesion principle. The difference between the two is that highly cohesive classes feature a set of responsibilities that are strongly related, while classes adhering to SRP have just one responsibility. But how do we determine whether particular class features a set of responsibilities and is thus just highly cohesive, or whether it has only one responsibility and is thus adhering to SRP? Namely, isn't it more or less subjective, since some may find class very granular ( and as such will consider a class as adhering to SRP ), while others may find it not granular enough?

  Read the article

• I know of three ways in which SRP helps reduce coupling. Are there even more? [closed]

  - by user1483278

  I'd like to figure all the possible ways SRP helps us reduce coupling. Thus far I can think of three: 1) If class A has more than one responsibility, these responsibilities become coupled and as such changes to one of these responsibilities may require changes to other of A's responsibilities. 2) Related functionality usually needs to be changed for the same reason and by grouping it togerther in a single class, the changes can be made in as few places as possible ( at best changes only need be made to the class which groups together these functionalities) 3) Assuming class A performs two tasks ( thus may change for two reasons ), then number of classes utilising A will be greater than if A performed just a single task ( reason being that some classes will need A to perform first task, other will need A for second task, and still others will utilise it for both tasks ).This also means that when A breaks, the number of classes ( utilising A ) being impaired will be greater than if A performed just a single task. Can SRP also help reduce coupling in any other way, not described above? Thank you

  Read the article

1