So long and thanks for all the fish.
Can you point me any scientific process that, without input from a human, can identify whether one piece of software is better than another? If it requires human input it is not objective, it is subjective and therefore based on a human’s opinion.
They are an addition, but not necessarily an improvement.
That article contains the following statement:
This tells me that they are similar more than they are dissimilar. Can you explain, in 20 words or less, why Soc is not the same as SRP?
You really need to take in the whole post. If you read further, you would have read how the author says Bob Martin refined the definition of SRP to more “class level”.
However, SRP was re-interpreted by Uncle Bob with the definition “THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE”. By the definition, SRP was narrowed down to class level.
So in 20 words or less.
SoC is more about software architecture and SRP is more about OOP concepts.
And, still, your monster class breaks both definitions. Your own description of what it does points this out.
my abstract class contains all the methods that either a Controller or a View can use on a Model, or where the Model calls a DAO
Scott
I wish you would stop this ridiculous argument. This thread was supposed to discuss Dependency Injection but has degraded into a vitriolic attack both on my person and the quality of my software. One measure of software quality is based on coupling, where high/tight coupling is considered bad and low/loose coupling is considered good. When you made the statement that “inheritance produces tight coupling” this was a complete red herring as this type of coupling is never considered as a metric when evaluating software quality. If you don’t believe me then read this quotation from article http://people.ucalgary.ca/~far/Lectures/SENG421/PDF/oocross.pdf which YOU cited to defend your argument
While it does state that there is a type of coupling between superclasses and their subclasses, it also states that coupling measures focus on non-inheritance coupling. This quite clearly means that when attempting to measure the quality of a piece of software that inheritance coupling is ignored because it is irrelevant.
This also means that, in a discussion on software quality, trying to treat inheritance coupling the same as object-to-object coupling is completely out of order.
The only reason that some people favour composition over inheritance is because they make a compete dog’s dinner with inheritance with their multi-level class hierarchies. I do not have multi-level hierarchies as each of my Model classes inherits from a single abstract class.
The following quote is taken from http://www.visbox.com/prajlich/T/node14.html
Note the sentence which says One way around this problem is to only inherit from abstract classes. This is exactly the philosophy which I follow.
What a useless definition! Every programmer I know considers a “separate concern” and a “single responsibility” to mean exactly the same thing. How are they different?
[quote=“s_molinari, post:399, topic:114913”]
your monster class breaks both definitions. Your own description of what it does points this out.
If you read Robert C. Martin’s article at http://blog.8thlight.com/uncle-bob/2014/05/01/Design-Damage.html you will see the following:
My framework implements the 3 Tier Architecture which has all the GUI code in the Presentation layer, all the business rules in the Business layer, and all the database code in the Data Access layer. This mirrors EXACTLY what Uncle Bob describes in his article, so who the hell are you to tell me that my interpretation of his article is wrong!
It should also be obvious to anyone with any programming experience that objects in the Business layer absolutely MUST contain code for the following:
(a) Methods which allow it to be called by the layer above it.
(b) Methods which allow it to call the layer below it.
So when you say that the existence of such methods in my abstract class provides a “reason for change” and are therefore a candidate for separation, can you answer the following questions:
(1) If I take out the methods in the Business layer which allow it to be called from the Presentation layer, then how can the Presentation layer call the Business layer?
(2) If I take out the methods in the Business layer which allow it to call the Data Access layer, then how can the Business layer call the Data Access layer?
(3) How can the existence of such methods be a violation of either Soc or SRP?
You don’t need to “take out methods”. Your “business layer” should have a set of classes, where each have a single responsibility (and possibly a number of methods), which serve to fulfill the business layer’s concern. For instance, you might have one or more classes, which deal with working with the data access layer. You might have another set of classes, which deal with working with the presentation layer. What you shouldn’t have is one class that does it all and then call it SRP and the “business layer”.
Scott
For once in your life would you just answer a question honestly without the needless evasion. Once again you’re moving the goalposts. Are the statements you made:
Neither of those articles put “inheritance” and “coupling” in the same sentence, so they are not related.
I understand that inheritance has absolutely nothing to do with coupling.
Right or wrong? Do you stand by them or do you agree that inheritance and coupling are related?
I disagree. In my implementation each Model class is responsible for a single database table, so whenever you want to do something with a database table you perform an operation on an object instantiated from that table’s class.
The first rule of encapsulation is to place ALL the methods and ALL the properties for an entity into a single class which is exactly what I have done. If I put different operations in different classes then I am breaking encapsulation. By over-applying SRP you are turning a modular system with high cohesion into a fragmented system with low cohesion.
No, I do not.
Extraordinary claims require extraordinary evidence.
All you’re doing here is demonstrating yet again that you don’t understand what coupling is. If you’re really going to -argue that “coupling and inheritance are not related” you need some hard evidence. Please provide an academic reference that specifically states that inheritance does not create coupling. As there are plenty of references that specifically mention inheritance creating coupling, if this were in fact incorrect there would be numerous retorts of this statement in academia. However, as there are none all this proves is that you simply don’t understand what coupling is.
For clarification: You are arguing against all academic and other sources by making this claim. This simply proves you don’t understand what coupling is. Unless you provide an academic reference that specifically states that inheritance does not create coupling your argument is 100% invalid.
You won’t be able to do this as no such description exists, because other people understand what coupling is.
That is not a rule of encapsulation. Where does anything speaking about encapsulation say all methods and properties of an entity all have to go into a single class? In the rules I’ve read, there is nothing mentioned about “entities”. You are twisting the rules of encapsulation here too, just like you do with SRP. Also, your default table class isn’t depicting a “single entity” either. It rather deals with a good number of concerns, which breaks SRP.
Scott
1 Like
This is Tony’s modus operandi. Take a known programming concept then retrospectively drape it over his existing framework. The parts that fit, he agrees with, the parts he doesn’t he discards as “dogmatic” or “written by charlatans”. Tony’s entire argument is religious in nature: Defend the word of the holy book (Radicore) at all costs, evidence is irrelevant.
Tony to a T:
1 Like
I disagree. The earliest description I found for encapsulation said the following:
[quote]
Encapsulation: The act of placing an entity’s data and the operations that perform on that data in the same class. The class then becomes the ‘capsule’ or container for the data and operations. [/quote]
Notice the use of the word “entity” and “data and the operations that perform on that data in the same class”. It couldn’t be much plainer, could it?
I disagree. Each Model class in my application is responsible for all the operations that may be performed on a particular database table. My “monster” abstract class provides all the standard code that can be inherited by any Model class.
The notion that this class breaks SRP is a complete fallacy. All the control code is in separate Controllers, and the view code is in separate Views, and all the data access logic is in separate Data Access Objects. This is ALL the separation that is necessary. Anything else would reduce a system of cohesive modules into a collection of artificially small fragments in which all cohesion would be lost.
If you look at the definition of coupling in https://en.wikipedia.org/wiki/Coupling_(computer_programming) you will clearly see that it relates to the connection between two separate modules. It relates to how one module calls another, not how one class inherits from another.
And again, you’re using wikipedia as a more authoratitive source than peer reviewed jouranls. I quote again:
One of the problems with implementing an abstract class with inheritance is that the derived class is so tightly coupled to the base class
This is from an academic paper written by Robert C. Martin.
Answer with a yes or no: Are you saying that Robert C. Martin, writing in a peer reviewed academic journal is less authoritative than Wikipedia?
Yes. Coupling between modules is not the same as the thing called “coupling” between a superclass and a subclass. Just because they use the same word does not mean that they mean the same thing and have the same effect.
Then there’s zero point talking to you. If you’re cherry picking discussions and dismissing peer reviewed academic journals and instead choosing wikipedia (Which even mentions subclass coupling by the way) then you clearly have no interest in learning anything.
This is the heriachy of evidence from the BMJ:
You are sitting on the bottom rung at “Ideas and opinions”. Whereas Academic Journals sit at the level of Cohort Studies.
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.