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

[s_molinari]

@tony_marston404

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?

Dependency Injection is EVIL

They often signal that the components wired together represent different or independent concepts or responsibilities, or belong to different abstraction layers in the system.

Scott

[TomB]

@tony_marston404

I am not backtracking, I do not write new applications from scratch, they are all built using my framework which was constructed years before autoloaders existed. That framework runs perfectly well without autoloaders, so refactoring it to use autoloaders is both unnecessary and economically unviable.

As I said nobody is asking you to rewrite the existing lines but you’ve written require_once lines enough times in the last 10 years to have made that time pay off. Once you’ve written an autoloader you don’t need to touch it again, with require_once you need to type it out every time and look up/mull over what the name of the file the class is stored in is. Not to mention, require_once lines take up screen space meaning that you’ll have spent more time mentally scrolling past them than you otherwise would have to had.

[DaveMaxwell]

@TomB

Not to mention, require_once lines take up screen space meaning that you’ll have spent more time mentally scrolling past them than you otherwise would have to had.

Not to be pedantic, but this has to be one of the DUMBEST reasons I’ve ever heard as to why a person would want to change a piece of code.

[TomB]

@DaveMaxwell

Not to be pedantic, but this has to be one of the DUMBEST reasons I’ve ever heard as to why a person would want to change a piece of code.

I never said anything about retrospectively changing anything, I was just pointing out that writing require_once lines instead of using an autoloader will have other knock on effects with regard to development time than just typing out the line. In tony’s words using an autoloader is “economically unviable.” and has been for 10+ years. The time saved by using an autoloader 10 years ago would have paid for itself dozens or hundreds of times over.

[Mittineague]

@TomB

writing require_once lines

Does not your IDE have auto-complete?

[TomB]

@Mittineague

Does not your IDE have auto-complete?

