Involved OOP Applications

[Michdd]

I've been using OOP for a long time, and I feel like I have a decent grasp on it, but when it comes to designing certain applications in OOP I'm unable to determine the correct route I should take. Building a PHP application that utilizes MVC is easy for me.

 

I have a base class, the controller class extends the base class and then I have classes that extend the controller class to represent each individual page. In this way I get all the functionality of the base class. I want to be able to get this same kind of functionality in other programs (not web based, nor PHP, but that doesn't really matter).

 

In my MVC applications an instance of a class extending the controller class is created when a page is accessed and that in turn gives me the functionality of all the other classes through hierarchy. I can't seem to figure out how I would do this in another type of application (or even if I should). At the moment I end up creating a base class that will hold other objects and I pass a reference of that base class to other objects held by that base object so I can access anything anywhere through that base object. However, I feel this isn't the right way to be using OOP.

 

I've been doing a lot of searching to find examples of entire programs written in OOP that are involved, but I can't seem to find much. Everything I find is extremely basic applications that while do a good job in teaching you what OOP is about, they don't really show you real-world applications.

 

Any suggestions or links would be greatly appreciated.

[ignace]

Being able to access everything anywhere in your application will cause a serious amount of overhead not to mention the inflexibility of the application. I doubt you truly grasped the meaning of MVC as you mention a base class that has access to everything anywhere (so I assume it can also access your db)

 

When you develop an application you must always adhere to laws (Law of Demeter, Separation of Concerns, ..) These laws will help you to write high-cohesive, loose-coupled, flexible software. These principles are also present in the MVC pattern.

 

When using the MVC we apply: "Skinny Controller, Fat Model" to give you an idea of what we mean by that I'll give you an example:

 

class UserController extends ActionController {
    public function registerAction() {
        $user = new User();//value-object (pattern)
        $user->username = 'username';
        $user->email = 'my-email';
        
        $model = new UserTable();//table data gateway (pattern)
        $model->save($user);
    }
}

 

Both $model and $user are models, they get that name as they are part of the domain-model (the models are the heart of all business-logic as they adhere to business-rules (:a user must validate his e-mail address prior to login)

 

Altough the model may use a database to retrieve/store this information it generally is kept dumb (which means it uses an object with a pre-defined interface but doesn't know anything about it's implementation nor should it care) so that the model may be using a db, a flat-file, or a service.

[ignace]

I forgot to mention that you don't need an OOP design for most websites you'll develop as they generally apply almost no business-rules. You get real benefits from OOP design when you develop software for larger to enterprise companies (in this case you'll be part of a team)

[Michdd]

Maybe I explained it in a bad fashion. I meant something like:

 

class Base
{
    /*
        Might have some methods to load different classes, packages, etc..
    */
}

class Controller extends Base
{
    public function __construct()
    {
        parent::__construct();
    }
    /*
        ...
    */
}

class PageName extends Controller
{
    public function __construct()
    {
        parent::__construct();
    }
    /*
        ...
    */
}

 

So in this simple MVC pattern there's only 1 instance of the lower level "PageName" class that needs to be invoked, but in a more involved (non-MVC, nor web-based) application there's not such a clear way to do this. It's pretty hard to explain what I mean, maybe I just need to do more research into design patterns.

[ignace]

No you explained it quite well apparently you didn't understand what I told you:

 

class Base {
    /*
        Might have some methods to load different classes, packages, etc..
    */
}

 

Your description of the Base class clearly shows a violation to the SoC (Separation of Concerns) as your controller may not and should not load classes instead should be done through a specialized Loader class or AbstractFactory.

 

The controller single responsibility is to match a model and a view for a given request like my registration example.