7 Replies - 981 Views - Last Post: 17 September 2008 - 06:15 AM Rate Topic: -----

#1 sms123  Icon User is offline

  • D.I.C Head

Reputation: 0
  • View blog
  • Posts: 64
  • Joined: 15-August 08

OOP, getting stuck on some theory

Post icon  Posted 10 September 2008 - 03:23 AM

Hey guys, been working through a java book and there are some chapters i am having a bit of trouble understanding;
-Abstract Classes and Interfaces;
Is This A Good Question/Topic? 0
  • +

Replies To: OOP, getting stuck on some theory

#2 1lacca  Icon User is offline

  • code.rascal
  • member icon

Reputation: 44
  • View blog
  • Posts: 3,822
  • Joined: 11-August 05

Re: OOP, getting stuck on some theory

Posted 10 September 2008 - 04:21 AM

Quote

Abstract Classes versus Interfaces
Unlike interfaces, abstract classes can contain fields that are not static and final, and they can contain implemented methods. Such abstract classes are similar to interfaces, except that they provide a partial implementation, leaving it to subclasses to complete the implementation. If an abstract class contains only abstract method declarations, it should be declared as an interface instead.

Multiple interfaces can be implemented by classes anywhere in the class hierarchy, whether or not they are related to one another in any way. Think of Comparable or Cloneable, for example.

By comparison, abstract classes are most commonly subclassed to share pieces of implementation. A single abstract class is subclassed by similar classes that have a lot in common (the implemented parts of the abstract class), but also have some differences (the abstract methods).

More here
Was This Post Helpful? 0
  • +
  • -

#3 sms123  Icon User is offline

  • D.I.C Head

Reputation: 0
  • View blog
  • Posts: 64
  • Joined: 15-August 08

Re: OOP, getting stuck on some theory

Posted 10 September 2008 - 05:55 AM

Thanks for the reply, but what are they used for, what makes them special/useful, where would u use them?
thanks man
Was This Post Helpful? 0
  • +
  • -

#4 1lacca  Icon User is offline

  • code.rascal
  • member icon

Reputation: 44
  • View blog
  • Posts: 3,822
  • Joined: 11-August 05

Re: OOP, getting stuck on some theory

Posted 10 September 2008 - 07:05 AM

The link I've posted explains abstract classes and their usage (with examples!) quite well. There is a link on that page to a similar introduction to interface as well.
Have you read it at all, or something is not clear there? If the latter, then please ask a specific question, if the first one, then please read it first.
Was This Post Helpful? 0
  • +
  • -

#5 pbl  Icon User is offline

  • There is nothing you can't do with a JTable
  • member icon

Reputation: 8324
  • View blog
  • Posts: 31,857
  • Joined: 06-March 08

Re: OOP, getting stuck on some theory

Posted 10 September 2008 - 05:22 PM

View Postsms123, on 10 Sep, 2008 - 05:55 AM, said:

Thanks for the reply, but what are they used for, what makes them special/useful, where would u use them?
thanks man

Lacca explanations were quite clear...
OK a small example

Imagine a class Polygon which would contain an int numberOfSides and a method computeArea.
This class would be abstract and would be extended by the classes Rectangle and Triangle that would set numberOfSides to 3 and 4 and provide their respective computeArea method

Now you can have a class that extends Thread that works well
But if your class already extends JPanel it cannot also extends Thread (as it can be done in C++) so you will have to
class MyClass extends JPanel implements Runnable
which mean I am an extension of JPanel but I also implements the methods of Runnable



View Post1lacca, on 10 Sep, 2008 - 07:05 AM, said:

The link I've posted explains abstract classes and their usage (with examples!) quite well. There is a link on that page to a similar introduction to interface as well.
Have you read it at all, or something is not clear there? If the latter, then please ask a specific question, if the first one, then please read it first.

Sorry Lacca
didn't realized you had already answered (dammed laptop)

Read first :angry:

This post has been edited by pbl: 16 September 2008 - 08:17 PM

Was This Post Helpful? 0
  • +
  • -

#6 1lacca  Icon User is offline

  • code.rascal
  • member icon

Reputation: 44
  • View blog
  • Posts: 3,822
  • Joined: 11-August 05

Re: OOP, getting stuck on some theory

Posted 17 September 2008 - 01:09 AM

No problem, the more answers, (hopefully) the idea is better explained!
Was This Post Helpful? 0
  • +
  • -

#7 mondal.sukanta  Icon User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 8
  • Joined: 17-September 08

Re: OOP, getting stuck on some theory

Posted 17 September 2008 - 05:35 AM

