I often use interfaces to

Shaggy — Thu, 15 Apr 2010 15:17:19 +0000

I often use interfaces to group like behavior on similar objects so the 'manager' class may expect only an instance of the interface, rather than a full class.

Consider:
A Car and a Bicycle should both move(SomeType direction) in terms of being objects in traffic, and so perhaps implement the 'iMoveable' interface

Now a TrafficCop object may have the method addEntity(iMoveable object), instead of having an addCar(Car theCar) method and a addBicycle(Bicycle aBike) method. It can do this because all TrafficCop needs to know is that objects it obtains through the addEntity method implement a method called 'move(SomeType direction)'

And, later on, when you realize you forgot pedestrians in your implementation, no changes are required in your TrafficCop implementation... If city planners could only design to interfaces! .

Abstract classes allow for a partial implementation of an object, so other objects may extend the abstract, without the implementer having to worry that someone may try to instantiate the partial implementation...

OK, so it provides a kind of

pr0gr4mm3r — Sun, 11 Apr 2010 02:58:55 +0000

OK, so it provides a kind of framework or standard for other people to implement, but what is the point.

From what I know, it was to enforce how your class is to be used then inherited/extended. I don't think there is a point other than that.

It doesn't do any performance improvements that I know of, and no, I have not had any use for them. Maybe if I coded with a team, but I usually do not.