I'm ashamed to say that I can't even be compared to a java dev, because I don't even know what MI is
MI = Multiple inheritence.
Antiquated technique, probably over abused when first introduced. When working with OOP and making the analogy to the real world it makes sense as most every living organism on the planet stems from two parents. The problem is, rarely do we model live organisms in software develpment, but instead in-animate objects where the concept of inheritence doesn't really apply. A screw driver doesn't really borrow behavior from a hammer in the real world, but they are both "tools" which share some common funcitonality.
However, when I say "interface," I don't think we're talking about the same thing. Heck, in my current project, I don't even have one interface class--only abstract ones
An interface is not a class. Abstract classes and interfaces have more in common than a class and interface. The difference being an abstract class has an implemention usually.
It appeared to me that interfaces and abstract classes were pretty much the same...just one is more strict than the other. I'm sure I'm wrong on that though, and should look it up.
Similar but key difference -- see above.
As far as the assigning the variables in the abstract/interface class, it just made sense to me. For example, I have a Domain Model object in my current application for a video. There are two different types of video, and they both have the exact same property names, just different property values, and different methods. So, I have them both extend from the same abstract superclass, and in that superclass have all of the protected properties that a video, regardless of the kind, has.
That is the idea, yes.
Your abstract class should basically contain any generic implementation code. Then if nessecary you override the abstract class methods to fine tuning compression, etc. This is the key ieda behind virtual functions and polymorphic programming. It's done for you automagically in PHP but in other languages like C++ it needs to be explicitly declared as such, which is why OOP is usually even more abused in C++ than PHP.
When I think about it, perhaps there are better ways of dealing with this specific problem of having two video types.
I don't understand enough of the problem to say, but I probably wouldn't use two classes unless it's absolutely nessecary. Here is what I would do (do avoid abusing OOP).
I would first implement a base class (not abstract). When I began using conditionals to handle different file types or compression types, etc I would then consider two options:
1. Remove the conditionals from the base class and throw the file type specific implementation into a child class and derive from the abstract base class.
2. Keep the base class as is (not abstract) and use composition and inject the file type specifics into the base class -- this is what I typicall prefer.
This is probably where I'm getting caught the most. I'm most definitely an amateur when it comes to OOP, and I feel that I can only learn by discussing it on here--hence I may come off as very ignorant sometimes But hopefully, with time, I'll get that vocabulary and understanding
I don't think you can ever fully be an expert in programming as the best practices always change. MI for instance was big (and still is in C++ frameworks) and now it's an antiquated practice most OOP developers frown on.
The best way to learn is to ask questions, argue your points the best you can and hopefully receive a logical rebuttle and not some emotional reply about one's fave technqiue. Certainly it has been my conversations with others that have changed my viewpoint, not reading books.
Thanks guys I think it kind of makes sense to me now - it's more of a guarantee that a class will have the required functions more than anything else, if I have understood correctly.
I would say yes, you understand now. Although it's more common to say "contract" than "gaurantee" either works though.
Yeah, I jumped into OOP code, but like others, most of my classes are just a collection of functions (bar the odd few). I'd like to now start exploring the theory behind real OOP principles, hence the looking into design patterns etc.
Good start. Object principles are also a good bet.
http://java.sys-con.com/node/38673
http://www.objectmentor.com/resources/articles/ocp.pdf
http://en.wikipedia.org/wiki/Open/closed_principle
OCP is probably the most important principle to understand when you want to write "real" OO code.
Google Object Oriented Design and Principles. There are several moer principles/best practices which you should learn as well.
I'm having trouble finding somewhere that really shows how OOP code can be used in everyday things, going over the intermediate level stuff.
That is going to be the hard part. The problem is, most articles on OOP are written by complete newbies to it who just want to get attention, so the articles are limiting and usually inaccurate (devarticles, phpbuilder, etc). Then on the other end of things you have people like OO experts who disscuss advanced topics using weird analogies like Ducks and Shapes, which are impossible to relate to real world development when you first start out.
I would say 98% of my code base is pure objects following all best practices that are applicable. Problem is, the objects only make sense in the grand scheme of things and wouldn't serve much purpose on a single object instance, so I can't exactly write an article hilighting best practices.
I have a resultset object which is initialized with a model object which is then injected into a paginator object which is then injected into a layout object which is then initialized with about 15 different objects and altogather generates a HTML display using nothing but objects (other than my template scripts). While it's made a very clean design, alone each object makes very little sense outside of the scope of my application.
You just need to keep reading and trying new things, asking questions, learning and eventually you'll get there.
Cheers
