PHP OOP: how to use a generic MySQL class in other classes?

For one, you don't need to use singleton in this case - or actually, you almost never do. See this article for example.

For one, you don't need to use singleton in this case - or actually, you almost never do. See this article, for example. Second, I think your OO designs are a bit off.

The main point of object-oriented programming and design is to isolate responsibility into separate classes. Right now, you're giving your User class two main responsibilities - store / carry one user's relevant data, and query the data service (in this case, a simple MySQL / database abstraction layer). You should first move that functionality into a separate object.

Usually, this is called a Service - so in this case, it's a UserService. A UserService has one responsibility: provide access to User objects. So it'd sorta look like this: class UserService { public function __construct($mysql); // uses the mysql object to access the db.

Public function get($id) { $result = $this->mysql->get_record("select x from y"); $user = new User($result'id', $result'name'); // assuming user has a constructor that takes an id and a name return $user; } public function save($user); public function delete($user); } You tie it all together at the start of your request (or where you need to access users): $mysql = new MySQL($credentials); $service = new UserService($mysql); $user = $service->find(1337); It's not perfect, but it's a much neater design. Your MySQL object does what it needs to do (build a connection, execute queries), your user object is plain dumb, and your service does only one thing, i.e. Provide a layer between the actual storage layer and the thing calling it.

1 This is a great design! User objects should have one responsibility, to hold user data. – Jon Snyder Jan 7 at 16:27.

You should pass in the mysql object to each user object. So it would look like this: $mysql = new mysql(); $user = new user( $mysql, $id); $name = $user->get_username(); class user { public function __construct($mysql, $id) { $this->mysql = $mysql; $this->id = $id; } public function get_username() { $username = $this->mysql->get_record("SELECT name FROM users WHERE id = '". $this->id."'"); return $username; } }.

Design your mysql class to be called statically: $username = Mysql::get_record("SELECT name FROM users WHERE id = '". $this->id. "'"); php.net/manual/en/language.oop5.static.php.

I'd rather call it Mysql::get_record("SELECT name FROM users WHERE id = %d",$this->id); – Col. Shrapnel Jan 6 at 19:23 There are definitely many improvements the OP can make. My answer deals with the narrow question of avoiding incessant instantiation.

– webbiedave Jan 6 at 19:38.

This is a common problem, and so there is a common solution to this. As you might know, in software development common solutions on common problems are called Design Patterns. There are two design patterns that can help you solve this problem.In a more abstract sense the problem you are facing is: How can I make class A available in class B?

The Singleton pattern "In the singleton pattern a class can distribute one instance of itself to other classes. " This is not exactly what you are looking for, as your website may use multiple database connections. However, it is used by a lot of people in this way.

Read some information about using a singleton class as a database provider here: https://ibm.com/developerworks/library/os-php-de... More information on the singleton pattern in PHP: fluffycat.com/PHP-Design-Patterns/Single... Another sensible approach is the registry pattern: Registry Pattern You can find information about the registry pattern on the link below, as well as an implementation almost identical that you are looking for: sitecrafting.com/blog/php-patterns-part/ Even more powerful is a combination between the singleton and the registry. Good luck and enjoy learning OOP PHP!

1 Actually, the singleton pattern is, in this particular case, not really needed - after all, anything that doesn't do anything with a database connection doesn't need to have access to that class, and by using singleton, your whole application gets access to singleton. Same goes for registry, although it's a slightly better alternative. No, I'd say that a database interaction object is a service, and services can be assigned to objects that need them, for example by using the dependency injection pattern.

See: martinfowler. Com/articles/injection. Html – fwielstra Jan 6 at 19:45 @Cthulhu - You're comment about using the singleton pattern is not needed for this problem is correct, however it is a common used solution to this specific problem.

Personally, I am not very familiar with dependency injection, but thank you for pointing it out. Will look into it. – Richard Tuin Jan 6 at 20:31 1 +1 for dependency injection... it makes unit testing so much easier if you don't have globals all over the place, instead injecting what you need into your class.

And yes, both registry and singleton are globals too... just more disguised. – kander Jan 6 at 21:22 A singleton is just a global variable in disguise. Do not teach new programmers to use bad practices.

– Jon Snyder Jan 6 at 16:25.

Using global variables, although that is probably not the best option. $mysql = new mysql(); function someFunction() { global $mysql; $mysql->get_record(...) } or a static method for your mysql class (see Singleton) class mysql { public static $theInstance = new mysql(); public static function getInstance() { return $this->theInstance; } } function someFunction() { $database= mysql::getInstance(); $database->get_record(...) }.

3 Uh, please don't suggest to use globales! – Felix Kling Jan 6 at 19:22.

Start to think to use Doctrine, it's better doctrine.org.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.