Currently I am trying to understand how OOP applies to PHP and I am having trouble with calling my class when I am getting into inheritance.
I am using the following PHP code:
require_once("init.php");
$table = new Table();
$table->draw();
$customer1 = new Customer();
Since the table class is just a plain class (not inherited) it will load correctly.
The init.php has the following PHP code:
function __autoload($class_name) {
require_once('classes/'.$class_name . '.class.php');
}
Because the Customer class is inhereting the User class, the code for the Customer class is inside the User class, however the __autoload function is trying to call for the customer.class.php now.
My Customer class would look something like this:
class User
{
private $_username;
public function __construct($name)
{
$this->_username = $name;
}
public function getUsername()
{
return $this->_username;
}
}
class Customer extends User
{
public function __construct()
{
//some code here
}
}
Cany anyone explain me please how I should call an inherited class with PHP?
You should only have one class per file. Your autoload will handle everything for you as long as every class is in its own file, named the same way...
Put all your Customer class code inside Customer.class.php
Each class should be written in its own file, exactly because of this autoload. There's no reason why class Customer must be within the same file as class User, just put it in its own file and your autoloader will handle it correctly.
Otherwise, you'll have to adopt some other naming scheme and write a more intelligent autoloader which can find classes in files with different names. (Don't do that, not really.)
Related
I've written this code for check behavior of my app and i don't why this code works. I have 2 classes and 1 entry point
PHP 7.2
class Base{
public function check(){
return $this->checkUnexist();
}
}
class Main extends Base
{
public function checkUnexist()
{
return 'UNEXIST METHOD CALLED';
}
}
$main = new Main();
echo $main->check();
Expected result something like called method unexist. But it calls method from child class with "this". Why? And where i can read about this issue ?
Trying to access child values from base(parent) class is a bad design. What if in the future someone will create another class based on your parent class, forget to create that specific property you are trying to access in your parent class?
As per my understanding, When you extend the class the child class have all the property, methods available for the Main class object, which are accessible outside the class.
So when you created an object of Main class your class internally looks like
class Main
{
public function checkUnexist()
{
return 'UNEXIST METHOD CALLED';
}
public function check(){
return $this->checkUnexist();
}
}
the check method exists and you will get the response. Try to make the method checkUnexist private or protected you will see the difference.
I have an abstract question for you.
Question:
How can a subclass that extends an abstract class register itself to the abstract class or another class?
Problem:
Guess we have a module master named ModuleMaster and maybe someone else writes another modules to handle a specific problem without modifying the master class and named it ModuleA. For that reason we want to implement a dynamic loading of problem solutions.
My idea:
File: Extensions.php:
namespace Project\Extensions;
class Extensions
{
public function getLoadedModules()
{
var_dump(ModuleMaster::LOADED_MODULES);
}
}
File: Modules\ModuleMaster.php:
namespace Project\Extensions\Modules;
abtract class ModuleMaster
{
public const LOADED_MODULES = array();
}
File: Modules\ModuleA.php:
namespace Project\Extensions\Modules;
class ModuleA extends ModuleMaster
{
}
I hope you understand what I mean and can help with that abstract problem.
This is very strange to use. It's probably a better design to have an external registry for your module. But I think you're asking for this:
File: Extensions.php:
namespace Project\Extensions;
use \Project\Extensions\Modules\ModuleMaster;
class Extensions
{
public function getLoadedModules()
{
var_dump(ModuleMaster::getLoadedModules());
}
}
File: Modules\ModuleMaster.php:
namespace Project\Extensions\Modules;
abstract class ModuleMaster
{
public static function getLoadedModules() {
$parent = self::class;
return array_values(array_filter(\get_declared_classes(), function ($class) use ($parent) {
return in_array($parent, class_parents($class));
}));
}
}
File: Modules\ModuleA.php:
namespace Project\Extensions\Modules;
use \Project\Extensions\Modules\ModuleMaster;
class ModuleA extends ModuleMaster
{
}
Example use:
$e = new \Project\Extensions\Extensions;
$e->getLoadedModules();
Example result:
array(1) {
[0]=>
string(34) "Project\Extensions\Modules\ModuleA"
}
Please note that the code only works if all your class files are included into the context before running getLoadedModules(). PHP won't know your class exists if it is not already loaded into the context.
You seem to be trying to create a capability in the parent class which is not required or inappropriate in the child class. This is the opposite of inheritance and hence an anti-pattern. Further, even though it might be considered as an extension of reflection, you are trying to put runtime data in a class - that's not what classes are for.
You've also not explained in any way that I can understand why you want to do this.
I suspect you really want to implement a factory, strategy or a registry object.
This is a follow-up to my previous question about resolving the diamond issue in php.
As I state in that question, I resolve my problem by using traits and passing the instance of the class to the method of the trait. Such as:
trait SecurityTrait
{
public function beforeExecuteRouteTrait($controller, Dispatcher $dispatcher)
{
// Do something that makes use of methods/members of the controller
}
}
class AppController extends Controller
{
use SecurityTrait;
public function beforeExecuteRoute(Dispatcher $dispatcher)
{
return $this->beforeExecuteRouteTrait($this, $dispatcher);
}
}
However, I am still uncomfortable with this as I don't think this is how traits are really supposed to be used. In my reading I haven't found any way in which to access class members in traits (make $this inside a trait refer to the class using it). Is this possible? Or is there another way to implement a similar behaviour?
After reading some of the answers...
Previously I thought I had received errors when using $this->... inside the trait and this led me to believe the trait could not access anything to do with the underlying class. After reading the answers I tried altering my code to use $this->... inside a trait again and it works - which means a typo several weeks ago has given me far too much headache...
The example given previously now looks like this
trait SecurityTrait
{
public function beforeExecuteRoute(Dispatcher $dispatcher)
{
// Do something that makes use of methods/members of the controller
}
}
class AppController extends Controller
{
use SecurityTrait;
}
Much cleaner and more easily understandable but provides the same functionality.
If you use a trait inside a class then that trait has full access to all class's members and vice versa - you can call private trait methods from the class itself.
Think of traits as code that literally gets copy/pasted into the class body.
For example:
trait Helper
{
public function getName()
{
return $this->name;
}
private function getClassName()
{
return get_class($this);
}
}
class Example
{
use Helper;
private $name = 'example';
public function callPrivateMethod()
{
// call a private method on a trait
return $this->getClassName();
}
}
$e = new Example();
print $e->getName(); // results in "example"
print $e->callPrivateMethod(); // results in "Example"
In my view referencing classes in traits is not the best way to use them but there's nothing stopping anyone from doing it.
No, that's exactly what Traits are for. Your class already extends a class so you can't inherit the methods and variables of any other classes.
Think of a Trait like copy/paste for code execution. When a class includes a Trait, it's just as if you had written all that code into the class itself.
Basically I'm looking for feedback or guidance on something I've created this week at work. The problem was that I had two types of document upload. These types both shared methods like upload, isUploaded, move etc. But, in some instances they both had unique functionality.
So I thought the best approach to handle this would be to create an abstract class which contains the common functionality and 2 separate classes which extend the base abstract class in order to inherit the common functionality.
So I have:
abstract class Upload {
protected $_id;
protected $_name;
protected $_dbTable;
abstract public function create(Filter $filter) {}
abstract public function update(Filter $filter) {}
public function __construct($id){
if(!is_null($id)){
$class = new get_called_class();
return new $class($id);
}
}
protected function upload(){
//Code implemented
}
protected function isUploaded(){
//Code implemented
}
protected function move(){
//Code implemented
}
}
Class Book_Upload extends Upload {
$dbTable = 'book';
public function __construct($id){
//Database stuff to obtain record information
//Set protected member variables
$results = $databaseCall();
$this->_id = $results['id'];
$this->_name = $results['name'];
}
public function create(Filter $filter) {
//Code implemented
}
public function update(Filter $filter) {
//Code implemenetd
}
//Other unique functions
}
Class Magazine_Upload extends Upload {
$dbTable = 'magazine';
Same as Booking_Upload but with additional functionality
plus abstract methods
}
My query is, am I using abstract methods correctly? Have I followed the correct path. Also, I'm not sure I need the construct in the abstract class. What if someone attempts to call $upload = new Upload($id)?
Any class should provide a single type of functionality (Single Responsibility Principle, example: Single Responsibility Principle - A hard to see example?).
An upload class must only deal with uploads. Without more code, I smell an over-functional class from your words that tries to accomplish both the upload and document-spesific tasks.
So before going that way, you should define well what these classes will be doing. Are those document-spesific functionalities really related to the actual act of uploading?
You're extending class doesn't call parent::__construct() so the abstract __construct won't make any difference.
You are using abstract classes correctly; they are base classes that are to be built upon by other classes that share common functions and/or will have the same functionality but is implemented differently.
Abstract classes are a base to be built upon that provide common functionality and structure to other classes.
In my CI system\libraries directory I have a new class named DD_Controller.php. This file looks like this:
<?php if ( ! defined('BASEPATH')) exit('No direct script access allowed');
class DD_Controller extends Controller
{
protected $ddauthentication;
function __construct()
{
parent::Controller();
$this->ddauthentication = "Authenticated";
}
}
?>
My application controller is defined like this:
class Inquiry extends DD_Controller
{...}
The Inquiry class works fine when I extend Controller, but I get a
Fatal error: Class 'DD_Controller' not
found in
C:\development\localhost\applications\inquiry\controllers\inquiry.php
on line 4
When I extend DD_Controller. In the config file I have the prefix defined as such:
$config['subclass_prefix'] = 'DD_';
Any idea of what I'm missing?
TIA
This is a better approach. Do the following:
Go to the following directory: your_ci_app/application/core/ and create a php file called MY_Controller.php (this file will be where your top parent classes will reside)
Open this the file you just created and add your multiple classes, like so:
class Admin_Parent extends CI_Controller {
public function __construct() {
parent::__construct();
}
public function test() {
var_dump("from Admin_Parent");
}
}
class User_Parent extends CI_Controller {
public function __construct() {
parent::__construct();
}
public function test(){
var_dump("from User_Parent");
}
}
Create your children controllers under this directory your_ci_app/application/controllers/ . I will call it adminchild.php
Open adminchild.php and create your controller code, make sure to extend the name of the parent class, like so:
class Adminchild extends Admin_Parent {
function __construct() {
parent::__construct();
}
function test() {
parent::test();
}
}
DD_Controller.php should be in /system/application/libraries/
If you're using the same CI for multiple apps, and you want them all to be able to extends their controllers to your custom one then you can extend the base Controller class in the same file.
In system/libraries/Controller.php below the Controller class:
class Mega_Controller extends Controller {
function Mega_Controller()
{
parent::Controller();
// anything you want to do in every controller, ye shall perform here.
}
}
Then you'll be able to do this in your app controllers:
class Home extends Mega_Controller {
....
Since the extended controller class you created will be available. I think this is better then overwriting the base controller, but that would work as well.
I recommend to avoid "cracking" CodeIgniter core files.
Better use its native extending possibilities and try to fit into them.
The same rule I would recommend for any PHP library / CMS.
This rule has few reasons:
- ability to quiclky upgrade without takint into account thousands of notes where and how was cracked in core files;
- portability;
- possibility to share your code - eg, this will be usable by both you and your friends in case of need, and it will help them to keep their library up to date, the same as you.
In other words, this is much more professional and it pays to you in the future by usability, portability and by update application possibility.
Regarding your personal question...
As for me, there is nothing bad to create your own library with everything you need to extend native CodeIgniter Controller, then load this library in Controller's constructor and you are done. The only thing to make better usability is to give short name to your library.
This way you can even divide what you need in different pieces and put into separate libraries:
WebFeatures
AdminFeatures
etc.
Then you just load needed libraries in your controller's constructor and you are done.
P.S. I know that proposed way does not fit into "right" OOP concept, but in the same time you must never forget about the integrity of the libraries used.
Everything above is just one more view of mine 7-years experience in professional web development, so I hope it will be helpful if not to follow, then at least to take into account.
Regards,
Anton