Again with the anecdotes. If you’re going to make a claim that “Don’t use X if Y” you need to:
I believe you’re lying. I’ve worked with code that old before, still do for one of our clients. It’s invariably a pain in the neck. Now admittedly, it’s your own baby so it’s not as bad for you. Guess it does insure job security though as put forth in this guide which you’ve inadvertently admitted to using several techniques from on more than one occassion –
How to Write Unmaintainable Code: Ensure a Job for Life.
[quote=“tony_marston404, post:308, topic:114913”]
The absence of unit tests has no bearing on whether software is flexible or not.[/quote]
There’s no polite way to put this – your willful ignorance of unit testing blinds you to the stupidity of that statement.
Nearly everyone on this and multiple other boards have told you your techniques are not only foul, but among the most wretched of foul. You are being willfully ignorant.
It is well known that beginners will tolerate what experienced programmers will not because beginners don’t know any better. Inexperienced programmers lack the ability to discern good from bad code. You also lack that ability, not from lack of experience but from willful ignorance and sheer stubbornness, both of which are unforgivable.
For your next act of stupidity would you like to tell me how lions are dogs, grass is in fact pink, or the number PI is an even 3?? You can lie all you want Tony, it doesn’t make it true.
That you’ve only managed 89 updates in 9 years speaks volumes. Drupal 8 sees that many updates roughly every 3 days. The stable branch sees about that many updates each month.
Yes. One was recently replaced after having ran for 9, and I’m glad its gone. Unlike you I’ve grown as a coder in the last 10 years and don’t hold up the swill I wrote ten years ago as a work of genius. I doubt I’ll be any more charitable in ten years to the code I’m working on now.
A more relevant question - Have you learned anything in that time? Given your posts I think the answer is very obviously no. Not only have you not learned one damn thing, you’ve went out of your way to not learn anything out of obstinance and a very misplaced sense of superiority - the kind of superiority that can only rise in the mind of one who knows very, very little about the subject at hand. It’s the kind of willful ignorance I have little to no patience for.
I disagree. If I don’t have the problem that a particular feature or technique is supposed to solve, the implementing that “solution” would be a complete waste of time. Anyone with common sense should be able to see that.
Then by your definition my code has a great deal of flexibility as any one of my 40+ page controllers can be used with any one of my 300+ Model class without having to change a line of code. This is why with just 40 controllers I can generate an application with over 2,500 user transactions.
“Better” is not something which can be measured scientifically, it is simply a subjective observation.
You seem to forget that you still need procedural code in order to instantiate the first object and call the first method. I use classes and objects where I can benefit from inheritance and polymorphism. Every one of my 300+ Model classes inherits from a single abstract class, and because each of my 40+ Controllers uses methods which are defined within the abstract class this means that every one of my 300+ Model classes can be called by any one of my 40+ Controllers.
I cannot point to a single document which identifies my best practices just as you cannot point to a single document which identifies yours.
I disagree. I was forced to use unit testing by a new manager on one particular project, but it took much longer to build the tests than it did to write the code that was being tested. As I had been employed for my ability to provide quick solutions to ever-changing requirements, this ability was seriously compromised by this perceived “need” for unit testing. The company owner decided that my productivity was more important that unit tests, so he fired the new manager.
You also fail to see that TDD means Test Driven Design, and I don’t need to write tests in order to design the applications which I write. I write enterprise applications which use enterprise databases, so the database design is where I start.
The title of this discussion is “Are today’s frameworks capable of enterprise capable applications?” to which I have given my honest answer. A B2B enterprise application is a different kettle of fish than a B2C website, so it needs a different kind of framework. I have been writing enterprise applications in various languages for over 30 years, and I have built frameworks in three of those languages. I have used my latest PHP framework to build an enterprise application as a package, not bespoke, which went live with its first customer in 2008 and its latest customer this very year.
I don’t adopt new techniques because they exist, I only adopt them when they have proven benefits in the type of application which I write.
As for not writing any code in the last 10 years you couldn’t be more wrong. The 89th release of my framework was made on the 5th of this month, and the latest release of my enterprise application was on the Sunday which has just passed.
Just because you and your cohorts think it’s best does not make it so. It is just an opinion, and an opinion which I do not share.
Incorrect. I do not use them because I have no need for them. My existing code base works quite happily without them (and has has done for over 10 years) so I see no reason to change code which works into code which does exactly the same thing but differently.
I repeat - inheritance has absolutely nothing to do with coupling, therefore it is quite wrong to say that inheritance automatically produces tight coupling.
Guess how each of my 300+ Model classes start:
require_once 'std.table.class.inc';
class X extends Default_Table {}How is my code different from yours?
Incorrect. What I actually say is “I have no use for that solution as I do not have the problem which its solves”.
You did not prove that I was wrong, you simply proved that you do not understand the problem for which DI is the solution, even after I pointed you to Robert C. Martin’s original article which clearly shows that DI has benefits only where a dependency can be provided from one of several sources. I use DI in my framework where that situation exists for the simple reason that I have never seen an alternative approach which is as effective and as flexible. Where a dependency can only come from a single source which will never be changed then DI is complete overkill and entirely inappropriate, so where that situation exists in my framework then I do not use DI.
If you stop attacking my code I will stop defending it. If you stop attacking my methods simply because they are different from yours then I will stop defending them.
Being paid $40 / hour is better than minimum wage. Being healthy is better than being disease ridden. Neither of those is subjective - they are both subject to objective measures, so once again you’ve been proven wrong. Now, are you wise enough to admit that or willing to further demonstrate your ignorance and foolishness?
Experience is NEVER meaningless. Experience helps you avoid making mistakes, but experience can only be gained by making mistakes.
When my experience has shown that a particular idea, technique or implementation has been proven to be a mistake then I feel perfectly justified in my decision to not repeat the same mistake.
Stop just stop. We’ve already been through this. You can use an autoloader, you chose not to, you can use DI, you chose not to. You made an alternative choice, the merits of the different approaches can be weighed up and analysed, and you always seem to fall on the side of the measurably worse choice.
The fact you have 2,500 of anything speaks volumes. If you need 2,500 variants of something, you’ve got repeated code there. Again though, it’s just anecdotes that have no substance. When it comes down to it, each time you’re asked you’re unable to provide anything with more substance than “40 controllers, 300 models lol”.
100% Wrong. There are lots of ways to measure “better”: Performance, lines of code, readability, flexibility, portability, etc.
Anecdotal.
You perpetually miss an important point: Best practices evolve out of tried/tested solutions. A “Best practice” emerges because professional programmers, language authors and academics try different solutions to the same problem and identify weaknesses/strengths in the approaches. The stronger approaches become “best practice” because they offer quantifiable benefits and the weak solutions become known as “bad practice” because they are actively detrimental to the codebase.
How many times must we go through this? Please stop playing the “LALALA Fingers in ears game”.
More irrelevant anecdotes.
More irrelevant anecdotes… None of this matters one iota to the topic at hand.
Then you have had a chance to use modern techniques and actively chosen to avoid them. This is negligence as they would have provided measurable benefits (Faster development time, less buggy end result)
And you again prove you don’t know what coupling is.
You cannot see that? How?? Default_Table is hardcoded, Your class will always extend the default table class… Again, go and learn about coupling as it’s clear you don’t understand it.
I’m not getting into this again, I repeatedly proved your incompetence in the other thread, go read that.
Then stop citing it. 90% of your remarks start with “My code”, “My framework”, “I don’t…”. Someone says “Singletons are bad” and you respond with “I use them in my framework so no they’re not!!!”
The problem here is that you clearly haven’t learnt from your mistakes. When you have everyone here and elsewhere telling you you’re going down the wrong path, there’s something in it. We have repeatedly shown you to be at a level of an inexperienced developer. The number of year’s you’ve been doing it is meaningless here.
No, I did not.
We’re getting to the point again where a reminder to keep the discussion civilized is necessary. One tip that will really help with this is if you find yourself using the word “you”, “your”, “I”, etc, try rewriting that line to be less direct, by using “someone” or “a person”.
Sometimes it is difficult and in those times, just be weary of the connotation/attitude that may be implied with your remarks and try to make it not become too personal.
I wanted to just highlight this because your misunderstanding of coupling seems to be the root of most of the issues you have: DI, TDD and Favour Composition over inheritance. As you don’t understand coupling. Go and read the section on it here:
https://nikic.github.io/2011/12/27/Dont-be-STUPID-GRASP-SOLID.html
Or my own explanation here:
No, I do not admit that it is “bad”. It is just a method of comparing two different approaches. One approach is to have a single class with 120 methods while a different approach would be to have 120 classes with a single method each. Which in your opinion would be the most readable?
So you would agree then that an over-enthusiastic interpretation of the Single Responsibility Principle can lead to code which is too fragmented?
It fits my interpretation of SRP. I have implemented the MVC design pattern with an additional twist of separating out all database access from the Model class into different Data Access Objects, with a different object for each DBMS engine. That is all the separation that I deem necessary.
Every one of my 300+ Model classes inherits from my “monster” abstract class, and 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. All control code is contained within my Controllers, all view code is contained with my Views, and all database access code is contained within my DAOs. This leaves the Models which contain all business rules, data validation rules and task-specific behaviour.
I only need to change my abstract class for one reason - if something in the Model changes. I can change a Controller without changing a Model. I can change a View without changing a Model. I can change a DAO without changing a Model.
Every method in my abstract class is there simply because there is where it belongs. You might have a different opinion, but I do not have to agree with it
Different people have a different opinion on what “better” means. Writing software that sells is better than writing software which does not sell. When building an application a development time of one month is better than one year. How I build my software should be less relevant than the fact that I can build it faster and better than most (if not all) of my competitors.
I disagree. DI was designed specifically for those circumstances where a dependency can be supplied from a number of sources. It was not designed for those circumstances where a dependency can be supplied from a single source.
So why do you and your cohorts keep telling me that I should replace all my include statements with an autoloader? I do not have the problem that autoloaders were designed to solve, so I don’t need one as a solution.
It may be an improvement, but it is one that I don’t need, which is why I will not change my entire code base to use namespaces.
Whether a new feature is actually an improvement or not depends on your point of view. But just because something is new does not mean that I should rush out and implement it immediately. If I have last year’s model of smart phone, but this year’s model is “new and improved”, why should I spend money on this year’s model if I have no need of the new features. Like most people I wait until I have paid for my current model until I go out and buy a new one.
.
Stop lying: http://pastebin.com/31sHHv75
Not that this matters. You can either use an autoloader or use require_once, an autoloader has measurable advantages over not using one (Development time, repeated code, developer needs to remember less). Whether you choose to use one or not is again, anecdotal and irrelevant. Unless you can demonstrate a situation where an autoloader is inferior to another approach, your post is meaningless.
That still does not hide the fact that there is no scientific measurement which can tell if one piece of code is better than another. “Does it work?” and “does it sell?” are more important questions than “how well was it written?”
Wrong again. It’s going to depend who you ask… if it’s the next developer who comes along and has to tidy up the mess the question “How well was it written?” is by far the most important one. When the client can’t find anyone to take on the work, or charges a lot because the system was written poorly then the question “how well was it written?” becomes incredibly important to the client as well.
And as I already said, there are lots of measures for “better”, flexibility, portability, performance, lines of code, coupling, cohesion. Go and tell the scrutinizer-ci team, sensio insights or phpmd teams that there’s no way to measure “better” and they’ll rightly laugh at you.
Your use of the word can instead of should implies that I am allowed to make my own choices then? And that one choice is not necessarily “bad” while the other is automatically “good”?
Who says that my choices are the worst? They still work, like they have done for many years, so how come they are automatically bad just because there is now a different way of doing exactly the same thing?
[quote=“TomB, post:318, topic:114913”]
tony_marston404:
This is why with just 40 controllers I can generate an application with over 2,500 user transactions
The fact you have 2,500 of anything speaks volumes. If you need 2,500 variants of something, you’ve got repeated code there.[/quote]
Then you have obviously not worked on a large enterprise application. Each one of those 2,500 user transactions - which you might now as “use cases” - does something different to a different Model class. I don’t have any repeated code as anything which could be repeated has been placed into a reusable module.
Lines of code would be a stupid way to measure “better”. Readability cannot be measured scientifically, it is a matter of personal perception. Flexibility cannot be measured scientifically, you need to apply an actual change to see how easily that change can be implemented. As for portability, my application can run on any platform on which PHP can be run, and it can be run with a choice of databases - MySQL, PostgreSQL, Oracle or SQL Server.
And you keep missing an important point. There is no document entitled “Best Practices” which exists in a single place, there are simply thousands of different opinions in thousands of different places. Even if there were a single document it would never be universally accepted by all programmers. Each programmer has his/her own different opinion on what is best for them. I most definitely AM following best practice, but it is not the same version as yours.
How so? They directly respond to the question around which this discussion was originally based. You are the one who keeps changing the discussion into attacks on either my methodology or me personally.
I chose to avoid those techniques which I saw had no benefit. This is not negligence, it is prudence. As for faster development time and less buggy end result, my development times are faster than yours, and neither my framework nor my enterprise application have any outstanding bugs.
Yes I do. My understanding comes from such articles as http://en.wikipedia.org/wiki/Coupling_(computer_programming) Can you point to any authoritative article which says that inheritance produces tight coupling?
No, you simply proved that you cannot read, and that you dislike any opinion which is different from your own.
Both are wrong and the discussion isn’t about readability. It is about SRP.
Sure. However, it is a lot rarer to find too much fragmentation. I personally have never ran across it. I have, however, seen a good number of classes doing too much.
And your interpretation doesn’t follow the same interpretation made by the best minds of programming, like Uncle Bob Martin.
And you can deem what is necessary all you want Tony. Just don’t declare it better or correct, because it simply isn’t.
Look at that single sentence Tony. There are already three reasons to change your class.
We don’t. You interpret what we are saying incorrectly. It is a bad habit you should get rid of.
No, you most definitely have the problem autoloaders were designed to solve, but are defiant to use it as a solution.
Hey! Finally, we almost agree!
Nobody cares, about what you need or not. And nobody is asking you to change your entire code base either. When will you start to understand that?
So, let’s take this phone analogy a bit further. It is fine, if you don’t go and spend money on the newest phone.
It is NOT ok to start telling everyone else that the new phone doesn’t have new features and that even the improvements are “evil” and the people who decide to spend money on the new phone and use the new improvements are “mindless monkeys”.
Think about it. If you would stand in front of an Apple store holding signs up saying the new improvements are evil and the people who buy new phones are idiots for doing so, what would happen? At worst, you’d get put up in a mental ward, at best, the passersby would think you are simply barmy.
Scott
Cobblers. I have learned to spot mistakes and never to repeat them.
It is not the wrong path, just a different path. Just because a thousand people keep repeating the same lie does not turn it into the truth.
Exactly. Every one of my Model classes inherits from the same abstract class. What is wrong with that? Some people actually say that classes should only be allowed to inherit from abstract classes, which is exactly what I have implemented.
I understand that inheritance has absolutely nothing to do with coupling. Coupling only comes into play when one module calls another, not when one class inherits from another.
I’ll just quote myself…
Given two approaches we can measure the differences and assess which is better, has fewest drawbacks/most advantages.
Of course it can, most easily by looking at coupling. Tight coupling is by definition less flexible than loose coupling.
And yet you constantly refuse to identify what these best practices are. When you attempt to you cite SRP, which you are clearly not following no matter how many times you claim to be.
You keep bringing your code into it, I am simply scrutinizing it. Don’t bring your code/methodologies up and it won’t get critiqued.
Wikipedia is not authoritative. Here’s an academic paper:
http://people.ucalgary.ca/~far/Lectures/SENG421/PDF/oocross.pdf
. Inheritance introduces significant tight coupling between superclasses and their
subclasses.
Go and read the other thread, I posted some code examples (You still did not) to back up my point. You never said what metric you’re using to measure “better”, provide code samples or even expand on your point when asked.
As I said, it’s tightly coupled. Until you understand what coupling is, you’ll never be able to understand why singletons are bad, why TDD is good and why DI is beneficial. These are all related and this is a major sticking point for you.
Oh and you’ll like this Tony. Your favourite author Robert C. Martin on inheritance and coupling:
http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf
One of the problems with implementing an abstract class with inheritance is that the
derived class is so tightly coupled to the base class.
For reference, this is what you said
Will you admit you’re wrong?