New answers tagged

0

Personally I would go with your idea of a third class. To me, this seems most consistent with an MVC (Model, View, Controller) pattern. If I understand correctly, an option (or Module) has a price property. This is part of your model. A user makes selections -- this is something that happens in your view. When it comes time to calculate a total based on a ...


2

The responsibility of this class is to retrieve information and output it. In other words, all of the things it does are its responsibility. However, how it does this is its own business and of no interest to its users. For instance, most C programs that produce screen output will eventually call printf, whose code lives in the standard library rather than ...


5

This is precisely why inheritance should never be the default choice for creating reusable features / functionality. Your issue boils down to you have an inheritance hierarchy that may in certain scenarios need knowledge across parts of the inheritance graph, making the graph have even more relationships between each node in it. These relationships are ...


0

Here you can find a short video explaining clearly the difference between those terminologies. https://www.youtube.com/watch?v=C7hkrV1oaSY Separation of concerns (SoC). Divide your application into distinct features with as little overlap in functionality as possible. (Microsoft). “Concern” = “distinct feature” = “distinct section” “Concern” works at both ...


0

TL;DR: you are over thinking this. However, I had fun overthinking it along with you. So buckle up.... Single responsibility ( reason to change ) of an entity should be to uniquely identify itself, in other words, its responsibility is to be findable. No, that's not right. The single responsibility of an entity is continuity. Identity is an ...


3

Allow me to go Zen on you: Please do not incur in analysys paralisys. By that reasoning you could as well call your method destroyInstanceWhenNeededButOnlyIfYouCallMe(). A single line of common code between two methods, specially an instantiation is not an itch that needs to be scratched. SRP doesn't go into that minutiae. It's about classes doing too ...


3

Single Responsibility Principle is ultimately a design principle created to ensure that "A class should have only one reason to change". While this doesn't mean that it cannot apply to methods, it means that it is more strictly applicable to classes. In determining the responsibility of your class or method, it is important to consider the consumer of your ...


0

You cannot violate the Single Responsibility Principle because it is just an esthetic criterion, not a rule of Nature. Don't be misled by the scientifically sounding name and the uppercase letters.


0

You are violating the single responsibility principle (SRP) as you are both representing data and performing logic in the same class. It sounds very reasonable for me. Model might not have public properties if exposes actions. It is basically a Command-Query Separation idea. Please note that Command will have private state for sure.


1

A lot of the answers here are really good but are focuses on the technical side of this issue. I'll simply add that it sounds like the developer's attempts to follow the SRP sound like they actually violate the SRP. You can see Bob's blog here on this situation, but he argues that if a responsibility is smeared across multiple classes then the ...


1

The most useful way I've found to understand the Single Responsibility Principle is to interpret "responsibility" as "reason why the code might change". This is because the primary goal of SRP is to group together code that will change together, and (as far as possible) keep code that will change for different reasons separated from it. By doing this, we ...


3

I would call the class ProcessController rather then MonitoredProcess. The class instance is not a process, it encapsulates a process handle. And it does not just monitor, it controls. You could pass the process id to the constructor. This would get your terminology straight, it would be clear your class controls a process for you. Which is one ...


1

This depends largely on the context of a "MonitoredProcess" in your application as a whole. Look at the name you've used: MonitoredProcess. This implies that the process is being monitored by something. It may be a different class, method, or something else in your application that is monitoring your processes and deciding on whether or not it wants to ...



Top 50 recent answers are included