Protected vs Private

[BerislavLopac]

That's because they're testing behavior and not implementation (which they should)

I can't imagine why they should -- what defines an object is its behavior, not its implementation.

Who cares if a multiply($a, $b) method is implemented as return $a * $b or as

for ($i = 1; $i < $a; $i++) { $b += $a }; return $b; 

It's only important to get the correct result out.

[taliesinnz]

Just a thought; making a varible public can screw things up, but it's also kind of annoying to write getters for every variable.

You only have to write setters on varibles which needs to be checked ( like to insure you are passing in corry object type to the object.

code along the lines of

class Obj
{
      protected $example;

      function setExample( $value)
      {
            $this->example = $value;
      }
} 

is bad design in my opion.

class Obj
{
      public $example;
} 

is more suited for the purpose.

I think setter should be used like

class Obj
{
      private $exampleDB;

      function setExampleDB( $valueDB)
      {
            if( ! $valueDB instanceof ClassDB )
                   return 'Invalid DB';
 
            $this->example = $valueDB;
      }
} 

[Jasper Bekkers]

I can't imagine why they should -- what defines an object is its behavior, not its implementation.

Who cares if a multiply($a, $b) method is implemented as return $a * $b or as

for ($i = 1; $i < $a; $i++) { $b += $a }; return $b; 

It's only important to get the correct result out.

Yes, that should have said 'as they should', please forgive. However; there are cases where implementation does matter (the case where performance matters, for example). However, that's not what Unit Tests are for.

[Athox]

I think setter should be used like

class Obj
{
      private $exampleDB;

      function setExampleDB( $valueDB)
      {
            if( ! $valueDB instanceof ClassDB )
                   return 'Invalid DB';
 
            $this->example = $valueDB;
      }
} 

Setter should optimally return an exception on error, since it's not a return function per se.

[Jasper Bekkers]

I'm sure that they are going to close the browser, open up an editor and create the biggest God object that we've ever seen. And God objects are my worst nightmare.

Thinking is the only way to create a solid design, if you stop to think and stop being critical the problems you have are beyond creating a God class.

That's a very type-centric way of viewing things. In my view, there are no interfaces, polymorphism happens through objects implementing the right methods, and inheritance is used to specialize behavior.

Specialization of behavior though inheritance is an overvalued concept that requires thorough knowledge of the Liskov substitution principle to be applied correct; knowledge that can often be avoided by combining objects through composition. The biggest problem with your approach being that you more often want to replace components entirely.

One example of this is that recently I had to change the input handling of a simple game from standard windows API to DirectInput because someone wanted to be able to use his new gamepad and figured it didn't work on the product. Thankfully this went smoothly because there was a (thin, but nice) abstraction in the way input was handled. The interface was this:

enum action_e{
    action_jump,
    action_shoot,
    // et cetera
};
 
// Abstract base class, this is the best approximation of an interface
class input_actions{
public:
    virtual void is(action_e a_Action) = 0;
    static input_actions *create();
};
 
// use case:
if(m_CurrentAction->is(action_jump)){
    // handle jumping
}
 
// Solution to the problem above is to replace 
// the input_actions_win32 class with a new 
// input_action_directinput class and modify
// input_actions::create() to return an instance
// of our new object.

That's just a tedious job if you don't have a formal specification. Now, the formal specification can be in a LaTeX document or it can be an actual interface in your code (input_actions in the above case); that doesn't matter, but I prefer the latter because it's always up to date and forces me not to break anything.

The only way I really use inheritance is when I have to hack something up that should be implemented in a relatively short time and would otherwise break a heap of stuff.

[jack57tin]

If you want to have something unchanged when your class is used use private, in all the other cases use protected or public.

[ilyalyu]

I have read and heard from a few people that say to never use the private access modifier, and instead always use protected. They say this is because you never know who will be extending your class, etc.

What do you guys think?

If you declaire a member function/variable as private, you can later edit it not caring that some derived class relies on this function/variable. If you declaire it as protected, you will need to check that your changes do not damage derived classes. If you declare it as public, you will need to check the whole program after each change. In short, the more private the less troubles.

[BasKar]

Dose it really matters if it is private or protected?
and i think you guys are getting off the topic .

[aedrin]

Since this is a topic discussing Private vs. Protected, I don't see how it is off topic.

And yes, it matters. The same reason that Design Patterns matter, that Object Oriented Programming matters. It's to create an easy to maintain system that can be extended when required, without rewriting the project.

[Jasper Bekkers]

Dose it really matters if it is private or protected?
and i think you guys are getting off the topic .

It's in a developers nature to have lengthy discussions about seemingly irrelevant subjects for there are always things to take from those discussions.