Skip to main content ↑ ↓
interface VS abstract Started by emanuele · · Read 3789 times 0 Members and 1 Guest are viewing this topic. previous topic - next topic

interface VS abstract

I'm sure I asked it somewhere, but most likely was on IRC or on gtalk, so I'll post it here just in case.

Code: [Select]
/**
 * Database driver interface
 */
interface Database
{

Code: [Select]
/**
 * This is used to create a table without worrying about schema compatabilities
 * across supported database systems.
 */
abstract class DbTable
{

Code: [Select]
/**
 * Interface methods for database searches
 */
interface DbSearch
{

I like consistency, so 2 interfaces and one abstract class doesn't sound right to me.

On your opinion, is there any reason not to switch the three of them to abstract classes?
I tend to prefer abstract because I can put there some common functions if needed.
Bugs creator.
Features destroyer.
Template killer.

Re: interface VS abstract

Reply #1 –

http://www.php.net/manual/en/language.oop5.abstract.php#usernotes
https://www.brandonsavage.net/interfaces-or-abstract-classes/

There's so many more, just search for "abstract vs interface"

You can have an interface and an abstract class.

If you had an abstract DbSearch class, would instances of the object share methods and properties? If not, it probably makes more sense as an interface.

When I work on local things, I almost never use interfaces because I don't need to worry about how it will be implemented later. I can just rewrite the class or extend another one. For open source stuff, you don't know how it will be used. So, more interfaces, to ensure that the objects are portable, should be used.
 

Re: interface VS abstract

Reply #2 –

Yep, have a common method is what I was thinking to put into the database class (just because it looked the most appropriate place to have it... heck, now that I think about it I may have broken the branch...oh well it's for development so who cares :P).

Okay, so from a practical point of view, there isn't much difference, let's say an abstract class with only abstract methods would be more or less like an interface (except for the "formality" of extends instead of implements).
From the "ideological" point of view they have a different meaning.

From time to time I'm way too practical for that things. :P
Bugs creator.
Features destroyer.
Template killer.