In OOP, sometimes you see something similar to this:
$memberID = $system->members->memberID();
I was wondering and totally confused on the part where it is ->members->... How does that work?
For example, lets say I have a class that I call up called $systems, then how can I put ->members-> after it to run the members class?
I only know how to do something along the lines of this:
$system = new system();
$memberID = $system->memberID();
But I would like to know how to do this:
$system = new system();
$memberID = $system->members->memberID();
Thanks!
-- UPDATE --
Here's a little update, thanks to everyone who helped me out this far! You guys really pointed me in the right direction, I actually have a great answer to my own question! :) And thanks to the moderator who edited this question, I'm sorry I wasn't familiar with the bbcode syntax.
I wanted something to automatically make the new classes, for example calling ->members-> would be automatically included using __get() rather then having to do manually put in something like "new members()". A little difficult for me to explain, but I hope you got the basics of it.
Anyhow, here is the code that I use:
<? class system {
public function __get($name){
$file = 'lib/'.$name;
if(file_exists($file)){
require_once($file);
$classname = $name;
$this->$name = new $classname($this);
return $this->$name;
}else{
die('Class '.$name.' could not be loaded (tried to load class-file '.$file.')');
}
}
} ?>
Now, if I were to do something the lines of this:
$system = new system();
$system->members->functionHere();
It would automatically create a new instance of the members class and require the file from the lib folder.
If this is against the rules then I apologize. I just wanted to post this for anyone who came across this question while searching Google, because I know I always land up here when googling things!
the $system variable holds an object which has a property named $members which itself holds an object which has a property $memberID
$system = new system();
$system->members = new Members(); // or whatever it must be
$system->members->memberId();
When you see something like that, you know that someone has most probably done something wrong!
In order for this code to work, you need to grant public access to a member variable of an object (the former storing an object).
To grant public access to such a member variable is in most cases bad practice. The variable should only be accessible through a getter (at least, it will still violate the LoD).
This code breaks the principle of encapsulation and the LoD (Law of Demeter).
[EDIT]
Why it is almost certainly a mistake:
A) Granting direct public access to member variables is in most cases a mistake, because it makes the public interface of your class rigid (hard to change). If you have a getter, you can change the implementation of the member anytime, the getter will still be the same and you don't need to change the call from anywhere. You can NEVER write a proxy for direct access to a variable! Writing a proxy for a getter on the other hand is easy!
B) Granting direct public access to member variables is in most cases a mistake, because you let everyone talk to a class inside a class directly! This will most probably lead to higher maintainance costs when the public interface of any of these two classes changes.
[/EDIT]
members is object property of system and is also an object that contains method memberID().
To assign property to your object, simply do something like this:
class System {
function __construct() {
$this->members = new Members();
}
// etc
}
or
$systemObj = new System();
$systemObj->members = new Members();
It really really depends on the context you wish to use :)
As #markus mentioned, properties must be declared public if you're accessing them from outside. Also, using setters/getters is often much better ...
Related
Let' suppose I have my code organized in classes and each class has its own file:
main.php, having class Main
config.php having class Config
security.php having class Security
database.php having class Database
Now, Main's constructor will initialize 3 objects, one for each of the other classes, and this way everything will look more or less like a class/subclass. The problem is that now Security might need something (a variable or function) from Config and Database something from Security.
// main.php
// here I include the other files
class Main {
functions __constructor() {
$this->Config = new Config();
$this->Security = new Security();
$this->Database = new Database();
}
}
// config.php
class Config {
public $MyPassword = '123456';
public $LogFile = 'logs.txt';
// other variables and functions
}
// security.php
class Security {
functions __constructor() {
// NOW, HERE I NEED Config->Password
}
function log_error($error) {
// HERE I NEED Config->LogFile
}
}
// database.php
class Database {
functions __constructor() {
// Trying to connect to the database
if (failed) {
// HERE I NEED TO CALL Security->log_error('Connection failed');
}
}
}
So, how do I share those functions and variables between these nested classes inside Main? Of course, I could send those variables as arguments to the constructors but what happens when we need like 5 or 10 of them? I could send the entire object Config to Security and Security to Database,
// main.php
// here I include the other files
class Main {
functions __constructor() {
$this->Config = new Config();
$this->Security = new Security($this->Config);
$this->Database = new Database($this->Security);
}
}
but is that reliable? Can I send only the reference (like a pointer, in C++)? Maybe I can send the hole Main object's reference as an argument in the constructor, and this way make everything available for everything.
// main.php
// here I include the other files
class Main {
functions __constructor() {
$this->Config = new Config();
$this->Security = new Security(&$this);
$this->Database = new Database(&$this);
}
}
I don't even know if this is possible.
What do you think? Are there any more conventional ways?
As it is stated in comments you are starting to think in terms alined with Dependency Injection. You are defensively coding (and rightly so) to workaround the issue of SoC (Separation of Concerns). You might try like I did with something I call the Registry pattern (I'm ignorant on the subject so I named it after the windows registry). The registry holds all the objects that may need to be passed around. This gives some benefits on a practical level
If I'm not sure something else is going to need a var, I just tack it into the registry and the one which depends will know where to look for it, as long as I pass him the Registry
If my project is very small and I don't want to hassle around to much about the idea then this is an easy solution
There are quite a set of problems behind this pattern of thinking. Say the project starts to get bigger, I know it happens to me sometimes. Now simple tasks like debugging become mountain climbing as I try to find why a dependancy is not where I'm looking for it and I have to track down where it is set and at what point, and if some other piece of code changed it and why.
All this means is that instead of following the principles of SoC, we just passed the concern onto a third object that now bears ALL the responsibility. This "registry" object is now responsible for too many things and any changes that happen to it will ripple through all your code.
From what I've read around SO and other tutorials, if you have an object that is juggling too many dependancies (let's say constructor with 10 parameters) then we are probably not doing things right.
I hope someone else can chime in on this because I'm very interested on this subject but I have not been able to put it in practice (mainly due to ignorance)
I have recently been working on a project that was thrown upon me at work after another developer left (he was the only one working on it prior to leaving). The project was written in CodeIgniter and uses the MVC framework. While working on the project I noticed something funny or at least something I have not seen before.
After the model is loaded into the controller the object is passed into the view using...
$data['outcomes'] = $this->id_conversion;
With id_conversion being the model that was loaded in at the top of the controller. My question is is this any different then using
new Id_conversion();
in place of the above.
Thanks for any help or anyone able to point me in the correct direction.
Edit. Sorry after reading the comments I see that I need more of my code for this to make sense.
public function person($id)
{
$this->authenticate->check_access(array('admin', 'rps'), 'home');
$this->load->library('page_uri');
$this->load->model('term');
$this->load->model('user');
$this->load->model('id_conversion');
$selected_term = $this->page_uri->get_term();
$current_term = $this->term->current_term_id();
if (!isset($selected_term)) {
$selected_term = $current_term;
}
$term = new Term();
if (!empty($selected_term) && $selected_term !== '0') {
$term = new Term($selected_term);
}
$user = new User($id);
$plans = $user->plans_by_term($term);
$data = array();
$data['user'] = $user;
$data['site_url'] = site_url("reports/person");
$data['current_term'] = $this->term->current_term_id();
$data['selected_term'] = $selected_term;
$data['terms'] = $this->term->sorted_term_list();
$data['term'] = $selected_term;
$data['plans'] = $plans;
$data['outcomes'] = $this->id_conversion;
$this->load->view('template/foundation', $data);
}
the model id_conversion loads in
class Id_conversion extends MY_Model{
function __construct()
{
parent::__construct();
}
/*
* Input a primary or secondary outcome as defined
* in the plan class and
*/
public function id_outcomes($id)
{
$sql = 'SELECT name
FROM outcomes
WHERE id ='. $id;
$query = $this->db->query($sql);
return $query->row_array();
}
}
Using new will create a new object.
Using $this->id_conversion will use the existing object that was already created at some point previously and which was stored in that variable.
Without seeing more of your code, it's utterly impossible to know what state the existing object is in, so I can't tell you what difference it will make to create a new one compared with using the existing one. I would imagine there's a good reason for the program to have already created the object and stored it for you, so I guess it's been set up ready for use, but I can't tell for sure from what you've given us.
But even in the case that the existing object is in an entirely pristine condition and creating a new one would give identical functionality, you'd be wasting system resources in creating an extra object when one already exists. Only a small amount of wastage, to be sure, but it all adds up.
It's probably going to give the same results but not certainly.
If $this->id_conversion is a reference to a model class, that class may have been initialized in a different way. In Codeigniter, you can initialize an instance of a model like this:
$this->load->model('model_name', 'alias_name', $db_params);
If the class Id_conversion doesn't exist and id_conversion is actually an alias, then of course that wouldn't work.
If $db_params are different, then this is much different than just saying new Id_conversion();. Note also that the () are not needed if you aren't passing anything to the constructor. And as mentioned, it creates another unnecessary instance of the class.
And of course, if the state of $this->id_conversion has changed at all, for example:
$this->id_conversion->property = 'value';
...then it will not be the same at all.
Note that $this->id_conversion will be available in the view as well, so while it's probably good practice to explicitly pass it to the view, it isn't strictly necessary. The view runs in the same scope from the controller method that it was called in.
Better to stick to the Codeigniter way unless you are sure you know what you are doing.
I know there are loads of questions on this, I have done quite a bit of reading. I'd like to ask this in context of my project to see what suggestions you may have.
I have quite a large web application with many classes, e.g. users and articles (which i consider to be the main classes) and smaller classes such as images and comments. Now on a page, lets say for example an article, it could contain many instances of images and comments. Makes sense right? Now on say an articles page I call a static method which returns an array of article objects.
That's the background, so here are the questions.
Since building a large amount of the app I came to realise it would be very useful to have a core system class containing settings and shared functions. There for I extended all of my classes with a new core class. Seemed relatively simple and quick to implement. I know CodeIgniter does something similar. I feel now though my app is becoming a bit messy.
Question Is this a good idea? Creating an instance of core is exactly what I want when calling an instance of an article, but what about when i'm creating multiple instances using the static method, or calling multiple images or comments on a page. I'm calling the core class unnecessarily right? Really it only needs to be called once per page (for example the constructor defines various settings from the database, I don't want to this every time, only once per page obviously), but all instances of all classes should have access to that core class. Sounds exactly like I want the singleton approach, but I know that's a waste of time in PHP.
Here's an idea of what my code looks like at this point. I've tried to keep it as simple as I can.
class core {
public function __construct(){
...define some settings which are retrieve from the database
}
public function usefulFunction(){
}
}
class user extends core {
public function __construct(){
parent::__construct();
}
public function getUser($user_id){
$db = new database();
$user = /* Get user in assoc array from db */
$this->__setAll($user);
}
public static function getUsers(){
$db = new database();
$users = /* Get users from database in assoc array from db */
foreach($users as $user) {
$arrUsers[] = new self();
$arrUsers[]->__setAll($user);
}
return $arrUsers;
}
private function __setAll($attributes) {
foreach($attributes as $key => $value)
{
$this->__set($key, $value);
}
}
public function __set($key, $value) {
$this->$key = $value;
}
}
The other issue I'm having is efficiently using/sharing a database connection. Currently each method in a class requiring a database connection creates a new instance of the database, so on a page I might be doing this 5 or 10 times. Something like the dependency injection principle sounds much better.
Question Now if i'm passing the instance of the DB into the new user class, i know I need something like this...
class user{
protected $db;
public function __construct($db){
$this->db = $db;
}
... etc
}
$db = new database();
$user = new user($db);
... but when I want to run the static function users::getUsers() what is the best way to gain access to the database instance? Do i need to pass it as a variable in each static method? (there are many static methods in many classes). It doesn't seem like the best way of doing it but maybe there isn't another way.
Question If extending all of my classes off the core class as suggested in part 1, can I create an instance of the DB there and access that some how?
Question I also have various files containing functions (not oop) which are like helper files. What's the best way for these to access the database? Again i've been creating a new instance in each function. I don't really want to pass the db as a parameter to each one. Should I use globals, turn these helper files into classes and use dependency injection or something different all together?
I know there is lots of advice out there, but most info and tutorials on PHP are out of date and don't ever seem to cover something this complex...if you can call it complex?
Any suggestions on how to best layout my class structure. I know this seems like a lot, but surely this is something most developers face everyday. If you need any more info just let me know and thanks for reading!
You asked in a comment that I should elaborate why it is a bad idea. I'd like to highlight the following to answer that:
Ask yourself if you really need it.
Do design decisions for a need, not just because you can do it. In your case ask yourself if you need a core class. As you already have been asked this in comments you wrote that you actually do not really need it so the answer is clear: It is bad to do so because it is not needed and for not needing something it introduces a lot of side-effects.
Because of these side-effects you don't want to do that. So from zero to hero, let's do the following evolution:
You have two parts of code / functionality. The one part that does change, and the other part that is some basic functionality (framework, library) that does not change. You now need to bring them both together. Let's simplify this even and reduce the frame to a single function:
function usefulFunction($with, $four, $useful, $parameters)
{
...
}
And let's reduce the second part of your application - the part that changes - to the single User class:
class User extends DatabaseObject
{
...
}
I already introduced one small but important change here: The User class does not extend from Core any longer but from DatabaseObject because if I read your code right it's functionality is to represents a row from a database table, probably namely the user table.
I made this change already because there is a very important rule. Whenver you name something in your code, for example a class, use a speaking, a good name. A name is to name something. The name Core says absolutely nothing other that you think it's important or general or basic or deep-inside, or that it's molten iron. No clue. So even if you are naming for design, choose a good name. I thought, DatabaseObject and that was only a very quick decision not knowing your code even, so I'm pretty sure you know the real name of that class and it's also your duty do give it the real name. It deserves one, be generous.
But let's leave this detail aside, as it's only a detail and not that much connected to your general problem you'd like to solve. Let's say the bad name is a symptom and not the cause. We play Dr. House now and catalog the symptoms but just to find the cause.
Symptoms found so far:
Superfluous code (writing a class even it's not needed)
Bad naming
May we diagnose: Disorientation? :)
So to escape from that, always do what is needed and choose simple tools to write your code. For example, the easiest way to provide the common functions (your framework) is as easy as making use of the include command:
include 'my-framework.php';
usefuleFunction('this', 'time', 'really', 'useful');
This very simple tow-line script demonstrates: One part in your application takes care of providing needed functions (also called loading), and the other part(s) are using those (that is just program code as we know it from day one, right?).
How does this map/scale to some more object oriented example where maybe the User object extends? Exactly the same:
include 'my-framework.php';
$user = $services->store->findUserByID($_GET['id']);
The difference here is just that inside my-framework.php more is loaded, so that the commonly changing parts can make use of the things that don't change. Which could be for example providing a global variable that represents a Service Locator (here $services) or providing auto-loading.
The more simple you will keep this, the better you will progress and then finally you will be faced with real decisions to be made. And with those decisions you will more directly see what makes a difference.
If you want some more discussion / guidance for the "database class" please consider to take a read of the very good chapter about the different ways how to handle these in the book Patterns of Enterprise Application Architecture which somewhat is a long title, but it has a chapter that very good discusses the topic and allows you to choose a fitting pattern on how to access your database quite easily. If you keep things easy from the beginning, you not only progress faster but you are also much easier able to change them later.
However if you start with some complex system with extending from base-classes (that might even do multiple things at once), things are not that easily change-able from the beginning which will make you stick to such a decision much longer as you want to then.
You can start with an abstract class that handles all of your Database queries, and then constructs them into objects. It'll be easy to set yourself up with parameterized queries this way, and it will standardize how you interact with your database. It'll also make adding new object models a piece of cake.
http://php.net/manual/en/language.oop5.abstract.php
abstract class DB
{
abstract protected function table();
abstract protected function fields();
abstract protected function keys();
public function find()
{
//maybe write yourself a parameterized method that all objects will use...
global $db; //this would be the database connection that you set up elsewhere.
//query, and then pack up as an object
}
public function save()
{
}
public function destroy()
{
}
}
class User extends DB
{
protected function table()
{
//table name
}
protected function fields()
{
//table fields here
}
protected function keys()
{
//table key(s) here
}
//reusable pattern for parameterized queries
public static function get_user( $id )
{
$factory = new User;
$params = array( '=' => array( 'id' => $id ) );
$query = $factory->find( $params );
//return the object
}
}
You'll want to do your database connection from a common configuration file, and just leave it as a global variable for this pattern.
Obviously this is just scratching the surface, but hopefully it gives you some ideas.
Summarize all answers:
Do not use single "God" class for core.
It's better to use list of classes that make their jobs. Create as many class as you need. Each class should be responsible for single job.
Do not use singletones, it's old technique, that is not flexible, use dependecy injection container (DIC) instead.
First, the the best thing to do would be to use Singleton Pattern to get database instance.
class Db{
protected $_db;
private function __construct() {
$this->_db = new Database();
}
public static function getInstance() {
if (!isset(self::$_db)) {
self::$_db = new self();
}
return self::$_db;
}
}
Now you can use it like db::getInstance(); anywhere.
Secondly, you are trying to invent bicycle called Active Record pattern, in function __setAll($attributes).
In third, why do you wrote this thing in class that extends Core?
public function __construct(){
parent::__construct();
}
Finally, class names should be capitalized.
I am working on a website with php/mysql.
I have 3 files config.php, utils.php and member.php. code of the files are as below,
config.php - $objPath->docrootlibs is fine, I am sure there is no problem with this.
/* Other library files & their object */
require($objPath->docrootlibs.'/utils.php');
$objUtils = new utils();
require($objPath->docrootlibs.'/member.php');
$objMember = new member();
utils.php
class utils{
function getCurrentDateTimeForMySQL(){
return date("Y-m-d H:i:s");
}
}
members.php
class member{
var $userid;
var $username;
function __construct(){
$this->lastactivity = $objUtils->getCurrentDateTimeForMySQL();
}
}
Now when I am including the config.php inside a page home.php with simple php include statement and running that page then it gives me following error.
Notice: Undefined variable: objUtils in D:\wamp\www\site\libs\member.php on line 17
Fatal error: Call to a member function getCurrentDateTimeForMySQL() on a non-object in D:\wamp\www\site\libs\member.php on line 17
Line numbers in error above are different, I just copied the specific part from the code here.
I am not understanding why its giving error, because objects of utils class is defined on config page before including the member class. It should detect that object.
Please check and help me to understand and correct this error.
Thanks!
One Solution
Unlike JavaScript PHP will not bubble up through scopes, which means
public function __construct(){
$this->lastactivity = $objUtils->getCurrentDateTimeForMySQL();
}
does not know what $objUtils is, because there is no such object defined in the local scope. This means, you have to make the object available inside that scope. The cleanest and most maintainable way to do that is to inject the utils instance to the member instance, e.g.
public function __construct($utils){
$this->lastactivity = $utils->getCurrentDateTimeForMySQL();
}
However, since you seem to be using that value on construction only anyway, there is no reason why your member instance has to know how to use the utils object. So why not just insert the actual value right from the start, e.g.
public function __construct($lastActivity){
$this->lastactivity = $lastActivity;
}
// then do
$utils = new utils();
$member = new member($utils->getCurrentDateTimeForMySQL());
On globals
You definitely do not want to use the global keyword or static methods. Both couple back to the global scope. This means you can no longer use the member class without the global scope. This makes maintaining, reusing, refactoring and testing harder. OOP is about encapsulation and by reaching out from the class to the global scope you are breaking that encapsulation. Use Dependency Injection as shown above instead.
Apart from that, using globals will also make your code harder to read. A developer looking at the ctor signature of member is likely to assume there is nothing else to do than just call new member. That's a lie, because she also has to setup the utils instance. In other words, you are hiding dependencies. The developer has to look at the actual code to understand what's going on. Thus, make dependencies explicit.
Some more resources:
http://c2.com/cgi/wiki?GlobalVariablesAreBad
http://misko.hevery.com/code-reviewers-guide/flaw-brittle-global-state-singletons/
EDITs after comments
If you really need that utils object, inject the instance and assign it to a property inside the member instance in the ctor. Then you can access it with $this->utils->foo() from anywhere else inside the member instance.
However, Utility classes are almost always a sign of bad design. It is much more likely that they should be broken apart and divided into/onto other objects. Try to find out the reponsibilities. Maybe Member should not use Utils, but Utils should be something else that uses Members.
Out of curiosity, why do you need a utility method for MySql anyway? If you use a Timestamp column in MySql for lastActivity, it will automatically update whenever the row is updated. I am assuming you are setting the lastActivity and then store the member data?
Regarding performance: you should not bother about performance. Write readable and maintainable code first and foremost. If you think your performance is not good enough, profile the application with XDebug to see what is really making an impact.
As another comment states, use dependency injection. Insert the utilities object into the constructor. Do not introduce variables over the global scope, especially between different files. This gets very confusing and creates a mandatory order of some file includes.
class member {
...
public function __construct(utils $objUtils) {
$this->objUtils = $objUtils;
...
}
}
In calling code:
$member = new member(new utils);
As an aside, I find it humorous that you have a macro with a name that is longer than the operation it performs.
As another aside, do you need a utilities class? Can the utilities just be functions?
It sounds like config.php is in the global scope. You need to use the global keyword when using $objUtils
function __construct(){
global $objUtils;
$this->lastactivity = $objUtils->getCurrentDateTimeForMySQL();
}
Since your getCurrentDateForMySQL doesn't depend on anything else inside your utils object, why not make it a static function? That way you can turn your member() method into:
function __construct(){
$this->lastactivity = utils::getCurrentDateTimeForMySQL();
}
I have a class that I am using all over the place in my code. It contains settings and other core functionality. Here's what I'm doing right now to use the class.
$settings = new Settings();
$settings->loadSettings();
Then, when I need to the code in some random function in another class, I do something like this:
function abc() {
global $settings;
$variable = $settings->a;
}
I'm sick and tired of randomly calling global $settings all over the place to pull in that settings object. I don't want to use the $_GLOBALS array (I don't know why, I just don't want to).
I'm thinking I want to switch to have a static class variable called $settings inside of settings. The code would look like this:
Settings::$settings = new Settings();
Settings::$settings->loadSettings();
Then, whenever I want to use it, I never have to worry about sucking it in via the global operator:
function abc() {
$variable = Settings::$settings->a;
}
Good idea or bad idea?
Well it's probably an improvement on globals, because it solves all the ugly scoping issues that globals cause. Getting rid of the global operator is generally a good thing! What you are doing is not dissimilar to the singleton pattern, though it's considerably simpler. (See the "Singleton" section at http://php.net/manual/en/language.oop5.patterns.php for more information on the pattern.) Your solution is almost certainly fine for your purposes.
On the other hand, there may be better ways of achieving the same thing that decouple your code more. That is to say, each class becomes more capable of being used in another project without significant recoding. One way to do this would be to "inject" the settings object into each class:
class ABC {
private $settings;
public function __construct($settings) {
$this->settings = $settings;
}
public function someMethod() {
$variable = $this->settings->a;
}
}
This would be more work, but may improve the re-usability of your code. You could then, for example, write a different settings class for every project but use the same ABC class.
This process, where you "inject" an object into another object that depends on it, is called dependency injection. There are other, more complex ways of doing this, including complex containers. See http://fabien.potencier.org/article/11/what-is-dependency-injection for an interesting set of tutorials on the subject. They're probably incidental to your current needs, but may help either now or in the future.
It seems you are looking for a Singleton. Basically the idea is to have a class which has a public static method getInstance() which returns an instance of the class itself. The first time you call the method, it stores the instance in a private property, and all later time it returns the stored instance. In this way, whenever you call Settings::getInstance(), you are guaranteed to have a copy of the same object. Then you can store settings in this object.