Hall of Famer

Looks like nested class is also on RFC now, things are shaping up faster and better than I originally thought: https://wiki.php.net/rfc/nested_classes

As far as I know, you need 2/3 of votes, so thats about 66.7%. It seems to me that property accessor gets 34/56 last time, which is about 60.7% of the votes(6% lower than required). Perhaps BC was the cause of all these, wonder if its possible to re-vote or that whatever gets rejected will never be re-considered.

I actually like the extended keyword support a lot, its not for me to decide which feature gets past the voting phase though. Varadics have already made it to PHP 5.6, so its not really an issue here. Come to think about that, it seems that C# accessor methods gets rejected despite more than 60% of the voters said yes(it needs to make 2/3 or more). I doubt if this means that this idea is dropped forever, or that the RFC creator can still make a comeback by making some major/minor modifications of the initial proposal. I personally like to see accessor methods implemented in PHP, but life is not much tougher without it so I can live with that.

Thoughts? https://wiki.php.net/rfc/anonymous_classes

Of course I know what is an IOS and what is an OSX, I was referring to the 'home screen' which I still call it 'desktop' at times since I'm so used to this term after being years of laptop/desktop computer user. Shall we move on from such debates that hardly even matter at all?

same reason why iOS changes its desktop design everytime. No matter whether its even a better design than its predecessor, a change is a change, and people want to see changes.

Actually Id recommend Java or C# for desktop applications, they are more object oriented languages than C++, while C is only useful for operating system as its procedural and lacking even the most basic object support.

Well Id recommend against using singleton database connection, but if you are using it as a learning process for programming/OOP its perfectly fine. They really are not OOP, but its still good to know how to deal with them as you may encounter programs from other coders that use statics/singleton if you work in a team. Still, keep in mind that static methods/singleton methods are poor OOP practices, use them sparsingly.

Nope I am not being overly defensive, I do in fact know what I am doing, and in fact if you read Ignace's post history with me you will know why I am talking about this. There was a time when I brough up that PHP's namespace is lacking wildcard import by using a draft user class hierachy example to illustrate how importing multiple classes can be made easier, and Ignace went on to comment on how the user class hierachy is flawed. Dont you think this is completely missing the point of dicussion?

I said it was just for illustrative purposes, if you earnestly believe this is what I will end up having in my own OO architecture you'd be serious mistaken. In my OO design Id completely separate the domain layer from application layer, the domain model will not know how to handle redirection, login and this kind of behavior. The controller will call login based on the subclass of model, but then you need to create a class hierachy for controllers first, maybe service layers too if you need further separation of concerns. Also I wont use PDO to fetch objects in the application layer either, instead I will use a data mapper. Now you see it will require significant overhead, and thus inappropriate in a single post like this to explain. Yeah I will do it if it were my own application, but here I just want to explain the concept of polymorphism, more precisely how to use polymorphism to eliminate conditionals. Nothing more nothing less, I dont wish to write 20+ classes/interfaces to scare the OP away, perhaps this forum wont allow me to post/upload all the source code of these classes anyway since they will be too long. Like I said, you can always refactor after design the first draft of your system architecture, for OP's skillset the above code should suffice, once he learns more about OOA/OOD he will move on to more advanced OOP.

