OOP - Database Interface

[benanamen]

Based on what I have learned from this thread this is how I am thinking a database interface should be done. Do I have this right?

 

 

 

[benanamen]

Are my questions getting too advanced for this forum now?

[ginerjm]

Everybody has their own way of connecting to their db. To each his own. If your code makes you happy then it's perfect already!

[benanamen]

To each his own. If your code makes you happy then it's perfect already! 

 

That's your "Expert" advice to someone trying to learn? Why even bother responding with such a worthless post?

Edited January 26, 2017 by benanamen

[Jacques1]

It's difficult to comment on the code at this very early stage.

 

The class structure makes sense: There's an interface and multiple implementations for the different database systems. But the connect() method doesn't do anything. It creates a PDO instance, stores it in a local variable, and then everything is discarded. What did you actually want to do? Put it into an attribute? Return it? Something else?

 

And which features are you planning to implement? Where is this going?

[benanamen]

As mentioned in another thread, all the OOP questions are for learning the proper way to do OOP.  The test project only consists of registration/login/forgot password/password reset functionality so that would tell you what all my questions will relate to. When I post something that doesn't make sense in relation to that functionality it is because that is the best I currently understand to do in OOP so knowing what the "project" consists of should make it easy for someone to guide me and point me in the proper direction.

 

I could read about how to do OOP all day on the net but I don't know enough yet to know if the author knows what they are talking about so I look to the couple experts on this forum that I trust and know have the proper knowledge. When I see certain procedural code I can spot in an instant if the author knows anything. i.e vars in a query, mysql_* functions. In OOP I currently can only spot if they use var or it looks like the class does a lot of things.

 

What did you actually want to do?

 

So to answer your question (which knowing the project should make obvious)

 

1. I want a person to be able to register for the app

2. Validate their email address from a secure token

3. Be able to login and logout

4. Submit a "forgot password" request

5. Reset the password from a token emailed

 

So this deals with a database, authentication, sessions etc, the usual stuff you already know. I have done this hundreds of times in procedural. 

 

For the OOP version, it should be easily scalable to other implementations such as different DB's, different logging mechanisms, etc, etc.

 

What you taught me about interfaces was a HUGE bump in the right direction. I would have been flopping around with abstract classes or something less important if it wasn't for you.

 

 

[benanamen]

The short answer to what I am doing is converting the procedural code from my repo to OOP for the sole purpose of learning advanced OOP. For as much as is possible, I want to write the "perfect app" in OOP.

[Jacques1]

I was talking more about the specific interface and classes above. Right now, there's only one method, and that method doesn't have any effects.

 

So commenting on the code is a bit like having to comment on procedural code that only consists of a few empty functions. What can you say about that?

 

If you fix the connect() method and add at least a few dummy implementations for other methods, I'm sure we can give some feedback. Alternatively, you could do research on common implementations which range from simple utility classes to complex object-relational mappers (Data Mapper, Active Record).

[benanamen]

(Data Mapper, Active Record)

 

Looking into it, that looks like what I needed to know about. I see Active Record is a pattern as well as an Open Source ORM library. Which one are you referring to? Is the pattern something I should learn how to write myself or do I just use the library?

 

This works exactly as expected. Any issues with it? Since this works, why would I need a Data Mapper or Active Record mapper?

<?php
interface Database
{
    public function connect();
}

//----------------------------------------------------------------------------------------
//
//----------------------------------------------------------------------------------------

class Mysql implements Database
{
    public function connect()
    {
    $dsn = DB_TYPE . ":host=" . DB_HOST . ";dbname=" . DB_NAME . ";charset=" . DB_CHARSET;
    $opt = [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
        PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,
        PDO::ATTR_EMULATE_PREPARES => false,
        ];

    return new PDO($dsn, DB_USER, DB_PASSWORD, $opt);
    }
}

//----------------------------------------------------------------------------------------
// Testing
//----------------------------------------------------------------------------------------

$db = new Mysql();
$pdo = $db->connect();

$sql = 'SELECT login_username FROM user_login';
$stmt = $pdo->prepare($sql);

foreach ($pdo->query($sql) as $row)
    {
    echo $row['login_username'];
    }

[Jacques1]

This is more concrete.

 

Unfortunately, you're still thinking purely procedural. Your “class” is just a bloated function: You call connect(), you get back a connection, and that's it. You might as well have written a connectToMySQL() function. There isn't anything resembling OOP.

 

