Abstract / Interface OOP

[Boo-urns]

I've found some good posts here about both, but what I'm not seeing is a reason to use either. Unless there will be multiple developers on the project.

 

What do you use them for?

 

Thanks,

-Corey

[Mchl]

You could say something similar about private/protected/public visibility settings? Why use them in single developer project, if he/she knows what they're supposed to be?

 

There are several answers:

Because it makes you think on your design

Because it helps avoiding silly mistakes

etc...

 

Not to mention that you never know, if there will not be more people working on that code in the future. Why not do it right from the beginning?

 

Interfaces are also important concept when it comes to OOP design patterns. Programming to interface, not to implementation, allows for creation of more versatile code.

 

Having said all that, I must add that I wish I could use those techniques effectively

[flyhoney]

Abstract classes and Interface classes are extremely important.  A very good example are databases.  PHP has the ability to interact with several different databases, MySQL, Postgre, MSSQL to name a few.  If you are designing a database driver for your application and you want it to be portable, an abstract class is the perfect solution.  If you create a database abstract class, you can effectively abstract database methods away from any particular database.  Instead, you would write a driver for each type of database that plugs into the abstract database class.  This way, you can seamlessly move from one database type to another without ever affecting your application.  If you've used an MVC framework you will notice that almost all of them do this, allowing you to use the framework with any type of database.

 

For example, if you are executing a query in mysql you may use mysql_query.  However, in Postgre, you may use pg_execute.  So you would create an abstract Database class with a query() method, and write a separate driver for MySQL and Postgre.

 

*edit *

I originally mixed the two terms up fixed now.

[.josh]

The point of OOP is to give you the ability to make your script modular (so as to make it more portable, easily interfaced with other things, etc..) and to enforce standards (like with interfaces, you can demand that classes under it have certain properties/functions defined, etc...) so that things can be easily added on.

 

That's it.

 

If you are making a program like a CMS or bulletin board system where you expect addons/mods to be made by yourself or others, OOP is a good thing.

 

But if you are scripting something and don't expect it to constantly be a "work in progress" or addons/mods isn't really the nature of the script, then it's not necessary, and in fact, it is more than likely overkill. 

 

It is, of course, a little more complicated than that, because the uses of OOP extend beyond just making addons for a website.  But still.  I see all the time code that's made way more complicated than it needs to be, because sure, it's great that they programmed it that way, but seriously, they will never use it for something else.

 

The main problem with OOP is that people keep saying you can do this or you can do that or it makes this or that possible but the bottom line is whether you really need those options or not.  You just need to decide what your code is going to be used for, and what you realistically think it could be used for. 

[Boo-urns]

Thanks for all the insights guys!! I just started doing OOP programming so its rough and which is why i asked about the abstract and interface. I'm shooting to create classes for everything that will be reused very often in new projects.