RiscOS wrote:1: Must I use getters and setters? What if a class has 20+ instance variables? I'd then have to create 40 extra instance methods to handle getting and setting.
Well, as Hockey already mentioned: if you have > 20 attributes in a class, it probably does to much and it is time to refactor. That said, I tend to think that accessors and mutators (get/set-ters) are used too frequently in the php surroundings. An object represents both data
and behaviour and can be talked to through a public interface. If it has no behaviour, then it's merely a
Data Transfer Object, which in PHP can be easily reduced to an array or an stdObject.
Usually, an object that incorperates no behaviour indicates misplaced responsibility, because it usually indicates a clear violation of the important OO principle
"tell don't ask". One of the key differences between procedural programming and object oriented programming is that in procedural programming you would ask for data and then go on using aforementioned data for example in a procedure. In object oriented programming you should be asking the object that has the data "do this for me, ok?".
Now, I'm not saying that I think all getters and setters are useless or undesirable: they certainly do have their uses. One of the main reasons that people use getters and setters is to comply with standards that are imposed by using a third party library, such as an ORM. Since an ORM has to save an objects attributes to the database, it'll have to know how to get them.
If you ask me, the preffered way to decide whether or not you should incorporate a setter or getter for a certain attribute is experience. That is to say: don't write it initially and only write it if time proves that you can't live without it.
RiscOS wrote:2: Function/method arguments. Should I check before doing anything in the method that the args are the correct type and if they are not return?
Well, you can obviously only work with the correct values, no? Some incoming values are easily transformed or typecasted to it's correct datatype, but sometimes that is just not possible. On such occasions, you'll have to let the client code know what just happened and why you can not continue executing the behaviour.
A likely scenario is that you get a wrong datatype because you did something wrong somewhere. Usually the interface between objects is well-defined (or it should be) and the client code will know what type the object is. In that exact situation
assertions might be helpful. The assert function of PHP is - in my opinion - a hidden gem. It really is a very easy development tool. So: if you're expecting something to be an integer, you could just assert( is_int( $id ) ). Just remember that this is a development aid, not a way to validate user input.
RiscOS wrote:3: Should functions always return something? Even if it something like true, just to indicate everything went ok? Is it bad programming not to?
Hmm.. I dare not say that it is bad programming not to return something from a method, but in practice I always do return. Remember:
return values and exceptions are the only way to communicate with client code. In my humble opinion public methods should always return a value, to indicate whether or not the requested behaviour was succesfully executed.
RiscOS wrote:4: I am developing a web app. I have the main class as a Singleton so that only one is ever made. I have an class property, an array (with multiple sub arrays) for storing the info for the application. I read that for info like this you should make a new object with the Registry/Register pattern and pass this obkect instead to your other classes.
Stop it. Seriously. The singleton pattern is getting abused by many in php today, while the implementation can not be justified and the benefits don't outweigh the disadvantages. If you want just one object of that type, just instantiate it once. If you want further clarification on that statement, don't hasitate to ask.
Also, your mention of a "main class" is making my neckhares stand up straight. Objects should have a clearly defined responsibility: a "User" should be able to login. What is a "Main" supposed to do?
EDIT: Sorry for the lengthy reply, I want to be "Fastest Advancing Newcomer 2009"
