I have one top class, let's say School.
And a couple of classes extending the School class.
Normally, if I had to call one of the child classes I would use:
new Math('aaa'), or new English(array('foo'));
Every child class has different parameters.
Now, what is better:
1) Creating factory method in the School class, so :
School::Factory('aaa') would return Math('aaa') class based on the given parameters to the Factory() method
2) Or simply calling each child classes directly?
EDIT: I have only two child classes, my problem is that I don't know if doing this is worth a bit of simplicity in production code. I would just check which parameters were passed to the Factory method, and based on this information I'd call one of these two classes. What do you think?
On one side I'll be able to write simpler code.
On the other every time I'll need to add new child class (though there are very little chances to do that), I'll need to change Factory() method either, so I have a dependency here.
1) Creating factory method in the School class, so :
You say that you have 2 classes extending School. Therefore, School should not act as a factory. The parent class shouldn't know anything about its children/subclasses.
2) Or simply calling each child classes directly?
Or you could have a "CourseFactory" or "LectureFactory" with createMath( aaa ), for example. Or depending on the case, maybe createLecture("math").
However, it makes no sense in your example that Math or English extend School (unless you mean MathSchool and EnglishSchool, but I understood it as MathCourse and EnglishCourse)
Related
I've been reading up about PHP's traits. Specifically I came across this article. They probide an example involving objects that need to implement a shareable interface. The following argument is presented:
Does it make sense to duplicate the share() method in every class that implements the Shareable interface?
No.
Does it make sense to have an AbstractShare class that objects who implement the Shareable interface extend?
No.
Does it make sense to have the share() method implemented as part of an AbstractEntity class, but then blocked out for the Message object?
No.
Does it make sense to implement a ShareableTrait that fulfils the interface contract and can therefore be easily added to only objects that require it?
Yes!
I can understand the first and third points. But the second one confuses me. What exactly is wrong with having an abstract class called AbstractShareable or something like that which contains the functionality to share something, and then extending from it?
An interface is specifically designed to create reliable, well, interfaces, independent of the implementing class. Meaning:
function (Shareable $sharable) {
$shareable->share();
}
You can be assured that this code will always work (any object being passed in having a share() method), due to your interface declaration.
You can achieve the same thing using a class hierarchy; i.e. if you require a certain class, you can be sure that all of its children will also have the same methods the parent has. But: this imposes a strict class hierarchy on your classes. All classes have to extend one specific base class. And they can only extend that one specific class. You couldn't use a class hierarchy for both an AbstractSharable and an AbstractLoggable, say. That's why the class hierarchy solution is too inflexible. It would only allow you to implement one "trait". Or you'd have to mash all your various "traits" together into the same base class. Then you have a giant monolithic base class.
Separating characteristics into small individual interfaces keeps your code simple and flexible. Traits provide a flexible implementation analogue to an interface's specification.
From time to time one of my models will need to call another. What's the best way to track this?
I was using an array in the base class of each model, so that if Model A called Model B more than once, the second and successive calls would return the existing instance, rather than loading a new one.
While this works fine for simple cases, I can see it has limitations. For example, take the case where Model A loads Model B and Model C; then Model C needs access to Model B (or even A) - it will load the class again!
I suspect that I need a coordinating object, external to the model classes, which acts as a repository. What patterns should I be looking at?
BTW, I am using PHP.
EDIT: Another consideration is that my views may call model methods directly too. In these cases it would make sense to serve up an already instantiated model, rather than a new one...
Thanks!
Take a look at the observer pattern thats used in such case.
Its easy .. each model have a list with listeners and when something happens it says to all Listeners hey something happend
I have three classes which basically do very similar things;
Store a record of an uploaded file.
Move and upload the file.
Set the status of the record to active or revoked.
One of the classes has an additional update method. Each class references a different table in the database because although some of the fields are common, there are a couple of fields extra in some of the tables.
As quite a lot of the functionality is common I think it may be best to extend a base class rather than duplicating a lot of the functionality.
My only quarrel is the construct function on the base class. As some of the fields in each table are additional I'm concerned this will prevent a base class.
I have thought of using an abstract class as this will allow me to extend on functionality whilst maintaining most of the things in one place. But it's the problem with the construct. Can I have an abstract class with no construct?
Any ideas?
If I understand you: You can have any class without __construct(). And you can always overwrite every method (except methods, that are declared as final) of a parent class in a child class.
I am sorry but I guess I do not completely understand your question. Anyway in inherited class you can always override the constructor and within it invoke the superclass constructor plus further stuff if needed.
at my working place (php only) we have a base class for database abstraction. When you want to add a new database table to the base layer, you have to create a subclass of this base class and override some methods to define individual behaviour for using this table. The normal behaviour should stay the same.
Now I have seen many new programmers at our company, who just override the method for the default behaviour. Some are so "nice" to put in all the default behaviour and just add there individual stuff where they like it, others kill themself trying to use the baseclass and their inheritor.
My first thought to solve this problem, was thinking about abstract methods that should be overriden by inheriting classes. But beside other arguments against abstract methods, "abstract" just does not show why the baseclass can't be used by its own and why these function should be overriden.
After some googling around I didn't find a good answer to implementing "real" virtual functions in php (just that there is a virtual function, that nearly kills all hope of a concrete implementation).
So, what would you do with this matter?
In PHP all public and protected functions are "virtual". You can prevent functions from being overriden by prepending the final keyword. (Or by making them private, but this is probably a bad idea).
In the design of the baseclass I would think of behaviors that subclasses would want to affect.
I would for example create empty functions like before_update() and after_insert().
function after_insert() {
// Virtual
}
Which the baseclass will call when an update/insert event occurs.
Maybe an is_valid() function which always returns true in the baseclass, and use the commentblock to describe what the consequences are when a subclass return false.
Hopefully this would give you some inspiration.
You can always use the "final" keyword to prevent some of the classes functions from being overridden if people are using the class in the wrong way.
It sounds to me like they are unable to acheive certain functionality hence overriding the methods. You may need to take a look at the design of your classes.
Without an example of the implementation of your base class, it's hard to give concrete info. But a few things come to mind:
Database abstraction is complex stuff to begin with. I understand that you want to keep it lean, clean and mean, but I think it's pretty darn difficult. You really have to take a thorough look at the specs of different DB engines to see what parts are general and what parts need specialization. Also; are you sure you don't have DB abstraction mixed up with the Table Data Gateway pattern, as you are talking about adding DB tables by extending the base class?
The methods of your current base class might be doing too much and/or are not general enough to begin with, if the extended classes are bending over backwards too keep it clean. Maybe you should break the base class interface methods up in smaller protected methods that are general enough to be reused in the overriding methods of the extended classes? Or vice versa: maybe you should have hooks to overridable methods in your interface methods.
Following from point 2: What's wrong with having an abstract class with some general implemented methods, and let your vanilla class (your base class) and other classes inherit from that?
Lastly, maybe you should just enforce an interface to be implemented, in stead of extending the base class?
I need help in designing my PHP classes where I need to extend from multiple classes.
I have a general class, Pagination.php that does all sort of pagination and sorting. All other classes will use this for pagination.
To make my life easier, I made a class generator that generates a class from MySQL table. All the properties, getters, setters and common methods are created automatically, which really saves time and money.
As an example, class Staff_Base in Staff_Base.php is generated automatically from SQL table t_staff.
Since class Staff_Base is automatically generated from SQL table, any 'custom' methods / properties are located in another class that extends Staff_Base.php. (So that whenever a new field is added, I can simply regenerate Staff_Base class and overwrite in Staff_Base.php).
So I have class Staff.php that extends Staff_Base.php.
The problem is, Staff.php also needs to extend another class, Pagination.php.
(The current workaround is to put methods in Pagination.php into every class. This is really troublesome whenever I make changes to the pagination/sorting methods.)
How do I do this?
What is the best design pattern to achieve this?
I know common suggestions to restructure my classes, but I really think hard of other workaround/solution. Also, I may also need to extend other classes than Pagination.php.
Thanks!
Can you have your generated Staff_Base class inherit from Pagination? Or does Staff_Base already inherit from another base class (that you do not have control over)...
Sounds like either Doctrine or Propel, I do not recall which uses the *_Base class system.
My suggestion would be to rewrite pagination to be able to be used by your entity classes instead of requiring your entity classes to extend it.
So if I am reading what you wrote correctly, since you can't inherit from 2 classes you are duplicating paginate into every class you have.
Class stacking is a solution. One of the first things I googled.
I would recommend changing your Staff_Base.php generator to make that class extend Pagination by default. That way Staff extends Staff_Base, and Staff_Base extends Pagination. I think that's probably the cleanest (and most object-oriented) way of getting the results you want.
you cant, multiple inheritance is not supported in php, but if you do a google search on this topic you can find some workarounds...
It sounds like you're mixing things up here. A class (such as a Staff class) is used to represent a single entity. Eg:
$john = new Staff('John');
How exactly does the paging fit into this? Being page-able (paginatable?) sounds like a property of whatever it is that allows access to these Staff entities, not of the entity itself. That way, the way is clear for each type of Staff class you create to inherit from the base class.
So, what I believe would be the solution you need:
A Staff class (Staff_Base, and its graph of children)
A Staff Data Access Object (DAO\Staff would be a nice name, if you're using namespaces)
An Interface, to signal to the world that a DAO can be paged
Import to note is that there is no direct inheritance between the DAO class and the Staff class. You can still generate the Staff_Base class based on its properties in the database, and extend from there... as long as you don't include the actual data access in that class.
The code using this would then look something like this:
<?php
$staffDao = new DAO\Staff;
$staffMembers = $staffDao->getPagedResult($start, $amount);
?>
Edited to emphasize that the inheritance structure should be separate from the actual retrieval
Well, you might already know that PHP doesn't support multiple inheritance. One way around might be using Interfaces instead of superclasses, although, if the logic is identical for each implementing of the interface, this might become tedious. How about writing a code generator, that simply injects the methods to each class? You seem to already do that on the "common methods".
Oh, and using getters and setters (as they are used in e.g. Java) in PHP is considered not a good idea. Objects are slow as they are, so using public fields is considered the norm.
Edit: Then there's the __call()-hack, which could recognize the methods that actually reside in your other classes, and call them manually.