View Postsms123, on 10 Sep, 2008 - 03:23 AM, said:

Hey guys, been working through a java book and there are some chapters i am having a bit of trouble understanding;
-Abstract Classes and Interfaces;

Interface vs. Abstract class
Abstract Class:
  • Abstract classes let you define some default behavior; they force your subclasses to provide others.
  • For example, if you have an application framework, an abstract class may provide default services such as event and message handling. Those services allow your application to plug in to your application framework. However, there is some application-specific functionality that only your application can perform. Such functionality might include startup and shutdown tasks, which are often application-dependent. So instead of trying to define that behavior itself, the abstract base class can declare abstract shutdown and startup methods.
Interface:
  • If you need to change your design, make it an interface.
  • For example, a media player might know how to play CDs, MP3s, and wav files. Of course, you don't want to hardcode those playback algorithms into the player; that will make it difficult to add a new format like AVI. Furthermore, your code will be littered with useless case statements. And to add insult to injury, you will need to update those case statements each time you add a new algorithm. All in all, this is not a very object-oriented way to program. This is an excellent place to use an interface so that you can provide new media plug-ins at any time without any change in code.
When To Use Interfaces:
An interface allows somebody to start from scratch to implement your interface or implement your interface in some other code whose original or primary purpose was quite different from your interface. To them, your interface is only incidental, something that have to add on to the their code to be able to use your package.
When To Use Abstract classes:
An abstract class, in contrast, provides more structure. It usually defines some default implementations and provides some tools useful for a full implementation. The catch is, code using it must use your class as the base. That may be highly inconvenient if the other programmers wanting to use your package have already developed their own class hierarchy independently. In Java, a class can inherit from only one base class.
When to Use Both:
You can offer the best of both worlds, an interface and an abstract class. Implementors can ignore your abstract class if they choose. The only drawback of doing that is calling methods via their interface name is slightly slower than calling them via their abstract class name.

1) Normal class vs other type (abstract and interface):
If content is not a core entity of my application means as per the business logic if content is nothing in my application only Article, Blogs, Review are the core part of business logic then content class should not be a normal class because I’ll never make instance of that class. So if you will never make instance of base class then Abstract class and Interface are the more appropriate choice.

2) Interface vs Abstract Class.
As you can see content having behavior named “Publish”. If according to my business logic Publish having some default behavior, which apply to all I’ll prefer content class as an Abstract class.
If there is no default behavior for the “Publish” and every drive class makes their own implementation then there is no need to implement “Publish” behavior in the base case I’ll prefer Interface.

These are the in general idea of taking decision between abstract class, interface and normal class. But there is one catch. As we all know there is one constant in software that is “CHANGE”. If I made content class as Interface then it is difficult to make changes in base class because if I add new method or property in content interface then I have to implement new method in every drive class. These problems will over come if you are using abstract class for content class and new method is not an abstract type. So we can replace interface with abstract class except multiple inheritance.

Language Definition:
We cannot make instance of Abstract Class as well as Interface.
Here are few differences in Abstract class and Interface as per the definition.

Abstract class can contain abstract methods, abstract property as well as other members (just like normal class).
Interface can only contain abstract methods, properties but we don’t need to put abstract and public keyword. All the methods and properties defined in Interface are by default public and abstract.

//Abstarct Class
public abstract class Vehicles
{
private int noOfWheel;
private string color;
public abstract string Engine
{
get;
set;
}
public abstract void Accelerator();
}

//Interface
public interface Vehicles
{
string Engine
{
get;
set;
}
void Accelerator();
}

We can see abstract class contains private members also we can put some methods with implementation also. But in case of interface only methods and properties allowed.
We use abstract class and Interface for the base class in our application.
Was This Post Helpful? 0
  • +
  • -

#8 1lacca  Icon User is offline

  • code.rascal
  • member icon

Reputation: 44
  • View blog
  • Posts: 3,822
  • Joined: 11-August 05

Re: OOP, getting stuck on some theory

Posted 17 September 2008 - 06:15 AM

View Postmondal.sukanta, on 17 Sep, 2008 - 02:35 PM, said:

If you need to change your design, make it an interface.

Did you mean implementation instead of interface here? If you have to change the design, then you are throwing out the interface as well - or I might have misunderstood something.

Also, I'd add that interface is a generalization of a service, so I think it is more appropriate to say something like: use an interface when you only want to specify a set of supported features that you support or want to use, so others can provide their own implementation. The difference might look only linguistic here, but it is not about changing design, rather about generalization and preparing for different providers of the same services.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1