0

I have stumbled upon an interesting problem/bug that I eventually solved, but the solution is not what I expected or would like it to be.

The setup is simple. There is an abstract static class Factory, which has a reference to a singleton (Registry) as well as two static properties, model and table.

There are a number of static classes building upon/inheriting from this abstract class and they all have an init() method in which they set the model and table properties. Of course, since model and table are static they can only have one value which is the same for all the child classes of the abstract Factory class. This is the problem/bug.

However, my aim is to have each child class have its own model and table so I am forced to declare model and table in each child class as a static property. This seems a bit cumbersome (and not very DRY), but it seems to me that this is the only solution if I want to have (1) the classes inherit from the abstract Factory class and (2) remain static.

Is my assumption correct or is there another approach that I am missing?

Bart Jacobs
  • 9,022
  • 7
  • 47
  • 88
  • 1
    please read : http://stackoverflow.com/questions/137975/what-is-so-bad-about-singletons – tereško Oct 11 '11 at 09:24
  • I'm not entirely sure what you refer to this discussion about the singleton design pattern. Granted, singletons do have pros and cons, but the question at hand is about a specific use case of static classes inheriting from an abstract static class while sharing a set of identical properties. Thanks for the link. – Bart Jacobs Oct 11 '11 at 10:16

1 Answers1

1

The goal is to have different values for $model and $table in different static child classes?

Assuming that is the case, I don't see how You could possibly accomplish that without explicitly defining them different in each child class.

I don't think it is cumbersome. I see it as a good practice - by keeping functionality where it belongs.

Saul
  • 17,973
  • 8
  • 64
  • 88
  • That is correct. I assume that there is no other approach in this case. Cumbersome is probably a bad choice of words, but I try to write as DRY as possible. Thanks for your answer. – Bart Jacobs Oct 11 '11 at 10:14
  • 1
    @BartJacobs - DRY is even more beneficial when balanced with others, see [Real Ultimate Programming Power](http://www.codinghorror.com/blog/2009/02/real-ultimate-programming-power.html) – Saul Oct 11 '11 at 10:25