Do you really want to learn OOP? I don't mean this in a hostile way. I'm simply observing that you have not adopted the OO paradigm at all. You're thinking and programming in terms of functions – which is perfectly fine. A lot of great applications are written in procedural code, and a lot of programmers simply aren't interested in OOP. But then you should in fact choose the procedural approach. It doesn't make sense to throw classes and interfaces around when you really just want to write functions.

 

If you do want to learn OOP, you have to be willing (and able) to change your way of thinking. Procedural code is about tasks: You validate the request, you connect to the database system, you send a query etc. OOP is about actors communicating with each other: The request router delegates the request to the controller, the controller validates the input, asks the database object to store the data etc. This is fundamentally different. It's a much more abstract, much more top-down approach to problems. It's not procedural code with some classes.

 

It might actually be a good idea to start with very simple examples before jumping to real code. Yes, it feels silly to write a Person which has an age and a name and can sayHello(). But maybe that teaches you more about OOP than all of the previous threads.

[benanamen]

I think you are not understanding my approach. I know there is much more to be done. I am basically taking this a piece at a time to make sure I am getting that piece correct and trying to avoid information overload. What you see "left over" in procedural is what are the next steps to understand in OOP correctly. For a DB, making a connection is step one. Now obviously I need to learn the proper way to handle CRUD. When I ask you questions, it is not to question what you tell me, it is to understand the "why" and not just to know that's what I should do. e.g I know to turn on a light you flip the switch and the light comes on, but I want to know "why" it does. You can't really be a Master of something if you don't know it inside and out.

 

It's not procedural code with some classes.

 

That is not my intent despite what the readme on my repo says. There is a particular reason it was worded like that. My intent is to re-write that project in complete, optimum OOP best practices. I have read numerous car, bicycle, animal, and people OOP tutorials and am familiar with what they all said. How much is correct or could be better, I have no idea as of now.

 

So, you know my project, you know what my intent is, and you can see the code at my repo that I am transforming to OOP. If you're willing, that should make it easy to guide me, I am more than willing to put in the time to learn and understand what you tell me. So, yes, I do want to learn OOP, but I want to learn it correctly from the start.

 

Moving forward, it seems my next steps are to do something with the CRUD operations. And yes, I have read many a code that others have done which just appears they are probably doing it wrong since none of them do it near the same way.

 

My question is, would the CRUD operation for a particular DB type (e.g Mysql) go in the class that implements the connection or is there some super crud class design that any type of db can use?

 

Additionally, since you could be using two DB's at once (Mysql & MongDB), how should the actual credentials be set up?

 

Thanks to all who help!

[Jacques1]

I understand your approach, I understand this is all work in progress, I understand you have legacy code. Nothing wrong with that. I'm a programmer myself, so I'm aware that projects take time. By the way, it's perfectly fine to embed OO components into procedural code, because the programming paradigms are not mutually exclusive.

 

What I fail to see is the OO part. So far, your objects are just containers for functions. They have no attributes to hold their state, they have no task which they take care of autonomously.

 

See what I mean? That's why I suggested a few design patterns as a starting point. If you want to implement your own CRUD operations with your database classes, that's also fine. But you should at some point make the transition from function containers to actual objects.

[benanamen]

What I fail to see is the OO part. So far, your objects are just containers for functions. They have no attributes to hold their state, they have no task which they take care of autonomously.

 

If you don't see it, it is because I don't know to do it, otherwise it would be there. So perhaps that is actually the next part I need to learn about. I don't know about attributes holding state in OOP. I don't know about autonomously taking care of tasks in OOP. What can you tell me about that in a way I can understand?

 

At this point, I don't know enough to make decisions of how I would personally want to implement anything in OOP. I am looking for the definitive way to do things for as much as that is possible. One of the things I don't like about Php is there is just way too many ways to do the same exact thing. One of the things I liked about implementing interfaces is it is definitive in that if you don't use the methods, it doesn't work. It is a strict rule.

[Jacques1]

You should forget about the “perfect way”. That's really not the issue right now. I think a more realistic goal is to get a basic understanding of OOP and write simple dummy classes just for the sake of learning.

 

If you don't know how attributes work, you should start with that. Start with the basics before jumping to advanced topics. For example, if you write a proper File class which can read() and write(), that would be infinitely more useful for this discussion than all the fancy interfaces and design patterns.

 

In any case, there will always be multiple approaches. OOP is still programming, so it's still a matter of experience, creativity and personal preferences. There is no simple ruleset.