New answers tagged

-3

Well, it depends on how you want to look at it. Another way is: "Is Single Responsibility Principle violating Domain Entity?" Both are guidelines. There is no "principle" anywhere in software design. There are, however, good designs and bad designs. Both these concepts can be used in different ways, to achieve a good design.


1

I would definitely go with a separate method, maybe even a separate class. The reason is not only SRP, but OCP too. Of course, if it is always the same format that the data is to be converted to and there is little chance of that format changing, then there is really no need to overdesign the code.


1

You use common sense. I might care a lot about whether the user is an administrator and add a method for that. I might care a lot about the user service object of the controller and use it a lot, for all the purposes that a user service object is designed to be used for. In that case I'd add a method for the user service object. I suspect that I don't ...


0

Your approach is fine. Immutability is a strong assertion. The only thing I would ask is: Is there any other place where you construct the object. If your object was not immutable you would have to answer additional questions because "State" is introduced. And the state change of an object may occur on different reasons. Then you should know your cases and ...


1

Two points: I prefer methods like these because they help break up method trains like: myObject.getFoo().doBar().tooManyCalls() (i.e. Train Wrecks) However, If you find yourself writing several of these "shortcut" methods you may very well have a bigger/better refactoring that you can take advantage of. See Bob Martin's book "Clean Code" and code-smell ...


5

Is creating methods such as isUserAdmin() bad practice? It is, though it isn't so much that this method is bad practice, but rather using a parent class as a dumping ground for methods you want to share with the child objects but that don't have any particular relationship to each other in terms of behaviour is a bad idea. If the method was a core ...


13

As with any rule, I think the important thing here is to consider the purpose of the rule, the spirit, and not get mired in analyzing exactly how the rule was worded in some textbook and how to apply that to this case. We don't need to approach this like lawyers. The purpose of the rules is to help us write better programs. It's not like the purpose of ...


1

So far everyone here is talking about classes. But think about it from an interface perspective. If an interface method declares a return type, and/or an implicit promise about the return value, then every implementation needs to return the updated object. So you can ask: Can you think of possible implementations that don't want to bother returning a new ...


2

Wrt. the specific case: Employee Update(Employee, name, password, etc) (actually using a Builder since I have a lot of parameters). It seems the Update Method takes an existing Employee as first parameter to identify(?) the existing employee and a set of parameters to change on this employee. I do think this could be done cleaner. I see two cases: (...


8

Does it violate the Single Responsibility Principle? Not necessarily. If anything, this violates the principal of command-query separation. The responsibility is update the employee data with the implicit understanding that this responsibility includes the status of the operation; e.g, if the operation fails, an exception is thrown, if it succeeds, ...


1

The single responsibility is about a class not needing to change for more than one reason. As an example an employee has a list of phone numbers. When the way you handle phone numbers change (you might add country calling codes) that should not change the employee class at all. I wouldn't have the employee class needing to know how it saves itself to the ...


67

The concept of the SRP is to stop modules doing 2 different things when doing them individually makes for better maintenance and less spaghetti in time. As the SRP says "one reason to change". In your case, if you had a routine that "updates and returns the updated object", you are still changing the object once - giving it 1 reason to change. That you ...


46

As always, this is a question of degree. The SRP should stop you from writing a method that retrieves a record from an external database, performs a fast Fourier transform on it and updates a global statistics registry with the result. I think almost everyone would agree these things should be done by different methods. Postulating a single responsibility ...


2

While there is some logic in having the methods that do some operations with bill history in the CustomerAccount (or Bill) class, one might argue that having them there breaks the SRP. You could say that CustomerAccount class should be responsible only for maintaining the account data (adding, deleting or modifying that data). Reporting could be seen as a ...


7

I agree that it is totally okay if a class has only one method, but recently I have read many blogs saying this is bad OOP and rather procedural coding. If a class has only one method, it's usually Execute(), or something equivalent. The question you have to ask yourself is, what are you encapsulating by using a class, if you only have one method? That's ...


2

I think the worst part of the interface is the fact that there is temporal coupling. Clients of the interface are expected to call methods in the right order, and this order isn't enforced by the type system, so it can only be infered by trial-and-error or by pre-existing domain knowledge. My initial thought is to keep a clean separate interface for the ...



Top 50 recent answers are included