Page 1 of 1

My Current OOP Understanding

Posted: Fri Sep 26, 2008 9:43 am
by The_Anomaly
Hey guys,

This probably isn't as advanced as this forum generally asks for, but I really feel like I have to consult with you guys about this topic. My current location is Albania, where every developer I've met lives and swears by procedural coding--and poorly done at that. I've loved the idea of OOP from the beginning, although for a great deal of time I had the totally wrong impression. Initially, all I created was basically a library of functions on steroids (i.e. using very simple inheritance), and then just procedural programming throughout. However, as I started to read more, specifically the wonderful book PHP 5 Objects, Patterns, and Practice by Matt Zandstra, my understanding of OOP and design was totally changed.

Anyway, the reason I talk about my location is that I have no one to bounce my ideas off of. As in, I'm just a beginner in OOP, and just trying to learn the best way of doing things through the books and my own applications. Heck, I've rewritten my current project about six times so far, because I keep realizing that I'm not really doing OOP, but some mutilated combination of procedural programming and inheritance.

So, if you guys will allow me to explain my current understanding of the topic, and how I've applied it on my current project, I'd really appreciate it. I don't want to spend my time here learning a certain way to program, then realize that it's really off the target of true OOP in PHP.

Understanding of OOP in General

The reason OOP is called Object Oriented Programming, is because you create code that resembles in a way objects in real life. As opposed to going through the code linearly, your objects are interacting in a way that makes your application run properly. One of the core concepts of OOP is encapsulation, where you basically try to make each of your classes know as little about the others as possible. For example, when using a Domain Model and Data Mapper in tandem, you want to keep them as ignorant about the other as possible. As in, you could totally change the Domain Model, and only have to change a factory method in the Domain Model for it to work.

Then there are other concepts, such as preferring an interface over an implementation. The most clear example of this is in the use of getters and setters. You code methods that get certain private data, as opposed to just accessing the public variables. Other principles such as abstraction, which force similar classes to conform, are also core to OOP. There are many other such concepts, but I want to get on to my current application to see if I'm applying them right.

Specific Questions

My application, in its most simple form, is basically a video upload and viewing site. I'm not going into the details, and for our purposes here, think of it as a simple youtube rip off (although it's not.). Users upload video, they watch it, they vote on it, and they comment on it. It's basically a Front Controller, with a Domain Model, and Data Mapper used in together, along with a Template View for my view layer. My commands (Upload, Encode, etc) are separate Commands, and are as encapsulated as possible for future usage. I've done my absolute best to not fall into the category of amateurs who use patterns for the heck of it, and I really do think that the above listed patterns are necessary for my situation--despite the simple domain logic it currently has.

The way I have it work is my primary Domain Object is the VideoDomainObject. This object is abstract, and I have two concrete VideoDomainObjects which are PostVideoDomainObject and DBVideoDomainObject. As their names suggest, these both originate from different sources, the former from a user's POST data after inserting a video, and the latter from the database produced by the Data Mapper. The reason I have them both abstract from the same class is that they have the same properties, which are almost exactly mapped to the table that holds the Video. The only difference between the two is that one originates from the Request and is inserted into the database through composition, and the one originates from the database and is then used for viewing the video or manipulating it. Each have different methods, validation, and such. Basically, my question is, did I implement the Domain Model properly in this case? If not, what would you suggest?

The other controversial element of my site is the Registry I have in place. It's basically where I store the data that has to move between all of the different layers. For example, the ID of the video is created from the Auto_Increment in mysql (Data Layer), is a property of the Domain Object (Model Layer), and may be used in my controller in the future.

I could go on and on, but I doubt anyone would read about it all, and those are the two topics I'm most worried about. I'd greatly appreciate it if some of you guys could tell me if I'm doing this right, as I don't want to learn something the wrong way and come off as an idiot later on in life.

Re: My Current OOP Understanding

Posted: Fri Sep 26, 2008 10:59 am
by allspiritseve
The_Anomaly wrote:Heck, I've rewritten my current project about six times so far, because I keep realizing that I'm not really doing OOP, but some mutilated combination of procedural programming and inheritance.
I would concentrate on getting a working project out, before you keep trying to rewrite the project to conform to strict OOP conventions. I'm a big fan of learning by doing, and I think you will learn a lot more if you try to ease into OOP gradually.
The_Anomaly wrote:as encapsulated as possible for future usage.
Don't worry so much about future usage... make it work. If you really want to set yourself up well for the future, learn Test Driven Development. Once you have decent test coverage, try adding some functionality to your site. Generally when you do this, your site isn't very well thought out and you quickly realize that you have problems that need solving. That's when you might go looking for a pattern. Still, only look to solve that one particular problem. Work in increments like this, making small refactoring changes that fix problems that come up. You will learn so much more, and become a much better developer, if you get in the habit of TDD and refactoring.
The_Anomaly wrote:The way I have it work is my primary Domain Object is the VideoDomainObject. This object is abstract, and I have two concrete VideoDomainObjects which are PostVideoDomainObject and DBVideoDomainObject. As their names suggest, these both originate from different sources, the former from a user's POST data after inserting a video, and the latter from the database produced by the Data Mapper. The reason I have them both abstract from the same class is that they have the same properties, which are almost exactly mapped to the table that holds the Video. The only difference between the two is that one originates from the Request and is inserted into the database through composition, and the one originates from the database and is then used for viewing the video or manipulating it. Each have different methods, validation, and such. Basically, my question is, did I implement the Domain Model properly in this case? If not, what would you suggest?
You are over complicating things. Make a Video object, and use it in both contexts. The point of a domain model is to be used by different "sources"... you don't need two objects. As you point out, they have the same properties.

Some will argue me on this, but I don't think the type of validation you're surely using belongs in the domain objects. In my opinion, it belongs in controllers, since it's often context-dependent.
The_Anomaly wrote:The other controversial element of my site is the Registry I have in place. It's basically where I store the data that has to move between all of the different layers. For example, the ID of the video is created from the Auto_Increment in mysql (Data Layer), is a property of the Domain Object (Model Layer), and may be used in my controller in the future.
An id is something that fits well inside a domain object. Not only does it serve as a primary key in the database, but also a unique identifier in the domain (making it a domain concept). A registry should be used after you end up passing too many objects in the parameter that it becomes hard to maintain, and/or you end up passing objects just to pass them on to more objects.