This argument became moot when you said your 9000 line class could not be improved. You’ve said it’s “perfect” and doesn’t break any rules. Yet here you’re saying you’re fine with breaking rules?
The issue exists because you claim your 9000 line class follows SRP while at the same time saying you don’t mind breaking rules. The contradiction here is that you broke SRP but on one hand you’re claiming the class follows SRP and on the other you’re saying "I am a pragmatist, not a dogmatist, and I will break as many rules as I see fit in order to achieve the results that both I and my customers expect. "
If it were just the latter it would be fine. Just admit your class breaks SRP and stop trying to redefine it to fit the code.
And lets be clear, the class in question does not follow SoC either, it has knowledge of CSV formats (how the data will be displayed), PDF format (how the data will be displayed), buttons (display logic: “/ if TRUE drop any SUBMIT buttons after a validation error”), file pickers (user input/gui code), file upload logic (user input), pagination logic, query building logic, information about css classes (display logic), the file name of a download (display/output logic) and lots of business logic.
EXACTLY! If an article uses several different terms when discussing the same topic, but never explicitly says that they are different and explains why they are different, then they are the same. That is how the English language works, or isn’t English you first language?
Now you are being silly. That’s as daft as saying “Chalk is a rock, therefore all rocks are chalk” which I learned was wrong way back in primary school. If an article on gravity uses the term “gravity” and “attraction between bodies” then it is reasonable to assume that both terms mean the same thing. It would be unreasonable to assume otherwise.
Using the same logic Robert C. Martin’s article titled the Single Responsibility Principle quite clearly states “This is the reason we separate concerns” which therefore means that “separation of responsibilities” and “separation of concerns” are identical concepts. The words are slightly different but the meanings are the same.
The English language is peculiar that way:
Different words can sometimes have the same meaning.
The same word can sometimes have different meanings.
An educated person would understand this and not jump to unreasonable conclusions.
I disagree. Each Model class contains code which executes the business rules required by that class. That is precise, not vague.
Only the concrete class, not the abstract class. It should be obvious to EVERY programmer out there that if a business rule changes then the code which executes that rule also has to change. This is a fact of life, and there is no technique or principle that you can devise which can escape that simple fact.
Now you are joking! No sensible programmer would ever do such a thing as it would decrease cohesion and increase coupling, which is the EXACT OPPOSITE of what you are supposed to do.
Your entire argument rests on: “I don’t understand the difference between a leopard and a cheetah therefore they are the same”. This is an argument from ignorance. Just because you don’t have the capacity to understand the difference does not mean they are the same.
As I said, it can apply to almost any class you can dream of. This version of the class:
class Default_Table
{
// member variables
var $access_count; // count of accesses since instantiation
var $allow_empty_where = false; // switch to allow an empty $where string in STD.LIST2.INC
var $allow_db_function = array(); // allow a field's value in a database insert/update to contain a function name
var $allow_scrolling = false; // used inside ADD2 pattern to allow scrolling between selected rows
var $alt_language_table; // table holding alternative language text
var $alt_language_cols; // columns holding alternative language text
var $audit_logging; // yes/no switch
}
Also meets that definition. A tiny subset. As such, you’re not defining what the class does. Your explanation needs to
What? that’s nonsense:
class X {
public function foo() {
echo 'foo';
}
}
I can change this to:
class X {
public function foo() {
echo 'bar';
}
}
and the code which executes it does not need to change. You’re full of nonsense yet again. There is no fact here, there’s a vague assertion.
Answer the question please:
What is the single reason to change for this class?
Keep in mind that if I can remove any of the methods or properties from the class and it still meets the definition you provide, you’re not describing what the class does because removing those methods is a change and that change does not affect the definition: it’s a different responsibility. If I can change the class API in any way and it still meets the definition you provide, you’re not describing all of what the class does because that is another reason to change.
What are you talking about? Splitting a class into two always reduces coupling. Two methods in the same class are by definition tightly coupled. Yet another demonstration of your lack of understanding of coupling.
At least we are getting Tony closer to the truth. He is saying he breaks rules, when he needs to. That is certainly a big step in the right direction, than we have been at.
Yes, he breaks rules. And if that gets him the results he and his customers want, that is fine and dandy.
The issue is the fact that you, Tony, are often trying to pass off your coding as “good” and “within the rules”, or good and purposely outside of the rules (like when it comes to DI), when your code simply isn’t good from a coding perspective. From a client/ user perspective, it might be fabulous. And that is great if it is. It still can’t be a given, that poor coding, although it works, can be considered good coding. It simply doesn’t work that way.
I think this is Tony’s biggest problem. He argues from the perspective “My code works” and then retrospectively tries to apply best practices to the code. When he can’t do this, he has to redefine the concept to match the code… which obviously doesn’t work.
I’ve asked this again but it’s worth repeating:
Tony: Why are you here? What are you trying to prove by trying to redefine SRP and SoC? You’re the only person in the world making this claim. Why? You have nothing to back it up, you have zero qualifications, zero credibility and zero authority, what makes you think you know better than everyone else?.. and most importantly… what does it matter? You go and code 9000 line classes full of bad practices, leave the rest of us in peace.
Some people like my framework, some people don’t.
Some people like the Zend framework, some people don’t.
Some people like the Laravel framework, some people don’t.
Some people like the Symfony framework, some people don’t.
Some people like the CodeIgniter framework, some people don’t.
Some people like the Yii framework, some people don’t.
Some people like the framework, some people don’t.
What does this prove? To each his own. This is a free country, and people are free to determine for themselves what they like and what they dislike.
But that is not all that my transaction generation process does. For example, the most common transaction pattern in all the applications which I have built is the LIST1. This is part of a family which also includes the ADD1, ENQUIRE1, UPDATE1, DELETE1 and SEARCH1 patterns. When you create a LIST1 task it performs the following:
Generates the transaction script for the LIST1 task.
Adds the LIST1 task to the TASK table in the MENU database.
Adds the LIST1 task to the MENU table in the MENU database.
Generates the transaction scripts for the associated ADD1, ENQUIRE1, UPDATE1, DELETE1 and SEARCH1 tasks.
Adds ALL these task to the TASK table in the MENU database.
Adds ALL these task to the NAVIGATION table in the MENU database.
This means that the LIST1 task will be instantly available on that subsystem’s menu bar, and all the associated tasks will be available on the LIST1 task’s navigation bar. All these tasks will be runnable with default behaviour but without having to write a single line of code - no PHP, no HTML no SQL. Can YOUR framework do that?
Simply put: it doesn’t need to because putting it together doesn’t require so many repeated steps each time I want to add something… as I said, it violates DRY.
If you want to discuss Object-Oriented Programming principles then using you use an Object-Oriented Programming language. It’s called “common sense”. The fact that you don’t understand the similarities between the languages further demonstrates your lack of understanding of OOP.
You missed the point. I was applying sarcasm. You continuously believe that if the end result between two processes/concepts is the same, then the two items involved are identical. Yet, you claim Java and PHP are not the same, even though their end result is.
Which just goes to show that you have a particular set of beliefs that you place above everything else. If you believe SoC and SRP are the same, it doesn’t matter how much we show you they are indeed different, you will continue to see them as the same.
Just like boiling water via induction versus placing a pot of water on an open fire are entirely different, but they both result in the water boiling. How they did it greatly differs. SoC and SRP are those two different techniques.
Wikipedia has a process for this, you’ll often see pages have been merged. Try again.
Again focussing on the words and not the concepts
“Large hadron collider = big bang theory because they both use the word ‘big’”. Yet again all you’re doing is proving that you understand the words but not the concepts the words are used to label.
You have provided zero souces. The ones you did don’t back up your claim as pointed out here:
Your argument is an argument from ignorance. As I said before, it rests entirely on the fact that you don’t understand the difference between the two concepts. Pointing out your own ignorance to back up your claim doesn’t work.
The general form of the argument is as follows.
Minor premise: One can’t imagine (or has not imagined) how P could be so.
Major premise (unstated): If P, then one could imagine (or would have imagined) how P could be so.
Conclusion: Not-P.
Your argument is:
“I don’t understand the difference between SoC and SRP”
“Therefore there is no difference”
I don’t really understand the difference between an electron and a photon but I don’t go around saying “That means they’re the same thing”
You missed the point by a mile. It isn’t about what people like. It is about you parading around like you are the king of PHP and your framework is the golden crown jewel of frameworks.
Correct. That is why I have multiple Controller objects, one for each transaction pattern. That is why I have multiple View objects, one for each output format. That is why I have multiple Model objects, one for each database table. That is why I have multiple Database objects, one for each database engine.
While it is OK for an application to multiple objects of each type, only an unreasonable person would conclude that this also meant that in a single user transaction it would require multiple objects for a single Controller, multiple objects for a single View, multiple objects for a single Model and multiple objects for a single database. A reasonable person knows where to draw the line
In my application each Model class is responsible for the business rules associated with a single database table, and to break that class down into artificially smaller units would break encapsulation, decrease cohesion and increase coupling which any reasonable person would see as being the wrong thing to do.
No it is not. If an article constantly switches between two different terms when discussing a concept, and does not state that they have different meanings and why they are different, then they are NOT different. That is how the English language works.
There is also nowhere where it says they are different, and unless it specifically says that they ARE different then they ARE NOT different.
The two concepts ARE the same, but with different wording. You simply do not understand that it is possible for different words to have the same meaning just as it is possible for the same word to have different meanings.
Yes he does. The article in question says the following
I read that as “I took the ideas of Separation of Concerns, Cohesion and Coupling and consolidated them into the Single Responsibility Principle” In other words Separation of Concerns has been given more substance and rebranded as Single Responsibility Principle.
Uncle Bob is saying that SRP has replaced SoC because SRP now includes the ideas of Coupling and Cohesion which SoC did not. They are NOT different concepts which will produce different results.
It doesn’t use the same terms though, it uses the same words. “Large” and “Big” appear on the pages for Large Hadron Collider and Big Bang theory a lot, it doesn’t mean they are the same. Just stop, it’s a ridiculous argument.
Given more substance: So they are not the same. Thank you.
which SoC did not
which SoC did not
which SoC did not
Repeat that a few times. You just highlighted one of the differences between SRP and SoC while claiming they are “the same thing”. Busted.
If SRP includes coupling then your 9000 line class that uses singletons is definitely out.
So let’s get your logic here straight:
SRP == SoC + Coupling + Cohesion
yet
SRP == SoC.
Unless coupling and cohesion equal 0 (ie. are meaningless), your sums don’t add up and you just proved yourself wrong.
By your own definition they can produce different results because someone following SoC and not SRP doesn’t have to take coupling or cohesion into account, which will end up in a different result.
I believe you said it was implied, and therefore, it isn’t specifically stated and thus at the interpretation that one chooses to accept of said content?
