Millions? Ok. I challenge you to find just one framework that has MVC architecture and does it with only three main classes and no serious sub-classing.
Scott
Millions? Ok. I challenge you to find just one framework that has MVC architecture and does it with only three main classes and no serious sub-classing.
Scott
Yes, and you are repeatedly misinterpreting what “inversion of control,” the first characteristic in that list, means. It does not mean “the application developer shouldn’t have to write code to call into the framework.”
And instead of attempting to explain why your interpretation is correct (which it isn’t), you simply respond with “But Radicore can do it without writing code”, as if what Radicore can do has anything to do with the definition of either “inversion of control” or “framework.”
I don’t event like MVC… I prefer DMVC, as DM being Domain Model. The term “model” might be to vague and can be interpreted as the objects that come from a database or a service, and what it should be read it is that is the the model that is suppose to be used in a the view(s). The MVC is a pattern for Presentation purpose, not for defining the application. The MVC pattern requires the minimum of 2 classes, and a thing to be the view (class or a “template” in twig for example). But applying that to a real scenario exploded the number of objects in context. The Domain Model can be composition of classes (user, address, context, …), the controller should be thin enough and only dispatch to other services, providers, validators, thus a bunch more of additional classes, each with each own responsibility, the view can be a composition of templates inside templates (header, side bars, content, signatures, footers).
So yes, there are millions of developers that explain how to do a single “hello world” webpage MVC application with 3 classes. I doubt that there is a single developer that really does that. But lets “assume” that there is. If so. The view needed to have all the ifs for all screens, the controller needed to have receive all possible actions from all views, and and the model needed to represent different combinations of data available to the screens. Is this a real scenario?
Obviously this breaks all SRP, SoC, SOLID, …, If not, what exactly what do you mean?
I have NOT redefined SRP. For “single responsibility” I have created a separate class for each database table where each class is responsible for the business rules for a single database table.
Inheritance is not a problem, it is a recognised technique in OOP for sharing code. He should have used the word “combined” instead of “coupled” as that has a totally different meaning. It is used when one object calls a method on another object and describes the degree of interaction between those two objects. Depending on how well this interface is coded, the degree of coupling can either be described as “loose” or “tight”, where “loose” is supposed to be the better of the two.
The coupling that exists between a superclass and its subclass is totally different, and can be totally ignored as a measure of software quality.
tony_marston404:
Soc (Separation of Concerns) and SRP (Single Responsibility Principle) mean exactly the same thing.Nowhere else does it say this and the fact that wikipedia has different articles describing different concepts is a nail in the coffin: You have redefined SRP and SoC.
You are totally wrong. In his article http://blog.8thlight.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html Robert C. Martin states the following:
This is the reason we do not put SQL in JSPs. This is the reason we do not generate HTML in the modules that compute results. This is the reason that business rules should not know the database schema. This is the reason we separate concerns.
To him the “separation of responsibilities” means exactly the same thing as “separation of concerns”.
The Wikipedia article https://en.wikipedia.org/wiki/Separation_of_concerns contains a reference to http://aspiringcraftsman.com/2008/01/03/art-of-separation-of-concerns/ which contains the following:
The Principle of Separation of Concerns states that system elements should have exclusivity and singularity of purpose. That is to say, no element should share in the responsibilities of another or encompass unrelated responsibilities. Separation of concerns is achieved by the establishment of boundaries. A boundary is any logical or physical constraint which delineates a given set of responsibilities.
In that article he uses the term “responsibility” over 20 times, so in his mind it means exactly the same as “concern”
this discussion has turned into one about the theory and how you don’t understand it.
But I DO understand these theories and concepts, it is just that my interpretation and implementation of these theories and concepts is different from yours AS THEY ARE ALLOWED TO BE!!!
You’re the one who said “Software component = ONE CLASS”. Software component has a specific meaning in computing which has no relation to classes.
I did not say that. There are several levels of component and sub-component, and in my architecture a class is at the lowest level.
So you’ve got zero formal qualifications,
Irrelevant. When I first joined the computing profession there were no such things as computer-based degrees. I got my first job by passing a test which proved I had a logical mind and could think like a computer. I have seen too many CS graduates who know the theory but are simply unable to put it into practice.
you’re entirely self-taught
Incorrect. I received on-the-job training as well as being sent on outside training courses.
mostly work alone so don’t even have other developers to discuss potential solutions
Incorrect. While being a full-time employee for several decades I always worked in a team of developers, first as a junior and then as team leader. While working as a contractor for several customers in the last decade I have always worked with other developers as they had to check and approve my work before it was allowed to go into production. I currently make a living by selling licences for my software package, a large enterprise application, and I regularly discuss the design and implementation of enhancements and customisations with my business partner who is also an experienced developer.
you’ve consistently demonstrated you don’t understand several fundamental concepts which inevitably leads to a misinterpretation of more advanced concepts.
My experience of having successfully designed and built a very large number of applications over the years clearly proves that you are wrong. My interpretation and implementation of certain concepts may be different from yours, but I am allowed to be different, just like every other programmer on the planet. There is no “one-size-fits-all” answer for everything.
The problem that exists with all the concepts and theories about OOP is that they are so badly worded that they are open to enormous amounts of interpretation and therefore mis-interpretation. Just because my interpretation and implementation of certain concepts is different from yours does not automatically mean that they are wrong! Different, yes. Wrong, no!
Why should anyone listen to anything you say?
For exactly the same reason why people should listen to what you say - to find out if it makes sense or not.
There’s “being different” and there’s redefining industry standard, academically recognised terms to fit your needs and then trying to pass off your awful code as “Well written”.
There is no such thing as a single “industry standard” that is universally accepted by all programmers. As for “academically recognised terms” I do not work in the academic world where theory is everything, I work in the commercial world where it is only the practical application of those theories which counts.
My code can be classed as “well written” simply because it is readable - by others as well as myself - and therefore easy to understand and maintain. Those are the only metrics that count, not the number of design patterns I use or the way I implement them.
tony_marston404:
There are millions of developers out there who assume that an implementation of the Model-View-Controller design pattern requires no more than 3 classes - one for the Model, one for the View, and one for the Controller - so it is not that unreasonable.Millions? Ok. I challenge you to find just one framework that has MVC architecture and does it with only three main classes and no serious sub-classing.
I have seen many articles on MVC some of which have a single class for the Model while others (like mine) take out all database access and put it into its own class. I have seen a few that split the Model into smaller classes, but I do not agree with this approach AS IS MY RIGHT!!! Just because some people like multiple classes does not mean that everyone should follow the same design, and I happen to be in the camp that doesn’t.
And instead of attempting to explain why your interpretation is correct (which it isn’t), you simply respond with “But Radicore can do it without writing code”, as if what Radicore can do has anything to do with the definition of either “inversion of control” or “framework.”
Considering that the title of this discussion is “Would you agree this is the definition of a framework?” all I have done is agree with the four characteristics documented in https://en.wikipedia.org/wiki/Software_framework and pointed out that my framework has all four characteristics while many of the other so-called frameworks do not.
So yes, there are millions of developers that explain how to do a single “hello world” webpage MVC application with 3 classes. I doubt that there is a single developer that really does that. But lets “assume” that there is. If so. The view needed to have all the ifs for all screens, the controller needed to have receive all possible actions from all views, and the model needed to represent different combinations of data available to the screens. Is this a real scenario?
I do not have a single Controller in my application that has to deal with all possible actions on all possible Models and Views.
I do not have a single View which has to deal with all different types of output - HTML, PDF, or CSV.
I do not have a single Model which has to deal with all the tables in the database.
What I DO have is an architecture where each user transaction, and I have over 2,500, uses a Model (sometimes more than one) a View and a Controller, where each is chosen from a list of possibilities at run time.
Each of these components is responsible for (or concerned with) a separate piece of logic in the application so as far as I am concerned this is an acceptable interpretation and implementation of SRP.
I have NOT redefined SRP. For “single responsibility” I have created a separate class for each database table where each class is responsible for the business rules for a single database table.
Again, Robert C. Martin says Classes should be small and that a 70 method class is too large. He says classes should have few instance variables, you have a class with 50+. You are redefining what SRP means to retrospectively fit it to your existing code. You have redefined it.
He should have used the word “combined” instead of “coupled” as that has a totally different meaning.
And now you’re putting words in peoples mouths again. He said coupling because he means coupling and yes they have different meanings. Once again, you demonstrate you don’t understand coupling which as I’ve said before is the root of most of your misunderstandings as SRP and DI are related to it.
Coupling is when one class or method requires the existence of another to function. With inheritance, the subclass requires the base class. This is a very simple concept. This is tight coupling because there is no way to make the subclass use a different base class without re-coding it.
From the wikipedia page (Because you seem to like it) https://en.wikipedia.org/wiki/Coupling_(computer_programming) :
coupling increases between two classes A and B if:
Ahas an attribute that refers to (is of type) B.
A calls on services of an object B.
A has a method that references B (via return type or parameter).
A is a subclass of (or implements) class B.
See that last point?
You are totally wrong. In his article http://blog.8thlight.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html Robert C. Martin states the following:
Which shows they’re related concepts, not the same. Again, you seem to struggle with nuance.
The Wikipedia article https://en.wikipedia.org/wiki/Separation_of_concerns contains a reference to http://aspiringcraftsman.com/2008/01/03/art-of-separation-of-concerns/ which contains the following:
Because they are related concepts. What you seem to miss is that “Separation of Concerns” is a term with a specific meaning and so is “Single Responsibility Principle”. It’s like saying “First Law of Thermodynamics” and “Second law of thermodynamics” Funnily enough they both use the word “Thermodynamics” yet relate to different principles. The same is true here, you’re focussing far too much on the individual words and ignoring the concepts they describe. You’re saying the first and second law of thermodynamics are the same because the word “thermodynamics” appears on both wikipedia pages. What a nonsensical argument.
But I DO understand these theories and concepts, it is just that my interpretation and implementation of these theories and concepts is different from yours AS THEY ARE ALLOWED TO BE!!!
Irrelevant. When I first joined the computing profession there were no such things as computer-based degrees. I got my first job by passing a test which proved I had a logical mind and could think like a computer.
While you have a fairly competent grasp of the basics, you have fallen into the same trap that anyone who is self-taught falls into: picking up bad habits and not being aware of alternative (better) approaches because you haven’t been taught them as well as lacking a proper understanding of the underlying theory. It’s all well and good being able to play some chords on the guitar but it doesn’t mean you know anything about how to read sheet music or any of the theory behiind it. Have you ever had any formal training on OOP? I can tell that the answer is a clear no or if you did it was a very introductory level.
While you may have gone to a couple of “training days” which gave you a basic grasp of objects and classes, those of us with degrees did 3 years learning about the nuances of this stuff. I’m currently doing a PhD (While working in industry) on the topic of OOP, best practices and software metrics. It’s safe to say I know considerably more about OOP than you do.
The problem that exists with all the concepts and theories about OOP is that they are so badly worded that they are open to enormous amounts of interpretation and therefore mis-interpretation. Just because my interpretation and implementation of certain concepts is different from yours does not automatically mean that they are wrong! Different, yes. Wrong, no!
No, you purposefully mis-interpret them by quoting single sentences out of context because you want to use them to justify your existing code.
For exactly the same reason why people should listen to what you say - to find out if it makes sense or not.
The difference, of course, is I’m not the one saying Robert C. Martin is wrong, disagreeing with experts from Google, Apple and Microsoft and I use primary sources (ie not wikipedia) to back up my claims. Your claims are based on hearsay, opinion and tertiary sources.
There is no such thing as a single “industry standard” that is universally accepted by all programmers. As for “academically recognised terms” I do not work in the academic world where theory is everything, I work in the commercial world where it is only the practical application of those theories which counts.
Riiight… there’s no such thing as “industry standard” or “academically recognised terms”. Where do you come up with this nonsense, do you even think about how stupid it sounds when you type it out?
The reason terms get blurred is because people such as yourself glance at a wikipedia page, assume you fully understand it (Even though wikipedia is a summary, it’s not a comprehensive guide) and then end up with a skewed interpretation of the original concept… and then blog about it. Which is why arbitrary blogs are not primary sources.
My code can be classed as “well written” simply because it is readable - by others as well as myself - and therefore easy to understand and maintain. Those are the only metrics that count, not the number of design patterns I use or the way I implement them.
Considering that everyone here who has looked at your code has agreed that it is difficult to read I can only disagree. I’ve yet to see anyone apart from yourself say that your default_table class is “easy to understand”. It’s actually incredibly difficult. Even Bob Martin displayed disgust when scott linked it to him on twitter.
“Inversion of control” !== “I don’t have to write code”. Laravel is a framework, as are all the others, as they are in control of the execution flow, rather than the developer of the application.
The methods fall into one of the following categories
- Methods which allow it to be called by the layer above it (the Controller or the View)
- Methods which allow it to call the layer below it (the Data Access Object).
- Methods which sit between these two. Many of these are “customisable” methods which are empty, but could be filled with code in order to override the default behaviour.
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.
The Principle of Separation of Concerns states that system elements should have exclusivity and singularity of purpose. That is to say, no element should share in the responsibilities of another or encompass unrelated responsibilities. Separation of concerns is achieved by the establishment of boundaries. A boundary is any logical or physical constraint which delineates a given set of responsibilities.
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.
Scott
Responsibilities, not responsibility. It is plural, not singular. In other words, they could have written this.
set of responsibilities as well. Not just plural but actually labels it as a set of them. SRP then relates to one of these responsibilities.
This should be the nail in tony’s coffin on this argument but I guarantee he won’t admit he’s wrong.
but I guarantee he won’t admit he’s wrong.
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.
Scott
“I write code that works and not code to suit the fancies of other coders.”
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”
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”
I agree completely.
Scott
tony_marston404:
Anything calling itself a framework which does not exhibit the four characteristics mentioned in https://en.wikipedia.org/wiki/Software_framework has no right to call itself a framework.Yes, and you are repeatedly misinterpreting what “inversion of control,” the first characteristic in that list, means.
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.
Again, Robert C. Martin says Classes should be small and that a 70 method class is too large.
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.
Coupling is when one class or method requires the existence of another to function.
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.
Because they are related concepts.
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.
No, you purposefully mis-interpret them by quoting single sentences out of context because you want to use them to justify your existing code.
Just like you do.
Riiight… there’s no such thing as “industry standard” or “academically recognised terms”. Where do you come up with this nonsense, do you even think about how stupid it sounds when you type it out?
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.
“I write code that works and not code to suit the fancies of other coders.”
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 have not redefined SRP. I have follows the description found in http://blog.8thlight.com/uncle-bob/2014/05/01/Design-Damage.html and http://blog.8thlight.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html
tony_marston404:
The methods fall into one of the following categories
- Methods which allow it to be called by the layer above it (the Controller or the View)
- Methods which allow it to call the layer below it (the Data Access Object).
- Methods which sit between these two. Many of these are “customisable” methods which are empty, but could be filled with code in order to override the default behaviour.
Wouldn’t you say these are 3 different responsibilities? If not, why not?
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:
Cohesion is a measure of the strength of association of the elements inside a module. A highly cohesive module is a collection of statements and data items that should be treated as a whole because they are so closely related. Any attempt to divide them would only result in increased coupling and decreased readability.
Responsibilities, not responsibility. It is plural, not singular.
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
TomB:
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”
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.
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
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:
Is it possible to write good code without DI? Of course. People have been doing that for a long time and will continue to do so. Might it be worth making a design decision to accept the increased complexity of not using DI in order to maximize a different design consideration? Absolutely. Design is all about tradeoffs.