Wouldn’t you say these are 3 different responsibilities? If not, why not?
And, continuing on this line of thought, you noted a very good quote about SoC. Here it is again.
You nicely highlight the word responsibility, but ignored what is being said. Look at the last sentence.
A boundary is any logical or physical constraint which delineates a given set of responsibilities.
Responsibilities, not responsibility. It is plural, not singular. In other words, they could have written this.
A boundary is any logical or physical constraint which delineates a given set of classes, where each class represents a single responsibility.
So, can you now still stay so stubborn and insist SRP and SoC are the same thing? I’ll answer it for you. You can’t. You cannot use the definition of SoC to legitimize your monster class and at the same time use that definition to say your monster class also follows SRP. The above proves SoC and SRP are two different concepts. And thus, we are back to your monster class breaking SRP.
Yes, I find it hard to understand how someone can be so lost in their own perspective and, at the same time, be so blind to think their perspective is completely correct too, when it really isn’t. The fact Tony’s framework works is only an attest to Tony’s fortitude, of which he can be proud of. However, it is not an attest of his competency as a developer. The fact his framework works to any satisfaction of any customer doesn’t prove that the fundamental concepts of OOP and of proper software design are also a given. A functional software and a proper software design, along with following OOP concepts correctly, are NOT mutually inclusive, which I feel is another incorrect perspective Tony has. “My Framework works, so the underlying development must all be perfectly correct from any development stand point!” When we start to point out this perspective is incorrect and Tony loses argumentative ground, his non-sequitur argument is something along the lines of, “I write code that works and not code to suit the fancies of other coders.”
It is fine to have that perspective, but when you have it, you should actually just stay in the wings and be quiet. But no, not Tony. He not only goes out of his way to write long winded blogs about how wrong most everyone else is, he has the arrogance to call those other devs doing normal things, like using DI regularly, as mindless monkeys. This is hard for me to understand and I hope I will never be that way.
This is a perfectly fine attitude to have. The problem is coupling that with saying “My code is perfect and follows all best practices such as SRP” then arguing the definition of SRP in order to pretend his code complies with it.
I’d be perfectly happy if tony was to say “My code works and does what it needs to. It breaks some programming principles and best practices but I don’t care”
The first characteristic clearly says that the flow of control is dictated by the framework and not the caller. This surely means that it is the framework which calls the developer’s code and not the other way around.
Any decision based on a simple count is ridiculous. Suppose I had a class for a database table which had 50 columns and I had a setter and getter for each. There’s 100 methods straight away, and the class doesn’t even do anything constructive yet.
When measuring software quality any “coupling” produced by inheritance can be totally ignored. It is only when module A calls module B that the degree of coupling can be affected by the developer.
Both articles use the terms “responsibility” and “concern” in exactly the same context, so the terms are not merely related they are identical and interchangeable. I have yet to see any article which states that these two principles are different, explains why they are different, and gives examples of the different results produced by each.
Just like you do.
I qualified that statement with that is universally accepted by all programmers. Just because one group produces a piece of paper with “best practices” as its title does not mean that everyone else immediately falls into line. Different groups have their own idea of what’s best for them.
No, they are NOT different responsibilities. All those operations form a cohesive unit and therefore belong in the same class. To split them into artificially small classes would convert a modular system into a fragmented system and make it less readable. I am not the only one with this opinion. This is what Tom DeMarco wrote in his book Structured Analysis and System Specification:
So you are saying that the meaning of a word changes when it switches from singular to plural?? What a load of BS.
SRP is exactly the same as SoC
responsibility = concern
responsibilities = concerns
I would qualify that by changing it to “It breaks some people’s interpretation of programming principles and best practices but I don’t care”.
I repeat what I have said many times before, all these programming principles such as SRP, SoC et cetera are all badly written as they are imprecise and open to huge amounts of interpretation and mis-interpretation. I tend to follow a moderate and balanced interpretation while others lie you, take an extremist view. Moderates and extremists will NEVER agree on anything.
You seem to think that academic theory can automatically be applied in the real world which is where you are wrong. In the real world, the commercial world, we have to strike a balance between academic theory and commercial reality. Sometimes striving for complete perfection is too expensive or too time consuming, so we stop when we reach “good enough”. It is a question of balance. In this article http://www.loosecouplings.com/2011/02/non-di-code-spaghetti-code.html the author wrote about DI, but it could be about any OO principle:
The application is the caller, not the framework, which means the developer has to write code to call into the framework. Once the application has called into the framework, the framework dictates the flow of control, which can include executing developer-written extensions, but it doesn’t mean the framework doesn’t have to be called into by the caller first. The developer has to write code to do that, or have that code generated for them by a boilerplate.
Are you saying, a person can simply ignore the meaning of a sentence, because a certain word is found within it and can be taken completely out of context? What a load of BS.
SoC is about the software as a whole. It defines the need for separation of concerns, each concern being a set of responsibilities. You can say your monster class along with the other separated concerns follows SoC.
However, SRP is about the proper formatting of singular classes and defines that a class should have a single responsibility and reason for change. With that definition, your 9000 class clearly breaks SRP.
Here are some:
Here is an SE question, where everyone who answers is agreeing and they all agree they mean different things.
This is a really good article on the separation of concerns. It doesn’t help my argumentation against your misinterpretation of SoC meaning SRP, but it also never mentions the two being the same and it is a great article all the same.
The SoC-Principle is strongly related to the Single Responsibility Principle (SRP) with concerns being a superset of responsibilities. In an ideal case, each responsibility consists of exactly one concern namely it’s core functionality. Often though multiple concerns are mixed inside one responsibility since it’s technically sometimes unavoidable. Therefore keep in mind that the SoC does not say ‘one responsibility should have only one concern’, but it says ‘concerns should be separated’.
[quote=“tony_marston404, post:212, topic:191138”]
ny decision based on a simple count is ridiculous. Suppose I had a class for a database table which had 50 columns and I had a setter and getter for each. There’s 100 methods straight away, and the class doesn’t even do anything constructive yet.[/quote]
While that’s true to an extent, it gives a good overview of complexity. If you read clean code by Robert C. Martin it says specifically that classes should be small… smaller than that. I.e. as small as possible. If you read the section on functions it says the same thing. You have broken SRP please stop arguing this point.
That depends entirely on which metric you use. Some count inheritance, some split coupling up for more precise measurements and have metrics for incoming/outgoing (Efferent coupling vs afferent coupling) and coupling caused by inheritance.
Not that this matters at all. You said:
it is quite wrong to say that inheritance automatically produces tight coupling.
Which is 100% wrong. Bob Martin said:
One of the problems with implementing an abstract class with inheritance is that the derived class is so tightly coupled to the base class
So that’s two things you need to stop arguing because you are totally in the wrong and just backtracking and trying to weasel your way out at this point. Stop, it’s just making you look foolish.
Both articles on thermodynamics use the word “thermodynamics” in the same context. The difference is that the “First law of thermodynamics” describes a specific concept related to it and so does the “Second law of thermodynamics”. The exact same is true here. I already said you’re too hung up on the individual words and not the concepts and all you do is repeat yourself. That’s 3. Stop.
[citation needed]. You’re the one who spins Bob Martin’s work to apply it wrongly to your awful code.
That’s simply not true though is it. Nobody apart from you is arguing about the definitions of these terms. I said this before, but there are discussions about the best way to apply the concepts, however you are arguing that the concepts have entirely different meanings (Inheritance does not produce coupling, singletons don’t create tight coupling, SRP and SoC are the same thing). Nobody in the world apart from you is arguing with the definitions.
I say again: You simply are not qualified to have a say on this subject, you’ve proven yourself entirely ignorant of the topic.
You’ve said SRP and SoC are the same and applied it to a class with 120 methods and 50 variables.
Bob Martin said:
The first rule of classes is that they should be small. The second rule of classes is that they
should be smaller than that. No, we’re not going to repeat the exact same text from the
Functions chapter. But as with functions, smaller is the primary rule when it comes to
designing classes. As with functions, our immediate question is always “How small?”
Five methods isn’t too much, is it? In this case it is because despite its small number
of methods, SuperDashboard has too many responsibilities.
The name of a class should describe what responsibilities it fulfills. In fact, naming
is probably the first way of helping determine class size. If we cannot derive a concise
name for a class, then it’s likely too large. The more ambiguous the class name, the more
likely it has too many responsibilities. For example, class names including weasel words
like Processor or Manager or Super often hint at unfortunate aggregation of
responsibilities.
We should also be able to write a brief description of the class in about 25 words,
without using the words “if,” “and,” “or,” or “but.” How would we describe the
SuperDashboard? “The SuperDashboard provides access to the component that last held the
focus, and it also allows us to track the version and build numbers.” The first “and” is a
hint that SuperDashboard has too many responsibilities.
So yes, you have redefined it. That’s 4 things you need to stop arguing because you are just in the wrong. You’re wrong, Tony, just admit it or stop this incessant nonsense.
Not only that, on functions and methods he says:
The first rule of functions is that they should be small. The second rule of functions is that
they should be smaller than that.
Every function in this program
was just two, or three, or four lines long. Each was transparently obvious. Each told
a story. And each led you to the next in a compelling order. That’s how short your functions
should be!
This implies that the blocks within if statements, else statements, while statements, and
so on should be one line long. Probably that line should be a function call. Not only does
this keep the enclosing function small, but it also adds documentary value because the
function called within the block can have a nicely descriptive name.
Oh look, you go against this as well and have functions that do far too much, shocking.
Tony, again, nobody apart from you is arguing about the definitions of the concepts, only how they can be applied. Nobody else says SoC and SRP are the same thing (And you still haven’t provided a source for this claim). Nobody else is saying “Inheritance doesn’t cause coupling”, nobody else is saying “a software framework must not be called”. It is you who is the extremist here, taking a concept and stretching it beyond all recognition in order to apply it to code which doesn’t fit the original definition… so that you can claim “My shockingly bad code follows SRP!/Doesn’t have tight coupling” or whatever concept it is you want to claim you’re following.
But for what feels like the hundredth time, just because occasionally it’s difficult to apply a concept in a real application doesn’t mean you get to redefine the meaning and then claim the code follows it.
Everyone has written code that doesn’t follow SRP, is tightly coupled or uses some bad practice, often it’s quicker to write initially. The difference is, you’re the only one who looks at that code and says “This follows SRP… let me go and find a line from a definition that proves it!!” everyone else says “The code works but it could be improved if there was more time”.
“Good enough” is perfectly fine, what’s not fine is saying that “Good enough” code follows best practices/is loosely coupled/follows SRP when it doesn’t. These concepts are not laws that you must follow, they are just indicators of code quality and flexibility. Please stop arguing about the definitions it’s making you look like a fool.
Question: is your Default_Table class “Good enough” or is it perfect? If it’s “good enough”, you’re saying it can be improved… how would you improve this class? If not, you’re saying that it’s perfect, there’s no room for improvement and your argument about “balance” is moot.
But in that case the amount of code that the developer has to write in order to activate the framework should be very small. In article http://www.sitepoint.com/crud-create-read-update-delete-laravel-app/ you should see from the volume of code that the developer is expected to write is anything other than small.
Who are you to say which source on the internet can be classed as primary secondary, tertiary or hearsay? Who are you to say which sources should be followed and which should be ignored?
Like most intelligent people I will only follow those opinions which make the most sense, and nothing you say makes sense to me. You have a habit of employing extreme interpretations on almost everything, and once you have started you simply don’t know when to stop. You do not like any opinion except your own and you are incapable of discussing anything in a reasonable and intelligent manner. Everyone knows that it is impossible to have a sensible discussion with an extremist.
Again, I’m presenting the known definition and you’re inferring it’s a definition I made up. if you knew the difference between a primary and secondary source you’d know that encyclopedias are a tertiary source.
How about wikipedia itself?
Once again we find Mr. Marston arguing with the definitions of things when the original definition doesn’t fit his agenda or puts his argument on a very weak footing. It’s pitiful, tony, this tactic is worn out by now surely?
Resulting to personal attacks is the biggest indicator you’ve lost the debate. If you actually had an argument (you don’t and never did) you would be able to use primary sources to prove me wrong rather than having a hissy fit and calling me names.
Show me where I have given a word in a sentence a meaning that is other than that which is found in the dictionary? To any reasonable and intelligent person the terms “responsible for” and “concerned with” mean the same thing. This in turn means that SRP and SoC mean exactly the same thing.
I have already pointed you to several articles which use the terms “responsibility” and “concern” interchangeably, so it is obvious that they mean the same thing. Anyone who tries to say otherwise is merely being pedantic and is nit-picking over trivialities. Both of those principles talk about taking a monolithic piece of code and breaking it down into smaller units each of which has a single concern or responsibility. Robert C. Martin has said in more than one article that separating GUI logic from business logic from data access logic is “good” design, and that is precisely what I have done.
I disagree. Saying that a class breaks SRP simply by counting the number of methods is completely unscientific. Each of my Model classes is responsible for the business rules associated with a single database table. It does not contain any control logic any view logic, or any database logic, so it fits Robert C. Martin’s description to a tee.
Just because some people share this opinion does not make it a valid opinion that should automatically be accepted by everyone.
The fact that MVC could be implemented with more than one class does not mean that it should. Most developers use only three, and there is nothing wrong with that. Personally I use four as I prefer to have all database access in its own class, which means splitting the Model into two separate parts.