PHP OOP - Does this database reading class make sense?

Why don't you split the "constructor" part and the "get the values" part?

Code :

class Database {

    protected $dbh;                 // Database handle connection

    public function __construct( $dbh) {
        $this->dbh          = $dbh;
    }

    public function getResults($columns,$table)
    {
        $resultSet = array();

        $read_database = $this->dbh->query('SELECT ' . implode(',' , $columns) . ' FROM ' . $table);
        while ($row = $read_database->fetch()) {            
            foreach($columns as $column) {
                $resultSet[$column] = $row[$column];
            }
        }
        return $resultSet;
    }
}

Usage :

$db = new Database($dbh);
$db->getResults($columns, $table);

Some time ago, I had the same problem than you, wanting to create an useful and secure database handling class.

In your case, there are some flaws in its design:

1. Constructors are only for initializing class instance, not for doing anything else.
2. Your class is too specific, only allowing to perform one single action, which is not too useful because in that case you'd need X different classes for your X different needs (queries) which is not the goal for a class.
3. Also, as you pointed, there is nothing about security there, which can be very hard to implement if you start to use a model like that in your project (I mean, several changes later in several files, etc...).
4. Your class seems not scalable nor reusable, which will make you work more rather than work less by allowing you to reuse code (which is one of the goals of OO).

So what I'd recommend you to do is the following (now you are on time to do so without side effects in your project, and a class that could be reusable):

1. Create an abstract class for handling a generic database, with configurable parameters, such as host, username, dbname that will be initialized in constructor (in a class you inherit from this one)
2. Create class functions to execute SQL:
   1. Run SQL queries
   2. Prepare prepared statements
   3. Execute prepared statements
   4. Connect/disconnect

Once done that, you have a reusable class for everytime you want to access a database in every project you may have in a future.

After that, just create a new class inheriting from this one (one per database you use (what means in practice one per project you have). This new class should be database specific (having the parameters to connect to database, preparing statements you will need and so on) rather than general, but reusing all its base code.

I have made something similar in the past I posted in my blog (will provide link rather than include it here because it is too long), you are welcome to use it as you like: http://stormbyte.blogspot.com.es/2011/03/mysqls-prepared-statements-made-really.html

If you wan't to write more bug-free, secure and extensible applications with highly reusable code, try to focus more on OOP.

So for example such class as DatabaseRead should always return object (Entity) not array. Why? Bacause you can then do much better validation of its data. So for example it returns instance of class Article. Article has no public properties, only getters and setters. This will grant you, that (if well written) $article->getTitle() will allways return string.

You can then reuse the class Article in administration, so Admin will always create the Article correctly.

You can then use type-hinting through your application as well, which will provide you with certainty, that the parameter which was passed to method is really an Article, not some uknown array (which could be in inconsistent state).

function foo(Article $article) {
   // we are now sure that we work with valid data of article
   $title = $article->getTitle();
}

As a showcase, have a look at this example: https://github.com/Dundee/testing-showcase/blob/master/app/models/ArticleRepositorySqlite.php

This class (ArticleRepository) has one responsibulity (see Single Responsibility Principle): the persistence of an Article. Class Article doesn't know about persitence at all. Bacause of this we can have multiple repository instances, which stores Article on different medium (memory, database, filesystem).

The concrete class ArticleRepositorySqlite uses some DB framework, but this is not always neccessary. The class could take PDO connection in constructor and execute ordinary SQL queries as well.

Hope it's understandable :)