5

I have two abstract classes in an inheritance chain, within what will eventually be a generic library:

abstract class Foo {
    public function baz() {
        echo 'Foo::baz()';
    }

    // other methods here
}

abstract class Bar extends Foo {
    public function baz() {
        echo 'Bar::baz()';
    }
}

These two classes are meant to be extended by developers, and my problem is that I'd like to make it so that neither implementation of the baz() method can be overridden (as they contain strict RFC-compliant code). Making Bar::baz() final is no problem; however, if I make Foo::baz() final, then Bar itself obviously can't override it either.

PHP 5.4's traits would likely offer a practical solution, but I can't drop support for PHP < 5.4 over this. My last resort is to just leave it as-is and use documentation to warn developers not to override this method, but I'd like to find something more concrete, if possible.

Is there any other design I can use to enforce that both methods shouldn't be overridden, while simultaneously keeping the code DRY (e.g. not removing the inheritance and duplicating all the code)?

Improve this question
4
  • It seems that if Bar needs to override baz, then Foo::baz doesn't really contain "strict RFC-compliant code." And if there's one class that needs to override it to make it really compliant, how do you know that nobody else will have yet another class that needs to override it to make it really compliant for something else? Commented Aug 16, 2012 at 17:52
  • I do not understand you problem. You either want to be able to override it or you want to prevent that. But you have to make a decision. So may I ask what you want? If you want two different things, you most likely do not have the same type, so you should not let the classes extend from each other. Maybe you just want to have two classes that share the same interface or something like that? Commented Aug 16, 2012 at 17:53
  • @hakra: The two classes share implementations for all other methods. Having them share the same interface is okay, but then I would have to duplicate the shared code (but it would allow me to change the baz() methods and make them both final). Commented Aug 16, 2012 at 17:57
  • @RobKennedy: The RFCs in question define two different behaviors under two different scenarios. Each of these classes models one of those scenarios, but they both share a lot of other code. If I don't use inheritance, then I have to repeat that shared code, keep it in sync for the life of the library, etc. I'd rather have DRY code than final methods, but I wanted to ping the community for alternatives I overlooked, if any. Commented Aug 16, 2012 at 18:02

3 Answers 3

Reset to default
2

I think I got a way to do this. It is more a trick than a really clean design thing but I think I got the point.

abstract class Foo {
private $bazBehaviour;
    public function __construct($bazBehaviour){
        $this->bazBehaviour=!empty($bazBehaviour)?$bazBehaviour:"defaultBazBehaviour";
    }
   final public function baz() {
       $this->bazBehaviour();
   }
   final protected function defaultBazBehaviour(){
        echo "Foo::Baz()";
    }
   // other methods here
}

abstract class Bar extends Foo {
    public function __construct(){
       parent::__construct("bazBehaviour");
    }
    final protected function bazBehaviour() {
        echo 'Bar::baz()';
     } 
}
class toto extends Bar{
     public function __construct(){
       parent::__construct();
    }
}
$d = new toto();
$d->baz();

with PHP 5.3.13 it sends : Bar::Baz()

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

+1 because I never thought about doing it this way. Unfortunately I can't accept, since < PHP 5.4 doesn't have closure binding, so the closure passed to the constructor wouldn't be able to use non-public methods and properties. This solution still might be useful to others though.
Hey, I successed in doing it like you want with the "protected visibility" and final keyword. There is no "closure" in PHP way. I edit my answer.
1

This seems like a situation where the idea "Favor composition over inheritance" applies. It's a little bit repetitive, but it doesn't involve repetition of implementations and gives you the functionality you want.

interface Bazr {
    public function baz();

    public function myOtherMethod1();
    public function myOtherMethod2();
}

public class Foo implements Bazr {
  public final function baz() {} 
  public function myOtherMethod1() {/* default implementation of some method */}
  public function myOtherMethod2() {/* yeah */}
}

public class Bar implements Bazr {
  private parentBazr = null;
  public function __construct() {
    $this->parentBazr = new Foo();
  }

  public final function baz() {}
  public function myOtherMethod1() {
    $this->parentBazr->myOtherMethod1();
  }
  public function myOtherMethod2() {
    $this->parentBazr->myOtherMethod1();
  }
}

Both Foo and Bar can be extended, Bar "composes" Foo's functionality, and baz is final in both Foo and Bar. I'm not sure if you prefer to include or omit the interface... PHP doesn't have typed variables so it's probably not necessary besides for enforcing the contract with the two implementing classes. The disadvantage of defining the interface is that others can then implement the interface (though that would also be the case with a trait).

Sorry if I mixed java/php syntax, I think I left out some "$"'s.

Improve this answer

1 Comment

I think you're right. And I will probably get around having to redefine the interface by using __call() to simply pass all calls to the parent. Thanks for this!
0

Sorry to say, your requirement is contradictory:

my problem is that I'd like to make it so that neither implementation of 
the baz() method can be overridden

However you are overriding Foo:baz() in Bar..so, there are some fundamental issues with the design/requirement here.

Improve this answer

6 Comments

Please read the entire question. In particular, I already stated that there are design/requirement issues here, and I'm asking for alternatives that satisfy my two criteria. Reiterating what I already know is nonfunctional does not answer my question.
If you did state that in particular, I cannot see it mate :) And in case you do want something that does answer your question then here it is: Is there any other design I can use to enforce that both methods shouldn't be overridden? Answer: NO
That's neither the question I asked, nor the correct answer for your own question. :-)
Is there any other design I can use to enforce that both methods shouldn't be overridden, while simultaneously keeping the code DRY (e.g. not removing the inheritance and duplicating all the code)? Is that not what the last sentence of your question says, or am I reading invisible ink? :P
That is, but that's not what you posted before. :-) To address your other point, though, I did state that I'm full aware of the conflicting requirements here: if I make Foo::baz() final, then Bar itself obviously can't override it either. I guess you just missed that part. And as I've said in other comments, I'm specifically looking for design workarounds (like what I can do with PHP 5.4's traits, only without the >= 5.4 requirement). I wasn't asking whether making a final method overrideable only for one child class was possible, because I know it isn't.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.