My Current OOP Understanding
Posted: Fri Sep 26, 2008 9:43 am
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.
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.