Are today's major frameworks capable of enterprise capable applications?

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?

I disagree. In Uncle Bob’s article at http://blog.8thlight.com/uncle-bob/2014/05/01/Design-Damage.html is says the following

That is PRECISELY why I have my GUI, business rules and database access in separate modules.

You still haven’t learned to read, have you? If you too the time to read http://php.net/manual/en/language.oop5.autoload.php you would see the following in the very first paragraph:

I do not have to write a long list of needed includes and the start of each script, therefore there is no annoyance. If there is no annoyance there is no problem, and if there is no problem there is no need for a solution.

Do you believe there are any objective measures or standards by which someone could compare the quality of one piece of code against another?

1 Like

Ooooh with the obfuscation. Is 400+ not a long list? Just because you chose to put them outside the top of the file (A bad practice even in the days of PHP4 because it makes it impossible to see what dependencies a file has).

Just because you don’t want to use something doesn’t mean it doesn’t solve a very valid problem. As I said before, there are numerous advantages to autoloaders (Development time, developer memory usage, flexibility, fewer lines of code) that. Unless you can demonstrate a situation where autoloaders are measurably inferior to another approach and explain how you’re making that measurement your words are worthless.

[quote=“tony_marston404, post:326, topic:114913”]
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. [/quote]

No, you don’t get to move the goalposts today. At that particular moment I wasn’t addressing that claim, I was addressing this one.

So I gave a very simple situation that proved you dead wrong. You’re trying to work from the premise that there is no such thing as better - period. And that’s easily proved wrong. Better can be measured and quantified, if in nothing else than money - better things cost more.

1 Like

So now you are mixing up SoC with SRP? Come on Tony. Stick to SRP please.

Oh right. You don’t do OOP properly. I forgot. If you did, you’d have that same issue. But, you still do have to make sure your class instantiations have some include or require before the instantiation. Don’t you? So you still have at least a part of the problem autoloaders alleviate.

Scott

Neither of those articles put “inheritance” and “coupling” in the same sentence, so they are not related. Your article does not mention inheritance at all.

As I said, you don’t understand coupling, stop trying to discuss concepts you clearly have a lack of understanding of. What’s annoying is that you’re arguing that the concepts that you don’t understand are wrong rather than learning what the concepts are.

If you had any idea what coupling was you’d easily be able to understand why inheritance creates tight coupling.

Then what would you think of a popular PHP email library that uses over 120 separate classes, some of which contain just a single method with a single line of code, just to send an email? That, to me, is a perfect example of code which has been degraded from “modular” into “fragmented”.

That is the most ridiculous statement I have ever read. 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 one simple question - if I take out the code which allows that class to communicate with other layers, then how am I supposed to communicate with other layers?

The ORIGINAL definition of coupling is defined thus

This is clearly limited to when one module calls another, not when one class inherits from another. The fact that some people have chosen to use the word “coupling” to describe the effects of inheritance is a silly mistake on their part. This is just as silly as the notion that inheritance breaks encapsulation.

If you bothered to read that article which you cited you would have read the following:

This quite clearly states that when examining code using various metrics that the effects of inheritance can be ignored.

Hah! Wow. Backtracking much?

Answer this question: In your own words:

I repeat - inheritance has absolutely nothing to do with coupling, therefore it is quite wrong to say that inheritance automatically produces tight coupling.

and

Neither of those articles put “inheritance” and “coupling” in the same sentence, so they are not related. Your article does not mention inheritance at all.

and

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.

“So they are not related”, “inheritance has absolutely nothing to do with coupling”, “it is quite wrong to say that inheritance automatically produces tight coupling.”

Robert C. Martin (Someone you often reference as an authority) says:

One of the problems with implementing an abstract class with inheritance is that the derived class is so tightly coupled to the base class

These opinions are clearly contradictory. Is Robert C. Martin wrong or are You?

You’ll probably try to claim that that somehow the statements don’t contradict each other but that would be a flat out lie. as it’s cut and dry. You can’t even weasel your way out and erroneously claim that it doesn’t apply to abstract classes because he mentions them specifically :stuck_out_tongue:

And remember this: If you say uncle bob is wrong, anywhere else you’ve cited him as an example to back up your claims becomes invalid because clearly he’s not an authoritative source.

You’re clearly wrong here. Admit it and I’ll let it go.

More importantly, what this does prove is that you don’t know what coupling is which invalidates any argument you have made on the subject of DI, singletons singletons and to a lesser extent TDD as understanding the pros/cons of them relies on a understanding of coupling.

I repeat, inheritance has nothing to do with coupling.

Please answer this question…

In your own words:

I repeat - inheritance has absolutely nothing to do with coupling, therefore it is quite wrong to say that inheritance automatically produces tight coupling.

and

Neither of those articles put “inheritance” and “coupling” in the same sentence, so they are not related. Your article does not mention inheritance at all.

and

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.

“So they are not related”, “inheritance has absolutely nothing to do with coupling”, “it is quite wrong to say that inheritance automatically produces tight coupling.”

Robert C. Martin (Someone you often reference as an authority) says:

One of the problems with implementing an abstract class with inheritance is that the derived class is so tightly coupled to the base class

These opinions are clearly contradictory. Is Robert C. Martin wrong or are You?

You’ll probably try to claim that that somehow the statements don’t contradict each other but that would be a flat out lie. as it’s cut and dry. You can’t even weasel your way out and erroneously claim that it doesn’t apply to abstract classes because he mentions them specifically :stuck_out_tongue:

And remember this: If you say uncle bob is wrong, anywhere else you’ve cited him as an example to back up your claims becomes invalid because clearly he’s not an authoritative source.

You’re clearly wrong here. Admit it and I’ll let it go.

More importantly, what this does prove is that you don’t know what coupling is which invalidates any argument you have made on the subject of DI, singletons singletons and to a lesser extent TDD as understanding the pros/cons of them relies on a understanding of coupling.