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.
Related
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)
This is less of an issue, and more of a best practice question - I know these are subject to opinion, but I'm sure there must be a standard convention for this particular problem.
Let's say I've got two classes, Account and Associate.
Account contains several methods which are useful to Associate, and so naturally I'd extend the Account class to Associate.
However, an issue of course arises when I have two methods with the same name e.g. create().
So far to counteract this instead of extending the parent class, I've been instantiating it as a variable in the child classes __construct() method, and then calling methods through that, e.g. $this->Account->create();.
Is there another way, e.g. a norm for using an extended classes methods while still having a method of the same name in the child class?
Any answers would be greatly appreciated!
Account contains several methods which are useful to Associate, and so naturally I'd extend the Account class to Associate.
No, this is not naturally, you are misusing inheritance. Or would you say that an associate is an account? If it has an account, use composition. If not, but the account class has methods that are useful for the associate class, they probably shouldn't be in the account class at all. Extract them to one or more other classes which can be used by both, Account and Associate.
The child class method will be called using $this if you are within the child class methods. If you want the parent method though, you'd call parent::create(); from within the child method.
But that is if you absolutely need to extend the Account class, which sounds unnecessary. If the "Account" class has public methods then you don't need to extend it, you can just call them after instantiating the class:
$account = new Account();
$account->create();
Or, if it is a public static method:
$creation = Account::create();
I am a 4 days old yii fan and I like it so much.
I have a special database table that can't be used by CActiveRecord directly. My solution is to subclass CModel to have my own logic for listing, creating, saving and deleting records. My new CModel subclass cant not instantiated; it seems that CModel requires more methods to be defined to allow creating an instance from it.
My question is: Is this the right approach to go or there are better ways? If yes, what are the missing methods to define to make my new class complete; not abstract
Thanks
I usually create my own classes to handle the so called 'logic' of the webapp that I'm building.
I place it in another folder (usually the logics folder) and auto import the directory from the config. The logic classes doesn't subclass from any Model
public class ProfitLogic { ... }
where inside the class(es) I implement functions that instantiates and use any ActiveRecord(s) that I need.
The reasoning for this is that when prototyping I often refine my database design, and I need to regenerate the ActiveRecords again :p
Your approach is fine generally speaking, and would be fine even if you were not "forced" to adopt it. I use a CActiveRecord subclass as the base for my models to provide additional custom functionality.
As for your other question, you only need to implement attributeNames() to be able to instantiate objects of your class.
However, why do you not subclass CActiveRecord directly instead of CModel? You can still override any and all methods you choose to. Is your database so dramatically different from the usual schemas that you won't be able to reuse any of the logic?
I'm fairly new to Yii as well, but have found that extending CForm, as in the default ContactForm model can be useful.
Not the best for having lots of heavy business logic, but it touches on your point of breaking out of the typical workflow.
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.