I too would like to see the “amateurish” comments stop. It isn’t that black and white and it’s insulting.
Then I guess you’re an amateur, because what is a class method but a procedure?
Every time you trot out a variation on that arrogant statement you sound like a pompous windbag that doesn’t know what he’s talking about, and I for one am sick of it because I find it disrespectful, acrid, elitist and hostile towards the members of the community with beginner or junior level skill, so please knock it off.
Object Oriented code is an organization scheme. So is procedural coding. The later is suited for small projects - only an idiot uses a chainsaw when a scapel will get the job done. For example, if I need to dispatch an email when a contact form on a simple brochure website is filled out I don’t need the entire Symfony framework. I can write a simple procedure to do it that lives in one file.
The Rule of Single Responsibility applies here. The procedural code you deride falls apart because it violates that rule. Having a single procedure try to fulfill multiple responsibilities is an invitation to disaster. However, classes and their methods can, and often are, guilty of much the same. Just read Tony’s 9000 line class if you don’t believe that. Call it ‘shoehorned procedural’ all you want, you’re missing the point entirely - the problem isn’t procedures, it’s failure to properly separate concerns.
And, I hate to break it to you HoF, but all PHP webscripts (the vast majority of PHP programs we discuss, and with the possible exception of ReactPHP) are procedures. They are launched by the webserver, formulate a response, return it to the webserver and die. Even if they are organized in OO fashion, they move from a set start point to a set end point – a flowchart for all of them runs in a more or less straight line. This is the very definition of a procedure.
Learn that definition before calling people amateurs. There’s no shame in being an amateur, novice or beginner, but there’s a lot of shame in being a pompous windbag that creates a hostile environment for everyone else on the site.
Well procedural programming is for amateurs, in a language that supports OO. You know this is true, it is the industry standard. Accept it or not, it is there for people to follow.
Yeah, both are organization schemes, but why is OOP widely used in serious projects, but not procedural coding? Because procedural programming fails as an organization scheme. With procedural programming, your code is inherently disorganized, and to read or reuse code is difficult if not impossible. OOP on the other hand, is the way to go for organized and clean code. I think theres no need to keep arguing on the obvious truth.
I am not missing the point, you are. You already said it yourself that procedural programming tends to violate single responsibility rule, and Tony’s 9000 lines class is indeed procedural in disguise, not object oriented at all. Procedural programming in general, will violate every elegant, efficient and reusable design principles. It is the very first thing that Pro PHP Refactoring book is telling readers to get rid of. Before you get rid of procedural code in PHP, refactoring is meaningless since you replace spaghetti code with another spaghetti code anyway.
Of course I understand the request/response cycle, at the very end objects are nonexistent, since HTTP is a stateless protocol. Nonetheless, you still write OO for a good reason. By your reasoning, everyone should just write in assembly languages, since at the machine level everything is the same 0’s and 1’s anyway. It doesnt make sense on every aspect.
Industry standards also include being courteous to others, and you obviously skipped class that day.
I never argued that procedural programs should be used for large projects, I argued that they have a time and place. If I need a PHP script to send an email for my clientside JavaScript app I don’t need to load the entire Symfony framework, setup routers objects, request objects, ad naseum. I write 5 lines of code in a procedural program and I’m done. If I need to send through a means other than PHP’s internal mail() function then I’ll load the phpmailer class, create an instance and let it do its thing.
The size of the projects involved have nothing to do with “professional” code. The mark of a professional is treating others with courtesy and respect. You sir have repeatedly failed to do this.
1 Like
@fretburner: That sounds like a constructive suggestion. What is the best way to start ?
I’ve started work on a new (client) web site recently, and although I’ve ported code from similar sites, much of it is new or revised. At present there is only a ‘simple’ availability calendar for a holiday property, there are no pretty pages yet. So perhaps that would be good ?
Yes that sounds good. Perhaps you could start a new thread and post the code (or link to a gist, if there’s a lot of code)?
@ramasaig: If you’re interested in learning OO programming, and you have the time, your time might be better spent converting an old, procedural project to an OO structure. The main reason I say this is that you already know the structure and functionality of the old application, so when converting it, you don’t have to worry about things like requirements definition or worrying about designing a front end. This frees you up to really being able to see the changes you are making to the structure of your code and the benefits you can gleam from those changes.
A few months ago, @swader reviewed a book that walks you through this process:
I’ve read the book but haven’t applied the process to any application, so I can’t personally speak to the effectiveness of the result. The book is well written though, and I believe it can act as an effective road map for someone looking to learn OO programming in PHP.
If you do take the time to go through this process, the last thing I would suggest you do is implement some new functionality into your converted application. It’s often hard to see the benefits of OOP until it’s time to add or change some functionality, so implementing a new feature (even a small one) can help illustrate some of those benefits. Plus, since it’s going to be well structured, you’ll be able to re-use that new feature in your future projects 
1 Like
@fretburner: Thanks for your reply. I suspect there’s too much code to post in a thread (though I probably don’t need to post it all). So I’d better get to grips with github.I’ll try to do something in the next week.
Now you are standing at the moral highground, clever. So I am not treating others with courtesy and respect, just because you dont think I do? Have you read most of my other posts on this forum? I was being as polite and helpful as I can, I know sometimes my answers aint the best but I try my best. I simply stated the objective facts, its this simple. And like I said whether the OP is willing to listen or follow is not my concern.
I am usually lenient at whether people follow the standard and guidelines or not, but of course there are some things that everyone should follow on a per se basis. For instance, do not even talk about organized, clean and reusable code unless you are writing in OOP. There are some concepts and methodologies that do not apply to amateurish procedural code, such as refactoring. But either way, you have every right to disagree, and this is again not my concern.
Says who? The concept of refactoring has been around a lot longer than OOP has.
And sorry, but OOP code can be just as “amateurish” as procedural code. It all depends on the developer and their ability to use the appropriate coding style/base where appropriate. Just because you use OOP doesn’t mean you’re a professional. Bad code is bad code, period.
Can I take a approach this topic from a slightly different perspective… in what situation is procedural code preferable to OOP?
OOP generally uses more memory, executes more slowly (Although not always!) so is less suited to performance critical tasks. Is there anything else?
From a programmers perspective, OOP offers far more flexibility, it’s easier to move code between projects and it’s far easier to test.
The reason procedural code often comes across as “amateurish” (not that I like the term) is that most developers who are at a level where they understand the difference enough to make the choice choose OOP because of the above. Because of this, most procedural code you run into in the wild is indeed written by less skilled developers, simply because they do not understand there is a choice. That is different, however, to saying “All procedural code is amateurish”.
That said, the scope for writing good procedural code is a lot narrower than the scope for writing good OO code simply because OO offers features/tools that can improve the code that procedural just doesn’t have. (Encapsulation and Polymorphism being the main ones) and there aren’t many situations where given the choice, procedural code is the better option.
3 Likes
I’d say that scope is roughly 20 executed lines, more or less. Anything past that and it becomes increasingly difficult to justify not using objects.
Another way to think of it is this, if the whole task could be covered by a class with a single method it’s probably better off being left as a straight procedure.
2 Likes
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.