[SOLVED] Coding Style and OOP

[Liquid Fire]

You've over complicated it again

 

MVC is a Design Pattern, "Concept" over glorifies it. It literally is Model, View and Controller separate from each other - that is it. The one file separation still satisfies MVC. The moment you start thinking about anything else other than this separation, you have overcomplicated it, and are in actual fact thinking of generic application design, or everyday OO practices, or whatever.

 

I am not really over complicating things, I just look at the bigger picture and not short term.  in the short term it might be easier to put everything into one file but when the site or application grow, making thing more modular is easier to maintain.

[Jenk]

That's not what I meant. You are overcomplicating the MVC Design Pattern. You are fully justified to have foresight for easy maintenance etc. but that is generic application design, and NOT MVC.

[Liquid Fire]

ok i think we agree even tho you say i am making things overcomplicated.  MVC is separating data/logic/view into 3 parts.  Putting those 3 parts into separate classes is the best way to make things easier to maintain IMO but not needed for MVC.

[Jenk]

Exactly.

[wrave]

roopurt18: You have successfully brought me back to reality. Somewhere along the way yesterday I got lost and was thinking exactly what you wrote. My application is fairly simple. I was thinking it so simple to cut-and-paste the code when there are only a few places in the system where it is used and I did exactly that.

 

I think originally I was more interested in coding style than reuseability but of the two, reuseability is the more important. This is especailly true of large applications. Of course, style will make it easier to find the code snippet I want if I have to go in and make query changes in just a few files. But as you point out, this really becomes a major pain if this were a very large and complex system. I'm going back to look at the cakePHP site.

 

Now that my head is straightened out a bit I see where cake can simplify creating multiple applications on the same DB. Where my query might now be used to provide a data display (view) for users, I might want to build a DB management application that would require the same display. And if I had to change the table structure, I'd have to make changes to the code for both applications. That could be very messy.

 

I can't help but make the comment that I began using PHP and MySQL about a year and a half ago and it has been the most enjoyable experience in my computing career. I've never built an application so quickly nor had it turn out so well. But more importantly I see that learning can still be enjoyable and it is in a large part due to the helpfullness of the contributors to these forums.

 

roopurt18 thanks again for your help. Your explanations are so clear that you should be teaching.  And everyone else that has commented has helped me too. You folks are great!

 

I think I can mark this thread solved.

[roopurt18]

NP.

 

Taking everything one step further, when writing OOP code you should be thinking in terms of interfaces.  I'm not going to bother with a long, detailed explanation, you seem resourceful enough to find some of this on your own, but I'll try and get you thinking.

 

Let's say you develop an object that acts as a session handler.  You should be thinking of all the different ways in which sessions are used and provide the proper interface for your session object.  What is an interface?  The interface for the object is the functions and methods that expose it's functionality.  There is a good chance your object will have properties (member variables), but any code that uses the object should not access those properties directly; instead it should access them via methods.

 

Short example:

  class A {
    var $a;
  
    function set_a($val){
      $this->a = $val;
    }

    function get_a($val){
      return $this->a;
    }
  }

 

  $a = &new A;
  // DO NOT DO THIS
  $a->a = 'Hello!';
  echo $a->a;

  // This is better
  $a->set_a('Hello');
  echo $a->get_a();

 

Here's why the first example is bad.  Say you develop that object.  Again, you use it all over the place in your code.  You later discover that the internals of the object should be redesigned, that internal variable 'a' should be an Array.  Or you want to restrict it so that only numeric values can be set there.  Well, if you were accessing that variable directly, you have a lot of code to change.

 

If you were using the set* and get* methods, then you have very little code to change.

 

When designing an interface, it boils down to this.  As long as all client code (i.e. code that uses the object) respects and uses the interface, you can change the internal workings of your object all you want and all of your client code will continue to function.

 

Hmmm.  That wasn't as short as I intended. 

[wrave]

I see where it would be tempting to access a property directly, a very small reduction in the amount of code to be written. $a->a = 'Hello!'; versus $a->set_a('Hello'); plus what if you forget the exact name of the methods, then you've got to get into the file and look them up. But I do see where you would be invalidating the reusability and I'm grateful for the heads up.

 

