SitePoint Sponsor

User Tag List

Page 4 of 4 FirstFirst 1234
Results 76 to 85 of 85
  1. #76
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Jasper Bekkers View Post
    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
    PHP Code:
    for ($i 1$i $a$i++) { $b += $a }; return $b
    It's only important to get the correct result out.

  2. #77
    SitePoint Addict
    Join Date
    Aug 2007
    Posts
    365
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by wysiwyg View Post
    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
    PHP Code:
    class Obj
    {
          protected 
    $example;

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

    is bad design in my opion.
    PHP Code:
    class Obj
    {
          public 
    $example;

    is more suited for the purpose.

    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;
          }


  3. #78
    SitePoint Addict Jasper Bekkers's Avatar
    Join Date
    May 2007
    Location
    The Netherlands
    Posts
    282
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac View Post
    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
    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.
    Design patterns: trying to do Smalltalk in Java.
    I blog too, you know.

  4. #79
    SitePoint Enthusiast
    Join Date
    Oct 2006
    Posts
    85
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by taliesinnz View Post
    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;
          }

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

  5. #80
    SitePoint Addict Jasper Bekkers's Avatar
    Join Date
    May 2007
    Location
    The Netherlands
    Posts
    282
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by phpimpact View Post
    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.

    Quote Originally Posted by 33degrees View Post
    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:

    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.

  6. #81
    SitePoint Member
    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.

  7. #82
    SitePoint Addict
    Join Date
    Nov 2004
    Location
    St Petersburg, Russia
    Posts
    295
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by whydna View Post
    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.

  8. #83
    SitePoint Member BasKar's Avatar
    Join Date
    Feb 2008
    Location
    Earth
    Posts
    2
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Dose it really matters if it is private or protected?
    and i think you guys are getting off the topic .

  9. #84
    SitePoint Enthusiast
    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.

  10. #85
    SitePoint Addict Jasper Bekkers's Avatar
    Join Date
    May 2007
    Location
    The Netherlands
    Posts
    282
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BasKar View Post
    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.
    Design patterns: trying to do Smalltalk in Java.
    I blog too, you know.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •