On Sep 23, 11:32*am, Damodhar <damu...@gmail. comwrote:
When would you use an abstract class and when an interface?
whats the abstract class.?
please give me the sample .
An abstract class is useful when you need a substantial amount of
functionality to be identical across the subclasses, for example in a
shopping cart with multiple methods of payment available, you could
have an abstract class which defines a generic payment method, and
have subclasses inherit from the superclass for each actual payment
method you want to support (paypal, credit card, account, etc). The
mechanics of how a payment is authorized would be different for each
subclass, but they all perform essentially the same function - they
validate that a user can prove that they can pay for the goods or
services in question.
An example of where an interface is useful is where you have unrelated
items that need to provide some similar functionality in a uniform
way. For example, you might have a CMS where articles are stored in a
database, but where the system caches them to disc as well as HTML
pages until the article in the database is modified, at which point
the physical file is deleted until the next time someone access the
copy in the database. Your CMS might also support the ability for
users to upload images, PDFs, etc to be stored for access on the disc,
but you definitely don't want these files to be deleted as the copy on
the disc represents the file itself and not a cached version. In this
case, you could create a Cacheable interface that says what methods a
class which is cached to disc needs to implement, while leaving it up
to the class itself to implement them. This makes more sense as
classes that represent different kinds of data almost certainly need
to implement their caching scheme (if any) differently.
Every class that allows caching would be defined as Class <name>
implements Cacheable, which is something you can then check for in
your code. Less experienced coders might test the class of an object
they are working with by getting the class and processing the result
with a big switch statement. This isn't the correct approach because
it means that you're assuming that certain classes objects implement
certain functionality, and if you add a new class to the system you
need to modify every switch statement in your software to take it into
account. If yo uimplement an interface you can test if an object
implements that interface with the instanceof keyword.
if ($thisObject instanceof Cacheable)
{
// Manage item's cache
}
This approach is better because it eliminates the switch statement and
thus makes your software easier to maintain. If you add a new class
to the system that also implements its own caching scheme then you
just need to declare that it implements Cacheable. As the interface
requires all classes to implement it to declare the methods specified
in the interface you can be sure that any class that implements
Cacheable will provide certain methods for you to use. Your code
doesn't need to know how the class implements these methods, just that
it does implement them.
These concepts are somewhat trickier to explain than to actually learn
to use I'm afraid, hopefully I've got the basic ideas across well
enough for you to figure them out for yourself.