It certainly doesn’t know the file name I’m about to type… Even if it magically did, clicking a button/pressing a key to autocomplete still takes time that wouldn’t be spent when using an autoloader. (And writing an autoloader for tony’s code would take all of about 10 seconds given his class/file structure here: http://pastebin.com/31sHHv75 )

[tony_marston404]

@TomB

@tony_marston404

Coupling involves the amount of code required for one object to call another, and how this code would need to be modified following any changes made to these two objects. This is all explained in http://en.wikipedia.org/wiki/Coupling_(computer_programming) in which the word “inheritance” does not appear at all.

So Wikipedia is now more authoritative than Robert. C. Martin?

In this instance, yes. Just because I agree with some of the things which Uncle Bob says does not mean that I have to agree with everything he says.

@TomB

Also, are you blind? From that exact page:

Subclass Coupling
Describes the relationship between a child and its parent. The child is connected to its parent, but the parent is not connected to the child.

I still maintain that the coupling which results from one object calling another is completely different from the coupling which is produced from one class inheriting from another. Same word, but different meanings in different contexts.

That article also states the following

Low coupling refers to a relationship in which one module interacts with another module through a simple and stable interface and does not need to be concerned with the other module’s internal implementation

This means that even if there is coupling between a superclass and its subclass, it would be wrong to state that the level of coupling would automatically be tight.

[tony_marston404]

@s_molinari

Like I said earlier. SoC and SRP are two different things.

How are they different?

[tony_marston404]

@TomB

One of you is wrong, which is it?

He is.

[TomB]

@tony_marston404

In this instance, yes. Just because I agree with some of the things which Uncle Bob says does not mean that I have to agree with everything he says.

Aha excellent so we can now ignore any article you bring up citing uncle bob as he’s clearly not a trustworthy source.

@tony_marston404

This means that even if there is coupling between a superclass and its subclass, it would be wrong to state that the level of coupling would automatically be tight.

Again, Uncle Bob and everyone else disagrees with you. The reason for that is that the implementation is fixed to a very specific one $this->method() will always call the same implementation of a method (it’s tightly coupled) $this->foo->method() can call one of many possible implementations, it’s loosely coupled.

And so much backtracking. So now there is coupling but it’s not tight? What is the difference between tight and lose coupling in your mind, give me a code example of each.

As a starting point, do you now admit these two things you said are painfully wrong?

Neither of those articles put “inheritance” and “coupling” in the same sentence, so they are not related.

and

I understand that inheritance has absolutely nothing to do with coupling.

Because if so, you’re finally admitting you don’t understand coupling.

edit: Here are some more sources for inheritance = tightly coupled

http://openlandscape.net/2010/05/11/taking-another-look-at-inheritance/
http://www.agile-code.com/blog/composition-over-inheritance/

http://c2.com/cgi/wiki?InheritanceBreaksEncapsulation

Inheritance creates a tight coupling between base and derived classes.

http://www.artima.com/cppsource/codestandards3.html

Avoid inheritance taxes: Inheritance is the second-tightest coupling relationship in C++, second only to friendship. Tight coupling is undesirable and should be avoided where possible.

Please find me some sources that claim inheritance is “loose coupling”.

[tony_marston404]

@TomB

The time saved by using an autoloader 10 years ago would have paid for itself dozens or hundreds of times over.

If autoloaders had been available when I created my framework then I would have used them. But they weren’t, so I couldn’t. Instead I used what was available, and that method still works just as good now as it did then.

[TomB]

@tony_marston404

If autoloaders had been available when I created my framework then I would have used them. But they weren’t, so I couldn’t. Instead I used what was available, and that method still works just as good now as it did then.

PHP5 was release in 2004. Even if you supported PHP4 until 2010 that’s still 5 years where you could have used an autoloader and chose not to. In 20 years time will you have implemented one? Even if only you write one requre_once line every 6 months it will only take a couple of years for the time spent typing out the lines to total more than the 10 seconds it would take to write an autoloader.

edit:

given the autoloader

function __autoload($name) {
	require_once $name . '.class.php';
}

This is 60 characters. Given an average class name of 10 characters e.g. require_once '1234567890.class.php'; the line is 36 characters. By the time you have written two require_once lines the autoloader has paid for itself.

[tony_marston404]

@TomB

Please find me some sources that claim inheritance is “loose coupling”.

Just because some people say that inheritance produces tight coupling does not mean that everyone agrees. And unless you can point to the “problems” caused by inheritance which means that it shouldn’t be used at all your argument has no point at all. If it is so much of a problem then inheritance wouldn’t be allowed at all, which would completely destroy the whole concept behind OOP. Next you will be telling me that polymorphism produces tight coupling or somesuch and should be avoided as well. Perhaps the only way we can avoid the problems produced by OOP is to abandon the whole idea and go back to procedural programming.

[TomB]

@tony_marston404

Just because some people say that inheritance produces tight coupling does not mean that everyone agrees. And unless you can point to the “problems” caused by inheritance which means that it shouldn’t be used at all your argument has no point at all. If it is so much of a problem then inheritance wouldn’t be allowed at all, which would completely destroy the whole concept behind OOP. Next you will be telling me that polymorphism produces tight coupling or somesuch and should be avoided as well. Perhaps the only way we can avoid the problems produced by OOP is to abandon the whole idea and go back to procedural programming.

And now you’re backtracking and moving the goalposts. Does inheritance create coupling or not? Do you admit these statements you made are wrong:

Neither of those articles put “inheritance” and “coupling” in the same sentence, so they are not related.

and

I understand that inheritance has absolutely nothing to do with coupling.

http://www.objectmentor.com/resources/articles/inheritanceVsDelegation
https://groups.google.com/forum/#!topic/comp.object/Kz3bBzSf9t0
http://codingdelight.com/2014/01/16/favor-composition-over-inheritance-part-1/
http://blog.berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/
http://misko.hevery.com/2008/07/30/top-10-things-which-make-your-code-hard-to-test/

Robert C. Martin again:

Inheritance it the tightest bound relationship there is.

Is that enough reasons for you?

[s_molinari]

@tony_marston404

Like I said earlier. SoC and SRP are two different things.

How are they different?

I think this blog hits the spot.

Separation of Concern vs Single Responsibility Principle ( SoC vs SRP )

And now that I think about it, your monster class breaks both.

Scott

[s_molinari]

@tony_marston404

If autoloaders had been available when I created my framework then I would have used them. But they weren’t, so I couldn’t. Instead I used what was available, and that method still works just as good now as it did then.

So is that an admittance, that you would agree, when I say, autoloaders aren’t just a fad, but a decent improvement to PHP?

Scott

[Michael_Morris]

@tony_marston404

I did not say that there is no such thing as “better”, I simply said that it cannot be measured scientifically.

And you’re wrong. Economics is a science. Specifically a social science about the value of things. Things which are better (or at least perceived as such) command a higher price in a free market.

[s_molinari]

@tony_marston404

He is.

Oh my.

Scott

[tony_marston404]

@Michael_Morris

tony_marston404:
Have you ever written an application that has run for 7 years?

Yes. One was recently replaced after having ran for 9, and I’m glad its gone

That is probably because you and your cohorts made one or both of the following mistakes:
(a) You failed to build an application structure that could easily be enhanced and extended.
(b) You failed to apply enhancements or extensions in a proper manner which resulted in the application being slowly degraded over time.

I do not suffer from such failings. The application structure which I created all those years ago is still going strong despite undergoing monthly enhancements. The enterprise application which I started in 2007 is still going strong despite the original subsystems being extended and new subsystems being added. That code is just as easy to work on now as it was then. While your legacy software is fit for nothing but the scrap heap, my software is still as sound as a bell and as fresh as a daisy.

But that’s only my opinion, and as a heretic and a non-believer I know that my opinions don’t count in this forum. But do I care?

[Jasmine]

I am extremely disappointed in a lot of you on this thread.

Aristotle has a famous phrase, “it is the mark of an educated mind to entertain a thought without accepting it.”

Essentially it means that while you may not agree with someone’s opinion, you can still be capable of discussing it.

Let me make this very, very clear.

Disagree with a thought all you want. Argue until we run out of server space. Go for it. But do not personally insult another person on this forum. Not only is it against our rules, it’s against human decency. Insult the argument but not the person.

If the only way you can defend your own thoughts, code, or beliefs on this forum is to insult the person you’re talking to, you’re not welcome here.