Oop / Modular help

[ro8in]

Hey everyone,

 

My first post here 

 

Im always wondering how do you guys keep stuff organized. Let me explain for example I have a class BOX

Class Box is used on page1.php and page2.php and page3.php. But now page2.php requires some new functionality which requires me to update a function inside class BOX.. But when I do this I might break page 1 and 3 because I forgot they use that function also. What is the best way to manage this? Should I write a new class which extends BOX for page2 or ????

[ro8in]

Maybe add some extra example

 

suppose class BOX has a function

 

getboxcontents()

 

But page2 requires not to get just the contents but the contents for a particular user. I need to change the function to

 

getboxcontents($user)

 

Which will cause the function to error on page1 and page2 as they are still calling the function without a var..

 

Basically I need to know how to handle such changes in huge projects.

[Andy-H]

Extend the class and overwrite the behaviour of the particular method.

 

class box
{
   protected $width;
   protected $height;

      public function __construct($width, $height)
      {
         $this->width  = (int)$width;
         $this->height = (int)$height;
      }

      public function getArea()
      {
         return $this->width * $this->height;
      }
}

class cube extends box
{
   protected $length;

      public function __construct($width, $height, $length)
      {
         parent::__construct($width, $height);
         $this->length = (int)$length;
      }

      private function getArea(){}

      public function getVolume()
      {
         return $this->width * $this->height * $this->length;
      }
}

[KevinM1]

This is one of those tricky situations that tends to confuse OOP newbies.  The question is really how often will the part that differs (page 2, in your situation) crop up elsewhere in your project?  If it's a one-time thing, I don't see anything 'wrong' with simply using a default parameter:

 

public function getBoxContents($user = null)
{
   if($user) // if user exists, this is the page 2 functionality
   {
      // do page 2 stuff and return
   }
   else
   {
      // do normal processing and return
   }
}

 

Keep in mind that this is really for those one-time exceptions that you may not feel warrant an entirely new class of objects to address.  Otherwise, create a child object like Andy-H showed.

 

Note: personally, I'd still more than likely create a new class anyway.  I don't like this kind of branching logic in my data objects.  Also note that this kind of debate (small bit of branching logic vs. a one-time-use specialty object) still rages today.

[roopurt18]

50% of the time this crops up you're going to realize you made the wrong choice six months later.

[ro8in]

Thanks for all the great answers.

 

My problem with this, specially in large projects is. Lets say ok I create an inheriting class for the changes on page2. But offcourse the customer now wants a change on page3 different for the one on page2. So I create another inheriting class.. Then suddenly 1 year later the customer asks me for the same change on page1 as on page2, but because i was so busy with page3 before that I forgot about the class i made for page2 and I start making another inheriting class for the changes on page1.

 

Like this after a while I end up with loads of classes even unnesecary ones.

 

How do you guys keep this all in order?

[Andy-H]

I'm an OOP newb myself, hovever, from the argument you made I'd create a child class too, as the first class will be used more; I would rather optimise the speed and process less code. The child class can be included from a seperate file, meaning the performance fall is only in effect in the case(s) where the child class is included. Although it means writing more code, I believe it's more modular.

 

Besides, I'm a speed freak - which is why I'm contempt writing pocedural code. xD

[Andy-H]

If the customer specifically asks for the same change to be made on page one as you DID on page 2, then you should know that the desired behaviour has already been created and should only need look for the inherited class (or include it - if you use autoload) and plug the class into page1.

 

I like to take an hour or two to fimiliarise myself with code I haven't seen for a while or have never seen to ensure I know how the code works and conform to it's standards. (tab indents, brace alignment, naming conventions etc.)

[ro8in]

Hehehe well the customer offcourse does not exactly say I want the same change on page 1 as on page 2. He just says now I want on page 1 this and this, which by coincidence are the same changes as i did long ago on page 2 but neither me or the customer realise it because its such a huge project.

 

But I will try to create child classes from now on for situations like this. Maybe it will not get as worse as I fear.

I now mostly do  Nightslyr fix butI sometimes end up with functions with over 5 of these vars.

[ignace]

Im always wondering how do you guys keep stuff organized.

 

We start with planning, creating a design that may work and try to make best guesses as what likely will change and in what way and try to accommodate our designs for those changes. For all this to work well you need a solid knowledge of OO principles and patterns although the latter is not really required but a welcome tool.

 

 

How do you guys keep this all in order?

 

Documentation. A term like Box is very vague and it's difficult to suggest designs without knowing the context. So either Andy-H's or Nightslyr's advice will do.