In response to George:
To be honest I don't know why you would want something more advanced than this at your stage in OOP. The tutorial is not entirely up-to-date, but it's still useful for learning the principles and logic behind the MVC framework.
Does this mean you think I'm ready to try out using MVC on a project? What about the URL redirection stuff where you make it so you can load a controller and method and what not just by typing everything into the URL. I don't totally get that yet. I wasn't sure what to study that was MVC related, so I spent the last few days focusing on OO PHP in general. Is it necessary that I use the URL thing?
I personally like the codeigniter framework; it may be worth a consideration. There's much documentation on their page found here: http://codeigniter.com/user_guide/
Going by the bullet list that points out its positive traits, it sounds nice. I bookmarked the page so I can return at a later time.
I still claim that learning OOP is better done without a framework
I've heard this a lot, and I never questioned it because its been spoken by people far better at programming than me. I assume that one doesn't write classes when they use a framework, so I can see why I would learn less about OOP, but what I'm wondering about is something else. Is a developer who can both use a framework and develop OOP applications from scratch worth more than one who can just do one or the other? Why or why not?
Out of interest, what sort of level do you actually consider yourself to be at when it comes to objects and classes?
Well, I'm not clueless but I'm still a beginner. I'm much more comfortable with procedural PHP, but I want to leave that behind. I get some basic concepts (like inheritance) and I know how to use some features (like abstract classes). I'm not good enough, though, to actually make anything useful. I can't make a login script, or a database script, or anything else a site would actually need.
Can you articulate your level of comprehension?
Hmm. You want me to verbalize what I think I know? Well, I get that OOP makes it easier for multiple coders to work on the same project, because the client coders only need to learn the interface and that's never as complicated as the implementation. I'm guessing the implementation is the whole of what is contained in the classes and the interface is whatever has been made public.
I can sort of see how bugs are less likely with OOP than procedural programming. For one, the client coders can only change what the interface lets them change, so they are less likely to mess something up. For two, code inside a class is isolated from code elsewhere in the application, especially if it's private or protected. I'm guessing this lessens the likelihood of unfavorable interactions.
I can see how OOP could make web application development a lot faster than just procedural programming. Writing the classes is a big time investment up front but if they are generic enough then they could work on a lot of sites, regardless of database used, login information required, or what have you, because the objects derrived from them can be customized to fit the needs of the particular site. I guess if you don't use a framework, then you make your own.
In response to NogDog:
But there's no real reason you have to take this "big bang" approach to learning OOP. If you keep in mind the ideas of reusability and compartmentalization when creating classes for specific, limited purposes, you should find it easy to integrate them into a larger system (MVC or not) as and when you get to that point.
So you think I should take my limited knowledge and get a site working in whatever way I can manage?