Your design has some flaws in it. First of all, mysql extension is deprecated, use mysqli or PDO. Second, for a system like this Id prefer object oriented approach as you are not handling a personal home page type of website. I dont get the entire picture of what your site is supposed to do, but below is a sample code that will help(note it is not a complete design, you can do some refactoring to make it better, its used for illustrative purposes only): abstract class User{ public function __construct(UserDTO $userDTO){ $this->id = $userDTO->idnumber; $this->idNumber = $userDTO->idnumber; $this->password = $userDTO->password; // Assume you already did password hashing/salting beforehand $this->position = $userDTO->position; // Whatever additional fields } abstract public function redirect(); } class Admin extends User{ public function redirect(){ header('Location: admin.php'); } } class Teacher extends User{ public function redirect(){ header('Location: teacher.php'); } } class Student extends User{ public function redirect(){ header('Location: student.php'); } } class Cashier extends User{ public function redirect(){ header('Location: admin.php'); } } class UserFactory{ public function __construct(UserDTO $userDTO){ $this->userDTO = $userDTO; } public function createUser(){ $method = "create{$userDTO->position}"; $this->$method(); } private function createStudent(){ return new Student($this->userDTO); } private function createTeacher(){ return new Teacher($this->userDTO); } private function createAdmin(){ return new Admin($this->userDTO); } private function createCashier(){ return new Cashier($this->userDTO); } } // Assume you have a PDO object available, but not a data mapper(for a small system). $PDO = new PDO(/*.. Your DB credentials..*/); $stmt = PDO->prepare(/*.. Your SQL ..*/); $stmt->execute(); $userDTO = $pdo->fetchObject("UserDTO"); //UserDTO, a data transfer object $factory = new UserFactory($userDTO); $user = factory->createUser(); $user->redirect(); exit(); This design is better 'cause you can use polymorphism to eliminate unnecessary conditionals. The advantage is more evident once you have to write duplicate if...else statement to check user level/position in other script/class files. Also once your site grows, there is a good chance that you will have other actions beyond redirection that will require checking the user level/position conditionals. All you have to do then is to add such method for each User sub-classes. As you see, with Polymorphism, you dont need to worry about writing these conditionals over and over again, PHP will do it for you. Note the design can be further improved using a domain model - data mapper design pattern, you will learn this later once you become more familiar with PHP and OOP.

A perfect script is a script with both perfect functionality and perfect design, they are about equal importance. The functionality part is easy to understand, it is about how your script works and meets the feature-requirement of your clients while staying bug-free. This does not have much to do with OOP, you can write in OOP while your code is full of bugs/syntax errors and do not meet the requirement of your clients. This is why I said OOP is one necessary step to perfect script, but not that OOP = perfect script itself. The design part is where OOP truly fits in, a perfect design = fully object oriented design. A perfect design means that your script is easily reusable, extensible, mainteanable, unit-test friendly and professional, which is exactly the definition of a fully object oriented design. A fully object oriented design also requires more than just the use of objects, as its possible to use objects without abstraction, encapsulation and any other related OO features, which make a script truly procedural in disguise(such examples are Singleton and Transaction scripts, two infamous antipatterns). However, without using objects you cannot achieve fully object oriented design in the very first place. You can mimic OO features using procedural language constructs, they just dont work as well as using actual objects in an OO language. In a word, using objects is a necessary condition for fully object oriented design, and fully object oriented design is a necessary condition for perfect script. Applying the basic of logics, we arrive at using objects is a necessary condition for perfect script too, which then translates into 'in a perfect script everything is an object'. No one is perfect, nor can a programmer write a perfect script, but you can always approach perfection as close as you can. This is why I emphasize the use of objects in PHP projects, the fact that you cannot write perfect script does not mean you should not aim at improving your script. In fact, even a tiny step will help.

Well if today's programmers want objects, theres definitely a reason for it dont you think? After all, all large enterprise applications/softwares are object oriented, these professional developers dont choose OOP just for its name. You know, in a perfect script everything is an object. Sure you can never be perfect, but you can approach as close as you can by writing more object oriented code(not just by using objects alone, a point amateur coders usually dont grasp). Same reason why engineers are always attempting to improve a system's efficiency knowing it can never be 100% efficient.

Well the entire procedural style of connecting to MySQL database(mysql_connect() or mysqli_connect()) is outdated, instead using the object oriented syntax for MySQLi or PDO is the way of future. Use this for your development assuming you prefer MySQLi over PDO: $mysqli = new mysqli('localhost', 'my_user', 'my_password', 'my_db');

Doubt you really dont care as you replied to this thread, and twice. Anyway, why not get back to the topic and come out with a list of programming practices that aspiring OOP programmer should avoid or get rid of? Thats the purpose of the thread to begin with, I aint interested in arguing on the irrelevant matters anyway.

You have a point, programming is about a healthy balance. When it comes down to the usage of design patterns, Id agree with you since a software can be written with various OO patterns. Nonetheless, there are still some basic rules that dictate that certain techniques are always better than their alternatives(like OOP is more professional than procedural), while certain practices should always be avoided(like global variables should never be used in a serious project). Yes procedural code, along with if/switch statement aint even OOP, but the point is that your code can be improved by replacing them with good OOP techniques. For this reason, they are considered code smells and poor programming practices. You can keep playing the word game and arguing that non-OOP techniques cant be considered poor OOP practices since they aint even OOP, its your choice and I dont really care. The real point is that a program consisting of procedural code is the worst nightmare for an OO programmer/OO software, if it is not clear enough for you. Perhaps the title was being a bit misleading, it may sound better if I called it 'poor practices that OO programmers should avoid' or 'poor practices that programmers should avoid when designing OO software'. You seem always to be obsessed with the unimportant/minor points in a thread, not sure whether you aint paying attention or that you are trying to digress. Sorta reminded me of the time when I used a dummy user class hierachy example to point out that PHP's namespace is lacking wildcard import feature as classes in the same package grow in number, while you ended up criticizing how the user class hierachy is inappropriately designed. The question is, who cares? Anyway, by mentioning procedural code I was specifically referring to programs that use objects but are actually procedural in disguise, a good example is transaction script, an Anti-pattern I identified a few months ago. The truth is that some people consider it as OOP so long as they are simply using objects, which is not true as OOP requires more than just using objects. Can this be considered poor OOP practice? Oh yeah you can always insist that its not even OOP to begin with, again its not my business.

PHP allows you to create object properties/fields on the fly. You do not have to explicitly declare a property inside your class, and it can still be created and ready to use. The visibility for these dynamically created object properties will always be public, I am not sure whether its a good practice though.

Here's my list, but anyone can add up to it. Id like to see how many we can come out with. 1. Public Properties/Fields: For good object oriented programmers, every property/field defined in a class should be private or protected. The problem with public properties is that they completely break encapsulation and expose the object's basic implementation details to client coders. Moreover, public properties can be modified or erased accidentally, not appropriate for security reasons too. There's a reason why in C++ all properties are private by default. 2. Static Properties/Methods: Static properties/methods skip the fundemental object instantiation process and introduce global scope, they are not even object oriented. In Java/C#, Static is often used with Singleton(an infamous anti-pattern) and Factory design to compensate for the lack of global variable support, but does not really make the program any better. Static properties/methods are difficult to debug as well, so use Dependency Injection as an alternative. 3. Too many if/switch statements: You cannot write a program without conditional statement, which is why pure OO is difficult or impossible to achieve. However, its always a code smell if your program contains too many if or switch statement, especially the latter. In many cases, its possible to replace conditionals with polymorphism. a very good example is when you have switch statements checking for types/genres. For if statement, things may get a bit trickier, its up for the programmer to decide whether to refactor. 4. Long class/methods: Long class/method usually is a code smell, it implies that your class may be a 'God class' and that your method needs refactoring. The book PHP Pro refactoring introduces many techniques for cutting down the size of a class/method, lots of them are really useful and Id recommend it to newbies. Class and method design should both follow the single-responsibility rule, otherwise it may be a sign that a class/method needs to be broken up into parts. 5. Inheritance Addict: Inheritance is a great OO technique, trust me it is. It is one of the four fundemental OO concepts(the other three being encapsulation, polymorphism and composition), you cannot build a fully functional OO system without inheritance. However, sometimes inheritance can break encapsulation, while composition is usually better than inheritance. Use inheritance when there's a strict is-a relationship between one class and another, dont overdo it. 6. PHP Array Addict: PHP arrays are a poweful tool, unfortunately they are not object oriented. PHP offers two object oriented way of Array handling, SplFixedArray and ArrayObject. Use for the former for numeric array and the latter for associative array/hash, it may be a good practice to extend these classes to add more functionality. The fact that PHP arrays are not object means that they are not subject for lots of useful object features such as type hinting. 7. Overuse of Magic Methods: Magic methods are useful at times, the constructor itself is actually a magic method, while others like __call() and __toString() are proven to be quite helpful for a program. However, a magic method takes at least 3x more time to execute compared to a standard method, they should only be used when necessary. Sometimes the presence of magic method also indicates that the class is not well-designed in the very first place. 8. Overuse of call_user_func_array(): First of all, I doubt call_user_func_array() itself is even considered OOP at all. But anyway, its commonly used to invoke an object's method with array of parameters. The problem with this callback function is that, its slow, its slower than a snail. Using __call() together with call_user_func_array() makes your program 17x slower, while its much faster to simply use variable method name such as $object->$method($arg, $arg2...). 9. Overuse of Method chaining: Method chaining is a very interesting and convenient feature, it is inspired by smalltalk's cascade feature. Unfortunately, method chaining is not as good and powerful as smalltalk's cascade, and abusing method chaining can easily break encapsulation and introduce tight coupling(dependency) between methods. Id personally only use it for builder object(like a query builder) or setter methods. 10. Procedural code: Need not to explain much on this one, the presence of procedural code is an implification that your code is not object oriented. What to do with it? Refactor, refactor and refactor, plain and simple.

Great, glad to have you on my contact. The first motto you should keep in mind for an object oriented programmer is that 'in a perfect script everything is an object'. Its impossible to write purely object oriented code(especially on PHP due to the limitation in the language itself), but you can always make your program more object oriented with a little bit more work. More object oriented code = More professional code. Just like in energy industry you can never design an 100% efficient system, but you can always improve its efficienty beyond what has already been achieved. Does this analogy make sense?

Actually __get() can be used to simulate a 'readonly' property in C#, although it wont be as powerful. One drawback of magic methods is that they are extraordinarily slow compared to other methods, you only use them unless you have a very good reason. For me, I've only found __call() and __toString() to be practically useful, but of course it may depend on your own application. I see that you like to ask OOP related questions, you can add me to your contact if you want to learn OOP and wish to know more about it. I'd always love to help out with OO enthusiasts.

Also a friendly tip, try to avoid using __autoload($class) unless you are developing a really small application, instead look for spl_autoload_register($loader).

Maybe, but it does not contradict with the point that superglobals are bad and should be erased. Just bundle HTTP extension with PHP core already, it can repleace most of the superglobals.

Well actually I hope all superglobals get erased in the next version, and instead make them collection type objects. Globals are one of the worst practice not only with OOP, but also in all programming paradigms, its unusual how PHP has this many superglobals. As far as I know, PHP has a HTTP extension, which has classes like HTTPRequest and HTTPResponse, just bundle this extension to PHP's core and bingo, you get a very good way of using Request and Response objects/classes rather than superglobals that are detrimental to quality programming.

Whats wrong with that statement? How can transaction script be a good OOP practice when its not even OOP in the very first place?

Well transaction script uses objects but is truly procedural code in disguise so its considered a poor OOP practice.