By interface, I am guessing you are referring to any method that accesses the properties found in the class.

 

I spent the day at work today (I was off yesterday) where they just moved my desk and they still haven't connected me back to the network. But I had access to the web so I spent the day looking for information and tutorials on OOP. I found a couple of good ones, one here on  PHPFreaks, that I will be studying in depth.

 

I have no doubt that I will have a lot more questions as time goes along.

[roopurt18]

By interface, I am guessing you are referring to any method that accesses the properties found in the class.

Essentially, yes this is what I meant.

 

I have a bit more time today than I did yesterday, so this may get long, but here we go.

 

In OOP you first must declare your object; you do this by writing the source code.  Think of this like creating a blue print for a house.

  // Declares an object, shape
  // (not a very useful object though)
  class Shape {
  }

There.  I have just declared my object 'Shape.'  However, I do not yet have a shape anymore than creating a blue print means I have a house.

 

After you declare your object, you must instantiate (create an instance of) it.  This is like building the house from the blue print.

  // elsewhere in the code, we instantiate
  // this is out-dated php4 syntax, php5 drops the & operator
  $obj = &new Shape;

After that line of code, $obj is a variable that refers to an instance of the object.

 

Since our declaration doesn't have any methods or properties, our instantiated object isn't of much use.  For example, our declaration (the blueprint) doesn't include a Draw() method, so it's impossible to say: $obj->Draw();.

 

Just to be clear:

method : a fancy name for a function, just like any other program function you can write, that happens to belong to a class

property : a fancy name for a variable, just like any other, that happens to belong to a class

 

Now for a quick aside:

You are familiar with the terms client and server, although up until now you typically think of computers over remote connections.  You can essentially think of an instantiated object as a server and the code that uses it the client.

 

So to answer your question, the interface is the set of methods and properties the object (server) exposes to the code that uses it (client).  Typically, the interface consists entirely of methods.  Methods do not necessarily have to access any of the properties, although they usually do.  Now, it is possible that properties of the object will be part of the interface, as in this example:

  $obj = &new A;
  $obj->a = 'Hello';
  // as opposed to: $obj->set_a('Hello');

You have to be very, very careful when doing this.  You have to almost guarantee that property will never change in name, type, restrictions, constraints, etc. for all of eternity.  This does happen in practice; a good example are the nextSibling and previousSibling properties of DOM nodes in Javascript.

 

You will notice in PHP5 and other OOP languages there are reserved words: public, protected, and private.  When you start using those keywords they define the level of visibility attached to a particular method or property.

  class A{
    private $a;

    public set_a($val){
      $this->a = $val;
    }

    public get_a($val){
      return $this->a;
    }

  }

  // elsewhere in another file
  $obj = new A;  // PHP5 now so I dropped the &
  $obj->set_a('Hello'); // works as expected
  $obj->a = 'Hello'; // a is declared private, can't be seen outside the class

Above, because the property $a is declared private, that last line of code won't work.  Not only that, the PHP interpretor is able to throw an error (since the interpretor read the definition and saw the private keyword).  When using public, protected, and private in a class declaration you guarantee that the clients (code that uses it) adheres to the interface you intended.

 

PHP4 has no such public, protected, and private reserved words.  Therefore any method of a class is public, likewise with any variable.  Due to this, even though PHP4 supports classes and objects, I wouldn't call it object oriented since it doesn't give the object designer the ability to enforce their interface.

 

Think about what would happen if a PHP4 application constantly used what was meant to be a private method of a class.  The server is then upgraded to PHP5.  Now that the server runs PHP5, the private keyword is added to the function in the class declaration.  Now all those calls that worked in PHP4 break.  Oops.

[wrave]

As "Carsoni the Great" I am about to make a prediction. Someday in the future, roopurt18 will be known for producing the worlds greatest OOP Tutorial!!! 

[scottybwoy]

Hat's off, I agree.  Do it roopurt18.