[RESOLVED] Order of elements inside a class

[Bjom]

Hi,

how do you go about ordering elements inside a class (apart from the obvious "variables at the top functions below")

Alphabetical, by function, any other logic?

E.g. when type/name/value would be the the order of importance of 3 parameters...

Would you prefer scheme1 or scheme2?

Obviously with only 3 parameters it doesn't matter but when it is becoming more and also in cases where a parameter is added at a later date, it could matter.

Anything from your experience giving clues about pros and cons?

Scheme1, by importance

class MyClass
{
    private $_type = '';
    private $_name ='';
    private $_value ='';

public function setType()
{        
}

public function setName()
{   
}

public function setValue()
{   
}
}

Scheme2, alphabetical:

class MyClass
{
    private $_name ='';
    private $_type = '';
    private $_value ='';

public function setName()
{   
}

public function setType()
{        
}

public function setValue()
{   
}
}

[NogDog]

When I actually make myself sort everything, I like to do

1. variables

   1. public (alphabetically by name)

   2. private (alpha. by name)

2. methods

   1. constructor

   2. public (alpha. by name)

   3. private (alpha. by name)

[Bjom]

Thanks,

sounds good. 🙂

Bjom

[Bjom]

just thought of a follow up question.

what about accessor functions with the set/get prefix.

Could be a good idea to sort them strictly for the element name contained in them, so that set/get don't get separated like so:

class MyClass
 private $_bar
 private $_foo

 public function getBar()
 public function setBar()

 public function getFoo()
 public function setFoo()

instead of

class MyClass
 private $_bar
 private $_foo

 public function getBar()
 public function getFoo() 

 public function setBar()
 public function setFoo()

Bjom

[NogDog]

I tend not to think that hard about it. 😉

[laserlight]

Bjom wrote:

(apart from the obvious "variables at the top functions below")

Actually, that is not as self-evident as you think. One way to organise the members is to place them such that the members that form the interface of the class comes before those that are purely for implementation, with the idea that a user of the class would be interested in its interface (notice that this is partially reflected in NogDog's order as well). Since member variables are usually just part of the implementation, they would then be placed towards the end.

Bjom wrote:

Could be a good idea to sort them strictly for the element name contained in them, so that set/get don't get separated like so:

That is what I normally do, mainly because I happen to want to implement them at around the same time.

[Weedpacket]

A refinement of the ordering described by laserlight places all public members first, followed by protected, followed by private. The idea being that most people only need to know the first group; the second group is only relevant to people extending the class, and no-one except whoever is responsible for the class itself needs to know about the last group.

Bjom wrote:

what about accessor functions with the set/get prefix.

What about using get and set instead 🙂?

[Bjom]

set/get....well, whatabout it? It's much better 😛

Thanks for pointing me there, I wasn't aware of how they work exactly and had got a wrong impression. All changed in my code now.

As for the ordering by public - protected - private. Makes sense, but somehow I feel reluctant to have variable declarations in many places instead of all of them at the top, I'll think about it, but for the moment....hmmm.

Within the variable/method blocks that's the best way to organize, I can see that.

@'s "I tend not to think that hard about it": I tended not think about it at all until I started UMLing my little project here and realized that I had created a neat mess....

Bjom

[Bjom]

Actually set/get had to go.

I think they are evil.

You lose all links to your public section -> no more pretty intellisense in the IDE.

Which has the following drawbacks:

• Anyone using the class needs to have the properties memorized or look them up in the manual all the time.

• It means back to manually sreening your program for typos.

• It's ebil 😉

Anyway: interesting detour.

regards

Bjom