Base class for my framework?
Moderator: General Moderators
Base class for my framework?
I have only seen a few of the major frameworks use a "base class". I am putting together a really lightweight, quick and dirty framework mainly for educational purposes. I was considering using a base class because I can see how convenient it would be to have all (or most) of my classes to be able to rely on having certain methods defined. I can see how it might be a good way to deal with debugging and testing, but I just want to know what you guys think about them. Good practice? Bad practice? If you use them, what sort of methods do you define? If you don't, why not? Thanks fellas!
Re: Base class for my framework?
I use a base class for Modules, and Controllers. 2 Separate Classes, which extend another base class that essentially defines how to load other classes/modules (Which add the registry to those classes etc).
In the modules base class, it has some database functions of course. In the controllers it has ways of loading a View, and gathering Input to pass along to modules.
In the modules base class, it has some database functions of course. In the controllers it has ways of loading a View, and gathering Input to pass along to modules.
Re: Base class for my framework?
See that's what I figured... that it would be pretty damn convenient to have the ability to KNOW a method exists in all your objects. Especially for things like unit testing. Although I can't think of exactly how I would use it for unit testing, it just seems like it might be a really cool way to provide "unit testing methods" although something about this smells to me... Is it bad practice to create methods that are only intended to be used for unit testing? I remember reading something about this, but I can't remember what.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Base class for my framework?
Originally I had a lengthly reply...but I'll just address the following:
1) Testing methods, should not exist in production code - especially in interpreted languages like PHP - it wastes resources.
2) Unit testing anything with inheritence becomes increasingly difficult or at least a greater PITA
I want to reply carefully, like stepping on eggshells - because everyone will have one of two opinions on this and neither are "right" or "wrong" it really depends on the circumstances.
Inheritence is bad, not in theory, but in use. I use inheritence frequently, but more often than not, I find myself refactoring entire class families into something more linear - especially after I understand the problem clearly.
Most of us learn inheritence first, then about composition, so it's natural we attempt to solve problems with each technique in that order. Both are valid solutions, but solve different problems better or worse than the other.
In PHP...the general rule of thumb I follow: "If more than 3 classes need to derive from a super class - I should re-think my design"
I know this sounds crazy, because it's a detriment to very idea of code-reuse "a la" inheritence - but it's a rule of thumb that has served me well in keeping my designs flexible and extensible.
There are cetainlly reasons, some of those PHP frameworks use a super base class design...but I think it's more "old habits" rather than best interest of the project. When I first came to PHP from C++ I had a helluva time *not* wanting to throw everything into a base class...it's common in C++ and some Java Frameworks (J2EE). The thing is, under those environments and especially in Window'ing frameworks it often makes sense to have a super base class. The problems those base classes solve however, are already solved for PHP developers, either by the language itself or the environment.
- RTTI
- Object Serialization
So you don't really need a super base class in PHP general application frameworks.
Functionality like:
- Logging
- Profiling
- Language
- Debugging
- Class or module loading
I feel these are all better left to the discretion of the client developer, not the framework developer. Basically, let them determine what functionallity needs to be "plugged" into the code they are writing to accomplish the task at hand.
If I'm writing a CLI script - I likely don't need language functionality.
As for the others, I would rather use my own logging facility and debugging techniques.
So you see, whether you use a super base class or not, is really a matter of personal opinion, experience and project requirements.
If you like the logging facilities, debugging methods, language loading, class loading techniques and code...then absolutely put it in a base class and save yourself some wiring work when plugging all those objects togather manually.
If your target audience is the greater PHP community - I would suggest going the way of Zend and keeping things independent - cause it seems to be the choice of popular opinion.
Cheers
Why not just check to make sure the object is of a certain, interface and if you want functionality, make it a abstract base class you check for???The Ninja Space Goat wrote:See that's what I figured... that it would be pretty damn convenient to have the ability to KNOW a method exists in all your objects.
Yes. Bad practice.The Ninja Space Goat wrote:Especially for things like unit testing. Although I can't think of exactly how I would use it for unit testing, it just seems like it might be a really cool way to provide "unit testing methods" although something about this smells to me... Is it bad practice to create methods that are only intended to be used for unit testing?
1) Testing methods, should not exist in production code - especially in interpreted languages like PHP - it wastes resources.
2) Unit testing anything with inheritence becomes increasingly difficult or at least a greater PITA
I want to reply carefully, like stepping on eggshells - because everyone will have one of two opinions on this and neither are "right" or "wrong" it really depends on the circumstances.
Inheritence is bad, not in theory, but in use. I use inheritence frequently, but more often than not, I find myself refactoring entire class families into something more linear - especially after I understand the problem clearly.
Most of us learn inheritence first, then about composition, so it's natural we attempt to solve problems with each technique in that order. Both are valid solutions, but solve different problems better or worse than the other.
In PHP...the general rule of thumb I follow: "If more than 3 classes need to derive from a super class - I should re-think my design"
I know this sounds crazy, because it's a detriment to very idea of code-reuse "a la" inheritence - but it's a rule of thumb that has served me well in keeping my designs flexible and extensible.
There are cetainlly reasons, some of those PHP frameworks use a super base class design...but I think it's more "old habits" rather than best interest of the project. When I first came to PHP from C++ I had a helluva time *not* wanting to throw everything into a base class...it's common in C++ and some Java Frameworks (J2EE). The thing is, under those environments and especially in Window'ing frameworks it often makes sense to have a super base class. The problems those base classes solve however, are already solved for PHP developers, either by the language itself or the environment.
- RTTI
- Object Serialization
So you don't really need a super base class in PHP general application frameworks.
Functionality like:
- Logging
- Profiling
- Language
- Debugging
- Class or module loading
I feel these are all better left to the discretion of the client developer, not the framework developer. Basically, let them determine what functionallity needs to be "plugged" into the code they are writing to accomplish the task at hand.
If I'm writing a CLI script - I likely don't need language functionality.
As for the others, I would rather use my own logging facility and debugging techniques.
So you see, whether you use a super base class or not, is really a matter of personal opinion, experience and project requirements.
If you like the logging facilities, debugging methods, language loading, class loading techniques and code...then absolutely put it in a base class and save yourself some wiring work when plugging all those objects togather manually.
If your target audience is the greater PHP community - I would suggest going the way of Zend and keeping things independent - cause it seems to be the choice of popular opinion.
Cheers
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
Re: Base class for my framework?
Besides having the standard object base class, that provides tools for data manipulation, i.e. importing, exporting, etc, I don't see a need to have a base class ever throughout the entire framework. What exactly did you have in mind for this base class?
I have multiple, less generic base classes, like A_Controller_Action, but nothing universal.
I have multiple, less generic base classes, like A_Controller_Action, but nothing universal.
Re: Base class for my framework?
Alright, I have decided NOT to use one common base class because I can't think of any specific reason why it would be necessary