SitePoint Sponsor |
|
User Tag List
Results 76 to 85 of 85
Thread: Protected vs Private
-
Jan 30, 2008, 15:24 #76
- Join Date
- Sep 2004
- Location
- Zagreb, Croatia
- Posts
- 830
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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
PHP Code:for ($i = 1; $i < $a; $i++) { $b += $a }; return $b;
-
Jan 30, 2008, 17:48 #77
- Join Date
- Aug 2007
- Posts
- 365
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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
PHP Code:class Obj
{
protected $example;
function setExample( $value)
{
$this->example = $value;
}
}
PHP Code:class Obj
{
public $example;
}
I think setter should be used like
PHP Code:class Obj
{
private $exampleDB;
function setExampleDB( $valueDB)
{
if( ! $valueDB instanceof ClassDB )
return 'Invalid DB';
$this->example = $valueDB;
}
}
-
Jan 30, 2008, 17:56 #78
- Join Date
- May 2007
- Location
- The Netherlands
- Posts
- 282
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Design patterns: trying to do Smalltalk in Java.
I blog too, you know.
-
Jan 30, 2008, 18:56 #79
- Join Date
- Oct 2006
- Posts
- 85
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
-
Jan 30, 2008, 19:15 #80
- Join Date
- May 2007
- Location
- The Netherlands
- Posts
- 282
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
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:
Code C++: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.Design patterns: trying to do Smalltalk in Java.
I blog too, you know.
-
Jan 31, 2008, 02:48 #81
- Join Date
- Jan 2008
- Posts
- 3
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
If you want to have something unchanged when your class is used use private, in all the other cases use protected or public.
-
Jan 31, 2008, 10:47 #82
- Join Date
- Nov 2004
- Location
- St Petersburg, Russia
- Posts
- 295
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
Feb 7, 2008, 11:45 #83
Dose it really matters if it is private or protected?
and i think you guys are getting off the topic.
-
Feb 7, 2008, 12:10 #84
- Join Date
- Oct 2006
- Posts
- 37
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
Feb 7, 2008, 12:22 #85
- Join Date
- May 2007
- Location
- The Netherlands
- Posts
- 282
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Design patterns: trying to do Smalltalk in Java.
I blog too, you know.
Bookmarks