Intercepting method progression based on condition checked by parent class

Question

This is a very basic architectural question and it is thus very hypothetical.

Imagine this simple setup:

I have a class representing a web object, with only one method that renders the object. However, this class extends a parent class which requires certain conditions to be met, so that the method is actually executed (so that the object is being rendered).

Example

class webObject__adminBase {

    protected function shouldRender(){
        return access::isAdmin();
    }

}

class webObject__adminPanel extends webObject__adminBase {

    public function invoke(){

        if(!parent::shouldRender())
            return;

        // if still here, render the object 

    }        

}

$panel = new webObject__adminPanel();
$panel->invoke();

The code above serves both: an example plus a practical explanatory approach to the problem.

The issue is: i would like to get around this problem without actually having to call a method in my parent class in the child's rendering method.

I would like to achieve a class design that assures that all i need to do is to extend the parent class webObject__adminBase. Any calls to any methods in my child class should be checked against certain conditions (as in this example systemAccess::isAdmin()) and only render if these conditions are met.

I hope my description is clear.

Since someone actually requested to close this question as "too broad", i decided to rephrase my actual question with a more direct reference to the question title:

Is there a way to intercept the progression (or even execution) of a child's method based on a condition checked for by its parent class (without calling a method on that parent class) ?

There are syntax errors, crazy naming convention and non allowed access to protected methods. If it is an example it is a poor one tbh — PeeHaa, Feb 15 '14 at 14:26
Thank You for pointing this out. Should have taken more care typing it down. However, i don't see naming convention issues. Please elaborate so that i can improve. — SquareCat, Feb 15 '14 at 14:28
Your class names for one. By most conventions class names are upper camel case. And what are those double underscores in there. Also it looks like you are trying to abuse the underscore to namespace classes instead of using actual namespaces. — PeeHaa, Feb 15 '14 at 14:29
Obviously. Give some constructive criticism. What is bad about the class names? Why is it a problem? What can go wrong using that naming convention? — SquareCat, Feb 15 '14 at 14:30
Also `return access::isAdmin();` is magic. How can I tell it has some `access` class as dependency by just looking at the signature. — PeeHaa, Feb 15 '14 at 14:32
Neither is it clear to me what `invoke()` is going to do by looking at the name of the method — PeeHaa, Feb 15 '14 at 14:33
As for `isAdmin()`: The idea was to provide a hypothetical call to a hypothetical static class method which checks if the user identifies as an administrator. I think that should be rather obvious. `invoke()`: The comment should make it clear that invoke would just render the object. But this is not of any importance. The question evolves around a different issue. — SquareCat, Feb 15 '14 at 14:33
Hypothetical static calls will result in hypothetical balls of mud. But if that is the point you are trying to make by all means continue :-) However considering this is tagged OOP I doubt you are aiming for balls of mud. — PeeHaa, Feb 15 '14 at 14:35
Would you have preferred pseudo-code? With all due respect: what's the point picking apart the nature of this example? If it is not clear what i am actually asking, *THEN* we can get into necessary structural improvements. Otherwise, please either provide a solution or move on. Whether or not you like or approve of my example or class naming conventions is not of any importance. — SquareCat, Feb 15 '14 at 14:37
... playschool-style. Anyone with some constructive input, feel free to provide that. — SquareCat, Feb 15 '14 at 14:40

SamV · Answer 1 · 2014-02-15T15:56:34.243

Here is one method of doing it, albeit quite simple. I'm sure there are better methods but this one tries to keep to your original methodology.

https://ideone.com/D5hA3H

Render Class

abstract class Render
{

    abstract public function main();

    public function __construct()
    {

    }

    final public function render()
    {
        if (!$this->canRender()) return '';

        return $this->main();
    }

    final public function canRender()
    {
        // Logic here
        return true;
    }
}

Admin Panel Class

class AdminPanel extends Render
{
    public function main()
    {
        return "Admin Panel";
    }
}

Execution

$panel = new AdminPanel();

echo $panel->render();

PeeHaa is right about the naming conventions, it is in the best interest to try and follow a popular coding style which allows you yourself to read code easier and vice versa. You might want to take a look at the PHP-FIG PSR one and two standards which helps in creating consistent code.

PHP The Right Way is also a great website that will help you out the most, it provides information about dependency injection and coding practices amongst other things.

That looks rather promising. Also, thank you for clarification of naming convention issues and for providing proper links to learn more about these things. +1 — SquareCat, Feb 15 '14 at 15:50

Intercepting method progression based on condition checked by parent class

1 Answers1