All the tutorials I've read don't really explain the need for them, or why they are used... All they appear to do is define the functions methods used in a class - which (so far) doesn't seem to serve a real purpose...
Can anyone enlighten me?
Moderator: General Moderators
Common. I guess it's not really needed but if you don't fully understand OOP all you end up doing is classes as a namespace of sorts or giving procedural code an object wrapper, which isn't bad but it's not fully utilizing objects.Hey all - when I started working with classes I kind of jumped in with the basics, but didn't see the need to go much further
You should probably search the forum as I am sure this has been disscussed before, but...Now I'm looking at design patterns etc, and I'm confused: What is the point in using an interface?
Code: Select all
interface Database_Driver{
function getResults();
function selectAll();
}Code: Select all
class Database_MySQL implements Database_Driver{
function getResults()
{
return 0; // Not implemented yet -- without this definition error would occur
}
}Code: Select all
$dbe = new Database(new Database_Driver_MySQL($conn_params));
$dbe->selectAll();
$res = $dbe->getResults();
// TODO: Iterate results
Code: Select all
interface Iterator extends Traversable
{
function rewind();
function current();
function key();
function next();
function valid();
}
You can define properties in an interface? I've never even tried in PHP but I would consider that a not very good practice as member data is typically more akin to implementation level code, because it's data.a controlled way of accessing the properties and methods in your class. For example, you might make a domain model that has an ID in it. If you need that ID for another layer, you'll keep $id private, but you'll make a public method getID(), that allows the client to get that ID.
Bah you sound like a Java developer using interfaces as an argument for multiple inheritence.At least, that's how I understand an interface at a theoretical level. I don't believe that the "class1 interfaces class2" syntax is all that's too it...it's a whole concept core to encapsulation and other OOP elements.
Probably the biggest change for me was avoiding inheritence at all cost...when I began favouring composition and DI is when my code really cleaned up and a huge difference was noticed.But man, is there more to OOP than that.
Code: Select all
abstract class Video {
protected $duration;
protected $name;
protected $time;
//...getters and setters here
//Varying elements of each concrete class
abstract function encode();
abstract function compress();
}
class AVideo extends Video {
//This class encodes the video as FLV, and gives another method to compress it.
}
class BVideo extends Video {
//This class encodes video as WMA, and gives another method to compress it
}
Code: Select all
function getVideo( Video $video ) {
$video->encode( );//Encodes, no matter what type of video it is.
$video->compress( ); //Compresses, no matter whta type of video it is.
}
getVideo ( new BVideo ); //Encodes and compresses as a WMV
getVideo( new AVideo); //Using the same client for the FLV now. This is the beauty of the interfacing...this function doesn't care whether I use flv or wmv
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 sometimesObject principles like OCP, etc are pretty simple too...in fact any developer who has wrote OO code for any length of time will likely use 99% of those best practices anyways (similar to design patterns). Formalizing your understanding though (and building your vocabulary) is what really makes a difference in understanding your code and code of others.
Cheers
Not entirely true, you could use something along the lines of duck-typing/design by contract and just make every object that implements those methods iterable a´la python.pytrin wrote:This addition to the language was only possible through the use of interfaces
MI = Multiple inheritence.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
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.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
Similar but key difference -- see above.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.
That is the idea, yes.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.
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).When I think about it, perhaps there are better ways of dealing with this specific problem of having two video types.
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.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 would say yes, you understand now. Although it's more common to say "contract" than "gaurantee" either works though.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.
Good start. Object principles are also a good bet.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.
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'm having trouble finding somewhere that really shows how OOP code can be used in everyday things, going over the intermediate level stuff.
Agreed. Although I use interfaces when I know that a functionality will be pluggable/extendable via modules as well. Just as a reminder to make sure methods are implemented.I think designing clear, clean interfaces -- and then programming to them is a key best practice for programmers. In PHP, I think use the interface construct when you actually have a need to enforce an interface upon other programmers.
Yep, if want to enforce a interface, whatever the reason, then that's a way to do it. Different programmers may have different reasons, but the mechanisms are the same.Hockey wrote:Agreed. Although I use interfaces when I know that a functionality will be pluggable/extendable via modules as well. Just as a reminder to make sure methods are implemented.
This is, in my opinion, actually the only "technical" reason to use interfaces in PHP. Enforcing interfaces is a matter of opinion to some extent, because it is about how an error will be discovered and not about functionality. The area where I have seen multiple-inheritance using interfaces actually is with things like Dependency Injection systems where you want to communicate a "type" of class to the system.jshpro2 wrote:You can check which interface a class implements at run time, and treat it differently based on which interface it implements as well ( when using polymorphism.. for example through an exception if your function was passed the wrong object ).. not something that can't be done through regular subclassing but its "cleaner" through an interface
http://us3.php.net/instanceof