Just because you perceive them to be disadvantages does not mean that everyone else will jump to the same conclusion. My software is certainly not inflexible as I have been regularly extending and enhancing it to deal with new situations and requirements for over 10 years. It is certainly not difficult to understand as my business partner and his team of developers in India have been able to use it to build applications.
Your claim that my software is hard to reuse in other projects is completely irrelevant. It is not a collection of libraries where you can pick and mi what you want, it is a fully-fledged RAD framework which you either use in its entirety or not at all.
You clearly do not understand the difference between “dogmatic” and “pragmatic”. The former is rules oriented and assumes that by following the rules with blind obedience that the results should automatically be acceptable… The latter is results oriented and will make or break rules in order to get the job done. By insisting that I follow your interpretation of the rules you are clearly a dogmatist.
I disagree. Whether you like it or not PHP is a multi-paradigm language, so it is entirely up to me if I choose to mi procedural and OO code. Saying that using procedural is wrong is in itself wrong.
I am not sidestepping any issue. You are telling me that I am not allowed to use procedural code anywhere in my software, and I am telling you that I will not comply.
I disagree. You are saying that because I choose not to write code in the same way as you that my code is automatically bad, but you are forgetting one important point - there is no single way of writing code which is universally accepted as being either “best” or “right”. There are many ways to achieve a result, and I choose a way which is different from yours, as do many other developers.
Unit testing certainly does not help me produce results more quickly as the time taken to write unit tests is often much longer than the time taken to write the production code in the first place.
The use of autoloaders and namespaces will have absolutely no effect on the result. If I have code that currently works without such things, then changing that code to incorporate them just because they are fashionable will not add any benefits whatsoever.
And yet you keep avoiding all my questions. As I already said, autoloaders are a pragmatists dream, they solve a very practical problem yet because they were introduced in PHP5 you don’t like them. Why is anything that you found out about after about 2005 and other people use “non-pragmatic”? I get the feeling that if function arguments were invented after 2007 you’d be arguing that anyone trying to explain their virtues to you is being “dogmatic”. There are measurable benefits to all best practices and modern techniques. We get it, you don’t want to use them but why come here and try to argue against their use? There’s nothing dogmatic about saying “Dependency inejction has fewer drawbacks than singletons” or “autloaders help reduce repeated code” or “namespaces prevent class name clashes so more easily allow code reuse” these aren’t “dogmatic”, they’re entirely pragmatic so just stop.
Allowed? There’s no laws here. I’m just pointing out that trying to put a square peg into a round hole is never the best method.
There are however, best practices. I’m not going into it again because we’ve gone over it a hundred times and you have made it clear you don’t want to listen. These best practices exist for a reason because each one provides a measurable benefit.
And again you just prove you don’t know what you’re talking about. Go read about unit testing before dismissing it. Unit testing makes testing faster. Got a form with 50 fields? Without unit testing to test it you must fill out the form each time. Change the way the result is processed? you have to fill out all 50 fields and test the new result… notice a problem? You have to do the same thing? Are there multiple code paths based on the user input? You’ll need to fill out the form for each of these situations. Unit testing allows you to test the result without filling in the form each time. Once you’ve written the test you can use it as many times as you like. Isn’t it a clue to you that all professional software (Windows, Mozilla Firefox, Open Office, Linux, Google Chrome and even the PHP language itself etc etc ect…) is unit tested?
For the hundredth+ time, nobody is asking you to change your code and this statement is factually wrong. Autoloaders mean you have to write less code meaning you can produce the end product faster with them. Namespaces allow you to easily use other peoples code in yours without name clashes (although you don’t like other people’s code but that’s another issue entirely)… being able to use other people’s code in your projects lets you build the end result faster. So “No effect on the end result” is you, yet again, not understanding basic php programming practices.
The problem with SRP is that it does not provide a clear and unambiguous definition of “single responsibility”, so it is open to misinterpretation and misunderstanding. By applying SRP intelligently you can convert a monolithic system into a modular system which is easier to maintain and extend. By mis-applying or over-applying it you change the system from being modular to being fragmented, which then makes it more difficult to understand, maintain and extend.
I have produced software which is based on a combination of the 3-Tier Architecture and the MVC design pattern, so in my opinion it is as modular as it needs to be. You may think that a 9,000 class is bad, but you are missing the point - it is an abstract class which is inherited by everyone of my Model classes, so it actually contains 9,000 lines of reusable code. How much reusable code do you have in your software?
That is just your opinion, and it is an opinion which I do not share.
I do not agree that “all OO, no procedural” is the way to go. As a pragmatic programmer I will only use OO techniques where they have clear advantages of procedural code.
You have constantly told me that in your opinion I should reassess my approach to software development, and I have constantly replied that in my opinion your favoured approach does not impress me one little bit and I see no reason to change what has been successful for me for over a decade.
Just because the language changes by introducing a new way of doing something does not mean that I should go through my entire code base and switch from the “old” way to the new" way. As a pragmatic programmer I do not see any justification in changing code which works into code which works the same, but differently.
The principles of good programming have not changed at all, just the tools by which those principles can be achieved. Just because a new feature is introduced into the language, such as autoloaders and namespaces, does not mean that I should use that feature. Just because someone develops a new technique for doing something, such as dependency injection, does not mean that I should use that feature. I have stated this many times already, I actually DO USE dependency injection in my software, but only in those places where it provides genuine benefits. Just because some people choose to use it everywhere does not mean that I should follow suit.
A new way of doing an old thing is not necessarily an improvement, it is just a different way of doing the same thing. A design pattern which is designed to work in certain circumstances, such as DI, should not be used where those circumstances do not exist.
I disagree. I will only change to using a different technique when that technique can be shown to have benefits. I will not implement a technique just because it is fashionable.
I disagree. The first rule of programming that I learnt in the 1970s is that software needs to be readable by a human being more than executable by a computer. A well structured program is more readable than a badly structured program. A modular program is more readable than a monolithic program. Over the years I have changed my programming language several times, and each language has provided different ways of achieving similar results. The fact that my programming style is different from yours is irrelevant - there is no such thing as a single style which is universally accepted as the only style that is worth following.
I don’t think you understand what “reusable” means in the context of OOP. Your abstract class has methods which are reusable only to classes which extend it. A proper object is reusable anywhere in the system by any other class. It’s back to tight/loose coupling. Inheritance is always tight coupling. For example, your 9000 line class has a fair amount of repeated logic in its get*data functions a bunch of if statement branching. If you Replaced conditionals with polymorphism you wouldn’t need that if (is_object($this->custom_processing_object)) { line hundreds of times an you could remove all the code that was only relevant to ‘custom_processing_objects’ (whatever the hell that are) to their own class. This is just one of dozens of examples in that single 9000 line file but anywhere like that where you have a repeated if statement, separating out the responsibilities better gives you leaner classes with better separated responsibilities.
All implemented languages features have benefits in some scenarios. Your refusal to use autoloaders, private visibility or any other language tool that was implemented in PHP5 demonstrates that your statement is untrue, unless by “fashionable” you mean “Less than 10 years old” (or more accurately, things that were new to you in the last 10 years).
And we’re back to this. I’m not going to try to teach you what best practices are for any more, I’m not going to educate you because you clearly don’t want to listen. If you don’t want to listen, do us a favour and also stop talking. Best practices (and bad practices) exist for a reason, they’ve been tried and tested by thousands of people who have discovered benefits/drawbacks to comparable approaches. Unless you’re willing to comprehend this (you’re not) there’s no point you having this discussion as more things get tried in more scenarios and new language features are implemented they emerge. They change over time.
Incorrect. They solve a particular problem, but as I don’t have that particular problem I don’t have need of this solution.
Incorrect.
I disagree that the benefits of using a particular technique can be measured. What measurement do you use? Lines of code? Time taken to write the code? Time taken to read the code? It is all down to opinion and personal preference, and my opinions and preferences are different from yours.
I don’t have any name clashes in my code, so I have no need for namespaces.
Since when is using a mixture of procedural and OO code putting a square peg into a round hole?
I AM following best practices, but they are not the same as yours.
Whether you have unit tests or not does not get away from the fact that a human being still has to test everything as testing for usability cannot be automated. Having unit tests may be useful, but you need to spend a lot of time in writing those tests. You seem to forget that I wrote my framework and my major application years before unit testing became fashionable, so the time that would be needed to create those tests for an existing application would be absolutely enormous. I would much rather spend my time in servicing my customers’ needs - and get paid in doing so - than writing code that costs a huge amount but has no value as far as the customer is concerned.
You are doing it again. You are telling me why I should be using autoloaders and namespaces and completely disregarding the fact that I do not have the problem for which these are the solution.
Using (or not using) autoloaders and namespaces has nothing to do with “best practices”, just “fashionable practices”.
That is every one of the 300+ Model classes in my application. Each time I add a new Model class it instantly has access to those 9,000 lines of shared code.
Where is that written? For your information any one of my 300+ Model classes can be used by any one of my 40+ Controllers simply because each of those Controllers uses methods which are defined in the abstract class. This is an example of polymorphism in action.
Where did that silly idea come from?
With the emphasis on some, not all scenarios.
I know what they are for, I just disagree that there is a single version of “best practices” which is universally accepted by all programmers. Each group of programmers is allowed to choose what they think is best for them, and my choice just happens to be different from yours.
Now you are the one who is backtracking. You have repeatedly taken examples from my existing framework and told me why I should change that code into something which is acceptable by you.
Even though my framework was created over a decade ago I am still using it today to build new applications, or add new modules to my existing enterprise application, and I see absolutely no reason why I should spend time in changing code that works into code that does exactly the same thing but differently.
Let’s have a headcount then, who’s on your side? You sound like the politicians denying climate change citing the one scientist they bribed against the 99 others in the field and trying to claim parity.
You wouldn’t know flexible if it ran you down like a freight train. I’ve worked with monstrosities like you’ve created and cleaned up after “programmers” like you after they’ve collected their fees, abandoned their clients and moved on to the next job. Flexible? I’ve read your code so I say, In a pig’s eye. For starters, no unit tests to prevent regressions.
Longevity is no mark of quality. If you don’t believe that statement I invite you to try any one of a number of mainstream American beers like Budweiser. Foul doesn’t begin to describe the stuff, but it has fans which proves any taste can be acquired.
Given the reputation of offshore Indian programming firms that is not a glowing endorsement. Quite the opposite actually.
Then per definition it is not modular or object oriented in the slightest
But that does remind me of something that no one else has brought up in this long bickering war. Hypothetical situation - suppose you had to apply a patch to every RAD site you’ve ever made - patch that has to touch multiple critical components you’ve had to customize the behavior of for those deployments? WITHOUT having to customize the patch for each site? I’m guessing you can’t.
I’ve been through that nausea too y’know at a company that won’t be named that had 12 clients on a custom-ware like RAD and not surprisingly each one was running a slightly different variation because with each client the software was “extended and enhanced to deal with new situations” It was a nightmare.
Such is always a nightmare unless you’re a fire and forget developer providing no support past the initial deploy. And that frankly is the only scenario I can see RAD working - fire-and-forget.
And we’re back to “I solved the problem in a different way so I don’t have the problem X solves” Can you please stop this argument as it’s utter nonsense.
Of course they can be measured. For me the the biggest one is flexibility: how easy is it to substitute a function/class with another? If you have to change the function definition rather than where it’s called to do this, it’s inflexible. This is a measurable effect. Inflexible:
function foo() {
$bar = new bar();
$bar->baz();
}
Flexible:
function foo(Bar $bar) {
$bar->baz();
}
This function is reusable with other collaborators, by measure of flexibility is is quantifiably better.
How are you quantifying “better?” This is something you never answer when asked.
Because OOP gives you features such as polymorphism an encapsulation. Trying to use procedural code with this voids those features and makes the code less flexible as a result.
Which best practices are you following?
Single responsibility principle? Nope.
Favour composition over inheritance? Nope
Use DI instead of singletons? Nope
Avoid global state? Nope
And yet again you prove that you’ve never done unit testing and don’t understand what it’s for. On any non-trivial application unit testing will save you time. Don’t believe me? Here’s a study that was done: http://www.msr-waypoint.net/en-us/groups/ese/nagappan_tdd.pdf
Our experiences and distilled lessons learned, all point to the fact that TDD seems to be
applicable in various domains and can significantly reduce the defect density of developed
software without significant productivity reduction of the development team. Additionally,
since an important aspect of TDD is the creation of test assets—unit, functional, and
integration tests. Future releases of these products, as they continue using TDD, will also
experience low defect densities due to the use of these test assets. Specifically, recent
contact with the IBM team indicated that in one of the subsequent releases (more than five
releases since the case study) some members of the team (grown 50% since the first release)
have taken some shortcuts by not running the unit tests, and consequently the defect density
increased temporally compared to previous releases.
And over time, because there are less bugs, time taken for newer releases will be faster.
This whole “I wrote my framework 10 years ago” thing is nonsense. 1) Nobody cares, we’re trying to discuss the merits of different approaches and you’re saying “I don’t use X therefore it’s bad somehow” and 2) There’s no reason you can’t have adopted newer techniques in code you have written in the last 10 years, or was the last line of code you wrote over 10 years ago?
Sorry, what? Using namespaces is most definitely a “best practice” simply because it allows developers to share code without name clashes at zero cost. I know you don’t use other people’s code so it doesn’t effect you but you cannot seriously argue against this being a best practice. Autoloaders aren’t a “best practice” per se they’re just a non-brainer for anyone who understands what they do.
You argument really is just “I don’t like them because they didn’t exist in PHP4”.
Each time you post something like this you dig yourself deeper into that hole of ignorance. You prove to us continually that you do not belong in this discussion as you have an inadequate level of expertise. Go and learn about coupling before making such snide comments.
Here’s a hint: For inheritance to be loosely coupled you’d need to be able to do this:
$parent = 'Y';
class X extends $parent {}
Which other than making zero sense from a design perspective, isn’t possible.
The problem is, every time we have a conceptual discussion about the merits of different approaches you come in and say “X IS EVIL. I DON’T USE IT IN MY CODE” The only way we can progress that discussion is by looking at the code you are referencing and showing you that your assumptions are incorrect (And they always are, like the DI topic you gave up on after we proved you wrong. Please do the same here).
I’l agree not to bring up your code if you don’t. In fact I’d much prefer not to have to but you can’t help yourself but bring everything back to “My 10 year old poorly written framework…”
I disagree. Flexibility is defined as “designs that can adapt when external changes occur”. I have modified, enhanced and adapted my code to changing requirements for more than 10 years, and without any difficulty.
I do not work like that. I have a support agreement with my clients so that I continue to deal with both bugs and enhancements for the applications which I create and install for them. The first user of my enterprise application started in 2008, and I still support him to this day.
The absence of unit tests has no bearing on whether software is flexible or not.
It is a much better indication of quality than something that is used once and then thrown away. A product that is still being used after 7 years, and is still being sold to new customers, cannot be the complete pile of junk that you seem to be implying.
Just like software which has been assembled using inappropriate design patterns or techniques can be judged as “foul”. Some people continue to produce such foul software because that is what they have been taught. In my long career I have learned to avoid such foul practices.
If you are saying that Indian developers are only “average” developers and not “rock stars” then it proves my point that you don’t have to be a rock start developer to understand my code. Any idiot can write code that only a genius can understand, but a true genius can write code that any idiot can understand.
Both my framework and the applications which I write with that framework have been broken down into distinct and separate modules, therefore it IS modular whether you like it or not. The opposite of “modular” is “monolithic”, and my code is certainly not monolithic. The fact that one of my modules cannot be taken out of my framework and plugged into a totally different framework is irrelevant.
It IS object oriented by virtue of the fact that I have made use of encapsulation, inheritance and polymorphism to increase code reuse and decrease code maintenance. That is the ONLY requirement of OOP.
Then you guess wrong. I release enhancements to my framework at regular intervals (89 updates since the first release in 2006) and I have almost never broken backwards compatibility with existing applications.
A feature of my framework, and any applications which are written using it, is that I keep core code totally separate from customisations. Each customer’s customisations are kept in a separate subfolders, so it is possible for 10 customers to have their own customisations for the same component without any issues.
Then you would be wrong. I used my RAD framework to create an enterprise application in 2007. Not only is the first client still using it but I am also selling it to new customers as we speak. The current version of this application has received many updates and enhancements since the original release, so it has proved to be very flexible and very adaptable.
Have you ever written an application that has run for 7 years?
Can we please move beyond anecdotes “I found that”, “in my experience”, etc as they’re utterly meaningless without a quantifiable way of backing things up. If you’re saying “Method X is more flexible than method Y” or “Method X is better than Method Y” you must back it up with something other than “That’s how I do it currently”. Without quantifying how you’re measuring these things and code examples comparing the two different methods, everything you say is worthless.
Can you believe someone cited his “DI is evil” article as a disadvantage for DI? Notice though it isn’t “DI breaks encapsulation”, but rather “DI diminishes encapsulation”.
Who is to say that the reverse is not true? I have correctly implemented a combination of both the 3-Tier Architecture and MVC design pattern where each module or layer has its own separate and distinct responsibility. This is a modular system. But there are some people out there who simply do not know when to stop this process of separation, and they end up by turning a modular system where each module is a cohesive unit into a fragmented system which has so many tiny parts that it becomes very difficult to comprehend and therefore difficult to maintain and extend. The idea that a single class should not contain more than X methods, or each method should not contain more than Y lines of code, has no rational basis. It is merely the plucking of numbers out of thin air and calling it a “principle”. You may think that my “monster” class with 120 methods and 9,000 lines of code is a sign of bad programming, but what about going to the other extreme? There is a popular PHP email library out there which uses 120 classes just to send an email, and most of these classes contain a single method with a single line of code! Which in your opinion would be the easiest to read - a single class with 120 methods, or 120 classes with a single method each?
Or perhaps they see the benefit of a pragmatic mind over one which is restricted by dogma.
Then why have I been told constantly in this and other threads that I should change my well-established code base to incorporate “new” ideas such as namespaces, autoloaders, DI, et cetera, for no good reason other than they are “new” and “fashionable”. Being a pragmatic programmer I see absolutely no reason why I should make use of a new idea unless it provides genuine benefit. In my opinion doing the same thing but in a different way does not provide any sort of benefit.
History is full of ideas which fall into fashion one day and fall out of fashion the next. I don’t write fashionable software, I write effective software.
I disagree. DI was originally designed to be used only when a dependency can be supplied from one of several sources, which is exactly how I use it. When a dependency can only come from a single source which will never change then DI is not appropriate. In those cases I choose NOT to use DI but employ a singleton instead.
There is nothing wrong with using the occasional include/require statement. Seeing that all these statements are contained within my framework and I never have to write a single include/require statement in any application components which I generate from my framework, there would be absolutely no benefit in going through my entire code base just to change code which works into different code which does exactly the same thing but differently.
I don’t have any naming conflicts, so I don’t need namespaces.
Not all new ideas are genuine improvements, they simply provide a different way of doing something that is already being done.
So you admit your monster class is a bad extreme? Because you are right, it is the “other” extreme, as there can also be too much fragmentation, although I’d say it is less a problem than a class that does way too much.
Your class does not fit the definition of SRP Tony, which is a simple answer to a simple question. If you need to change your class, for what single reason do you need to change it? You have probably at least 20 reasons to have to change your class.
No, it is not pragmatic to use your framework, when there is a world of better programming available. It is barmy.
Nobody is saying you should change your code base. Everyone is saying you should stop using your code base, as a basis for your arguments.
Where DI would have no disadvantages over a singleton. Just because you decided to go this route doesn’t mean DI is wrong to be used in the same situation. This is one of your terrible arguments, where you use your code as a basis for proof and fails miserably
Oh boy. Dancing around the point again. Nobody said there is anything wrong with using include or require statements. The point is, it is simply more elegant to not have to worry about having to write include or require statements. Can’t you agree that is an improvement over writing include or require statements?
Just because you don’t have the ability or the need to use code produced from other developers, it doesn’t mean namespaces isn’t a nice improvement. It IS a great improvement.
Right, a navigation system in a car is just like using a paper map. A telephone and armband that can measure your health statistics, is just like a doctor you have to go to regularly. The ability to store data on the Internet and have access to it from any device, is the same as a USB stick.
Naturally, if you always use a paper map, go to the doctor regularly and carry around USB sticks, you don’t need the new stuff. But still, they are improvements, just like the things we are talking about are PHP improvements.