I've been trying to build a PDO extension, and I wanted to have special classes in different files but I wanted to have them all link to the same original class.
I have worked with some Frameworks and I see that they use the extends class keyword, and I thought that it added the class you are making to the class that you have given.
Some code I have tried is:
class PSMQuery extends PSM {
// Functions and Jargon
}
I tried making an object for the original PSM class:
$psm = new PSM(/*Information*/);
But when I call the $psm variable like $psm->functionInTheExtendedClass it comes up with an error saying that it was an undefined method when I called it.
Am I using the extends keyword incorrectly?
Am I using the extends keyword incorrectly?
You use it correctly, but it works the other way around.
If PSMQuery extends from PSM, this means you can access and use stuff from PSM in PSMQuery, but not the other way around.
I think to understand it you can use a good example:
class twoRoomApartment extends building { }
So now you can think logical and already see, that a two room apartment probably extends from a building and not the other way around.
Means now in your code, you just create an instance of PSMQuery.
It's inheritance.
Parent : PSM
Child : PSMQuery
When you use extends you are extending parent class functionality and creating child class.
Your child class will inherit all the parent class functionality.
Parent will not get child class functionality.
So when u r trying to create object of parent class it doesn't know child class functionality.
You need to create object of child class and then you can access methods from parent class.
Related
I have trouble understanding the import behavior. Let me explain, I have a class B outside of any namespace (for some reason I have double autoload, a proprietary one, and the classic PSR-4, I guess this can have something to do with my issue, I'm ready to gather more information on this tidbit if necessary). In this class I import a class A from a namespace, and it turns out when in a method of my children class I can use the A class to instantiate an object, but when I try to tell class B to extend class A it says the FQN is not found.
<?php
use \App\Services\AbstractController as BaseController;
class BarController extends BaseController
{
public function test() {
$foo = new BaseController();
}
}
There I would have an error on the "class BarController extends BaseController" line saying BaseController can't be found, but if I delete the extends part, the test method will run smoothly with its instantiation (I did try to manipulate the object, it sure works well).
so I guess my question is, is there any difference on the treatment of a class to extend vs. using it to instantiate an object.
Thanks in advance for your thoughts, and I'm ready to answer any additional question.
I did manage to deal with the issue. The controller class was instantiated inside the proprietary autoloader but the method was called later on the process. I switched both autoloader order (ie. first psr-4 then proprietary one) in the init and it works well.
I'm trying to make an application in CodeIgniter where every controller extends a base controller called 'Incyte_Controller.php' and where every model extends a base model called 'Incyte_Model.php'.
I used to import these parent classes in every child class using 'require', but want to change that as it is too redundant for me.
So i moved the base files to 'application/core' and changed the base class prefix in Config.php from 'MY_' to 'Incyte_'.
Now, all controllers can extend 'Incyte_Controller' without the use of 'required'.
But, strangely, when the application tries to load a model it says:
Fatal error: Cannot instantiate abstract class Incyte_Model in
/opt/lampp/htdocs/incyte/system/core/Common.php on line 172
This happens even though i try to extend the base model in the exact same way i extended the base controller.
I checked for spelling errors, including capital letters, but found none.
Also, i must mention that both base classes are abstract classes, because they shouldn't operate on themselves(my teachers would most likely prefer that)
Please understand i KNOW abstract classes themselves cannot be instantiated, but classes that extend abstract classes CAN be instantiated, and that is what i'm trying to do. But it doesn't seem to work in one case, while it does work in another very similar case, which is strange.
I hope any of you can help
A better way to do this would be to extend the core model class to something like MY_Incyte_Model and then extend this in your actual models.
So instead of class AwesomeModel extends CI_Model you can have class AwesomeModel extends MY_Incyte_Model.
Read more here
https://ellislab.com/codeigniter/user-guide/general/core_classes.html
Go to /opt/lampp/htdocs/incyte/system/core/Common.php and you will find a line trying to do something like this:
new Incyte_Model();
The Incyte_Model class is abstract (which means that it can't be used directly - it has to be sub-classed).
Look into how PHP handles Object Oriented (OO) code.
In particular, look at class abstractions.
The application I am working on has a wrapper(DAO) for each model class. The model itself is derived from Eloquent class. The issue is that junior developers keep calling methods like ModelClass:Where() or ModelClass::find() rather than using DAOClass:DaoMethod(). How can I restrict in my class that implementor of class can't do something like ModelClass::where()?
Thanks
The final keyword should do the trick. Just make all your desired DAOClass methods final. That way, once they are called from a class which extends your DAOClass, they will get a fatal error.
We are looking to build a system with core classes and the ability to extend these core classes and are looking in to using namespaces.
The problem we are having is working out if we can extend an extended class without extending the class that it extends from
For example, if we have folders and files as below
shared/classes/Entity.php
shared/classes/DatabaseEntity.php - Extends Entity.php
shared/classes/User.php - Extends DatabaseEntity.php
classes/ - Holds classes which extend from the shared classes
If we wanted to create a custom DatabaseEntity class without creating a custom User class , is this possible?
The way I understand this is that the User class will be looking in the shared namespace to extend the DatabaseEntity class but as we have extended the DatabaseEntity class, it needs to look at the top level classes directory
Example of shared/classes/User.php
namespace shared;
class User extends DatabaseEntity {
}
Example of shared/classes/DatabaseEntity.php
namespace shared;
abstract class DatabaseEntity extends Entity {
}
Example of classes/DatabaseEntity.php
namespace custom;
use shared\classes\Entity;
abstract class DatabaseEntity extends Entity {
//Some custom functionality to extend shared/DatabaseEntity
}
So if we didn't want to change the User class to say
use custom/DatabaseEntity
Then is this possible?
Hopefully that makes sense
Thanks in advance for any help
If you don't want to add to User class
use custom/DatabaseEntity
and you want to extend custom/DatabaseEntity
you may just change class declaration from
namespace shared;
class User extends DatabaseEntity {
}
to
namespace shared;
class User extends \custom\DatabaseEntity {
}
if you want to extend \custom\DatabaseEntity.
If it's not want you want to achieve I cannot understand your problem - you ask two questions.
You asked
If we wanted to create a custom DatabaseEntity class without creating
a custom User class , is this possible?
The answer is - yes, you just created it in your example. You created custom DatabaseEntity class without creating custom User class.
But if you want to achieve:
it needs to look at the top level classes directory
you need to tell User class to extend specific class - so you will need to extend using fully qualified class or import namespace using use and creating alias
I don't know if I understand you well, but you want to create CustomDatabaseEntity class that will extend DatabaseEntity and you don't want that CustomDatabaseEntity extends User class.
It's of course possible. You can create as many child classes as you want. As User class is defined that it extend DatabaseEntity class it will even don't know that you created CustomDatabaseEntity
I also think that you are using it a bit wrong. If DatabaseEntity have anything common with database and not with User itself, you should rather create Interface DatabaseEntityInterface, those two DatabaseEntity classes should implement interface
and then in User class you should pass it as constructor argument
class User {
protected $dbi;
public function _construct(DatabaseEntityInterface $dbi) {
$this->dbi = $dbi
}
}
and later you can pass to User class either class for shared folder or the one from classes
I'm building a class that interacts with an API. Say the API has a "get_something" method for "foo" objects and "bar" objects. I want my class to expose a "get_something" method, but be able to distinguish if it's for "foo" or for "bar."
What's a good solution for me? Can I create a class that has multiple name spaces? Would that be a good idea?
Maybe I should have nested classes?
you should look at namespaces as packages in java. a class belongs to 1 package only
what you can do though is have
namespace A_NS;
class A { ...}
namespace B_NS;
class A extends \A_NS\A {};
in that case class A will exist under namespace A_NS, and another class A' will exist under B_NS, which will extend class \NS_A\A;
you could check an object's class, or implement some identifier inside to distinguish.
overall, i would recommend that the design of your system will treat each class as if it belongs to 1 namespace only.
Two ways to do this, you can use an interface (http://us3.php.net/interface), which ensures that classes implementing the interface will have specified methods. Or create a parent class with abstract method (http://us3.php.net/abstract) get_something which will force any child classes to also have the class. Then you should be able to do a get_class($object) to determine which class was instantiated.