Far better surely to pass them in as parameters rather than relying on global variables? Makes the code a little less portable if you’re going to relay on external variables with specific names. Functions / classes that rely on globals are a pet hate of mine.
The PDO extension, which consists of three OOP classes, is actually well written. There’s no good reason to add another class definition around it. This is just adding unnecessary typing and processing. If you want to do something useful for the PDO extension, extend the PDO class to add a general-purpose prepared/non-prepared query method, that accepts an optional call-time array parameter that causes the method to either use the query method (non-prepared query) or use the prepare/execute methods (prepared query.)
Don’t unconditionally output the raw database error information. This only helps hackers when they internationally trigger errors. You can trigger a connection error by making a large number of requests that consume all the available connections, and a connection error contains the database server host name/ip address, the username, if you are using a password or not, and web server path information. This gives hackers 2/3 or all of the information they need to break into your database on shared web hosting or if remote access is allowed. Instead, in most cases, just let php catch and handle the exception, where php will use it error related settings to control what happens with the actual error information, via an uncaught exception error (database statement errors will get displayed/logged the same as php errors.)
It’s actually dsn (Data Source Name.)
Depending on which tool you used to create the user/password, you also need to assign which databases the user has permission to access and you need to ‘flush’ the privileges to cause them to take effect.
I tried your example. Although the __construct() has one argument, public $pdo, I’m getting this
Fatal error: Uncaught ArgumentCountError: Too few arguments to function Data::__construct(), 0 passed.
I seem to have fixed the problem between Data.php and Config.php. Got rid of __construct(), now I don’t have any warnings or errors in Data.php
In Logic.php I have Data.php which contain the class Data as an include. Data is instantiated.
In Logic.php I have a Logic class. In a Logic method I have:
$registered = $data->FunctionName();
Since I have included the file Data.php which has the instantiated class Data in Logic.php, I should be able to access all Data methods as if they were in Logic.php, so I changed $data to $this. After typing
where FunctionName is a function in in the Data class (Data.php), I get call to undefined method Logic::FunctionName
What am I doing wrong?