Implements and Extends?

I had a question about interfaces. I know how they work but I dont see the point in having them...?
If I put methods into an Interface, then each method in the interface must appear in that class.
abstract interface Drive {
public void start();
public void accel();
public void decel();
public void dropTop();
public class Car implements Drive {
}and if I have a class that extends Car, then it also implements Drive. but I dont see the benefit of having Drive at all.
help?

interfaces are useful when it comes to multiple inheritance, since you can't extends more than one class, but you can implement as much interface as you want
imagine for example that your "Car" class is supposed to extends "Vehicle", but it also has to be an Observer (for the Observable/Observer pattern)
you can make it both a Vehicle and an Observer using:
class Car extends Vehicle implements Observer {}and if you want your car to be a vehicle, an observer, and an oil consumer:
class Car extends Vehicle implements Observer, OilConsumer {}if you only had two classes OilConsumer and Vehicle, you would have to choose which one car will extend ; with interfaces, you can use both at one time
interfaces can also be used as simple markers
did you try to search a bit before asking your question here?

Similar Messages

Difference between implements and extends

Hi all,
what is the difference between implements and extends. i am sorry to ask this silly question, but i am new to JAVA.
Thanks
Balaji

when you extend a class, your class that you are coding inherits every method and field from the extending class. For example:
public class CustomFrame extends JFrame {
//Your class's methods will be in here, but so will all of JFrame's methods.
}You can override (most) methods from extended classes if you want them to do different things than they normally do. The most commonly overriden methods when using swing are stuff like paint(Graphics g). It needs to be overriden to repaint all of the components.
When you imlpement something, you have to specify an interface. Interfaces have methods in them with no code. If you implement an interface, all methods in in must be defined. If not, the code will not compile. Some interfaces like ActionListener extend other classes to perform stuff. The actionPerformed(ActionEvent e) method will perform an action when a button is pressed, etc.

Difference between Implement and Extend

what is the difference between implements and extends and why do we use them
thanks,

classes extend one other class and implement as many
interfaces as they wish.
interfaces extend as many interfaces as they wish.But for all that, they both just mean "inherits."
There wouldn't even have to be two different words, since you never have a choice between X extends Y and X implements Y. For a given X and Y, only one of the two will be legal.

Implementing and Extends

What is the difference between implements and extends?
For example, public class Banner extends Applet implements Runnable =>
If you extend a Class, then you can use the members of the superclass(which is Applet in this situation). And if you implement a Class then you can also use the members of the class. And as far as i know the Class youre implementing is called an interface. I know that an interface is not implemented yet, and it contains a lot of empty methods like public interface Series{ int getNext(); void reset(); void setStart(int x); }   .
Then if you want to implement this interface you must use another class. In this class you define the methods and also write a couple of variables, whom you will be putting in the not implemented methods, like this=>
class ByTwos(extends superclass) implements Series { int start;    int val;   ByTwos(){start=0; val=0;}
public in getNext(){val +- 2}    public void reset(){start=0; val=0;}
public void setStart(int x) {start=x; val=x;}        }.
Then you create another Class with a main method and an object of type ByTwos, wherein you USE THE MEMBERS OF THE INTERFACE CLASS.
Are the things i wrote right? What is the difference then?

Shelby wrote:
jverd wrote:
If all the methods defining a type are abstract, you can make the type an interface. An
interface is very much like a class with all abstract methods. Users of that interface
don't care which implmentation they get. All they need to know is that they'll be able to
call the declared methods.Dense people really annoy me, and right now I'm being REALLY dense about the advantage of using
an interface. I can understand what you say about using an interface to define a type of something
like an animal. But since all of the variables in an interface are final, and all of the methods are only
signatures, it seems to me it would just be easier to create classes that use their own methods that
actually perform a task.You're only thinking of writing the concrete classes. Think about the code that uses the type.
Animal animal = goGetSomeRandomAnimalFromSomewhere();
animal.speak();
animal.feed();I define the Animal type, as an interface, and every user of Animal knows that any Animal (meaning an instance of any class that implements Animal) will be able to speak(), feed(), etc.
Now I'm making some kind of game with animals wandering around in it. I want to draw some random animal on the screen, have it make its noise and then go eat. At the point where my code is doing that (above), I don't know what specific Animal implementation I'll get, only that it will be an Animal. So I have to declare the animal variable as a supertype of all the classes that could come back.
The Animal type serves that purpose. It could be an abstract class, rather than an interface, but an abstract class can carry implementation, and my Animal class has no implementation. How does an Animal speak()? How does it feed()? Animal is simply a pure type. Interfaces are better suited for pure type defintions than abstract classes. That's their purpose.
In addition, my implementing classes can implement other interfaces besides Animal, such as, for instance, Serializable or Comparable. Java doesn't support multiple inheritance of implementation, but it does support multiple inheritance of type--via being able to implement multiple interfaces.
Remember--inheritance is primarily about type, NOT about code sharing.
As another example, consider the java.util.List interface. You can add() to a list, remove() from it, see if it contains() a particular element, etc. There are multiple ways you could implement a List, and there's not really any common implementation you'd want to assume. So we define a List interface--the pure type--and then we implement it in very different ways via ArrayList and LinkedList. (Actually, there's a layer or two of abstract classes between List and those implementations. The abstract classes define implementations of some of the methods that do have reasonable defaults--for instance if they only rely on other methods in the List interface.)
Now I want to do something with a List--say shuffle it or sort it or display its contents in a GUI--I don't care what kind of List you give me. I'm just going to use the methods that all lists provide to perform my operation.
public void sort(List list) {
// I can sort ANY List here
}Now, if you still don't think this makes sense, can you tell me how you'd do this without interfaces?

Whats the difference between implements and extends!??

Can an interface be extended or not??
If it can whats the difference between implements and extends??
Thank you!

Code Sample:
interface a implements aa{This is illegal. An interface cannot implement another interface. It can only extend another interface.
interface a extends aa{That's the way to do it. As already said above:
An interface can only extend another interface.
A class can extend another class.
A class can implement zero or more interfaces.
So, "implements" is only used for classes that implement interfaces. For the rest, "extends" is used.

Ok, easy question...About implements and extends

Im sure this will be simple to all of you, but I am still new to the Java language. I want to know the difference between using "extends" and "implements" in the way that its used in these examples:
With the "extends" keyword...
class PrimeThread extends Thread {
         long minPrime;
         PrimeThread(long minPrime) {
             this.minPrime = minPrime;
         public void run() {
             // compute primes larger than minPrime
     }And then with the "implements" keyword...
Using the interface "Runnable"
class PrimeRun implements Runnable {
         long minPrime;
         PrimeRun(long minPrime) {
             this.minPrime = minPrime;
         public void run() {
             // compute primes larger than minPrime
     }Can someone please explain when you would want to use the "extends" version and when you would want to use the "implements" version? Sorry for practically insulting your intelligence...I'm just trying to learn this language without a book as an experiment to see (how much/how fast) I can learn purely using the web resources...Thanks to anyone who wishes to explain this to me.

That's pretty much it.
An interface may extend zero or more other interfaces.
A class (except Object) always extends exactly one other class--either the class explicitly named with "extends", or Object if "extends" is not present.
A class may implement zero or more interfaces.
"Extends" implies a parent-child relationship. Interfaces extend other interfaces, and classes extend other classes.
"Implements" implies a contract stating that the class will provide implementations for all the methods declared in the interface (or the class will be declared abstract). If a class implements A, and A extends B, then that class must implement all methods declared in A and all methods declared in B.
Does this help?

Classic and Extended classic scenario

Hi All,
Can we have classic scenario for Service procurement (MM-SRV) and Extended classic for direct material procurement in the same SRM system.
This is because Extended classic doesnot support service procurment where as Classic scenario supports
Does any body implemented like this. If so pls let me know Pros and cons
Abdul Raheem

Hi Laurent,
Thanks for reply.
Do we have any limitations if we go by this model like Service procurement by Classic and Direct procurement by Extended Classic.
If any thing breif on PRos and Cons of going by this model.
Abdul raheem

Adf bc jar for base entity classes and extending them existing project

Hi,
I am using jdev 11.1.1.0 and have created a base workspace/project and adf jar for my base entity classes.
1. I can consume this base adf bc jar in a separate new consuming workspace and create VO based on base bc classes or create new EOs that extend base bc entity classes.
2. Furthermore, for an existing consuming project that earlier included src/ of base entity (BC components), i can remove the dependency on bc source and bring in this new adf jar and everything including the view controller and the service/datacontrol works fine.
The issue i am running into is as follows.
- In the existing project (#2) above i try to create a couple of entities based on entities in my base jar; associations are automatically brought in. Note i am not overriding any attributes. My intent here is to generate .java and implement some code.
- I then try to make my existing VOs based on the newly extended entity (VO overview->Entity Objects-> Shuttle NewEntity from Available to Selected)
- I then try to remove the old EO from selected under VO overview->Entity Objects->Shuttle OldEntity from Selected back
- I get a warning dialog box that says something to the effect that some viewlinks are dependent on these old EOs in this consuming project.
- I tried to laboriously analyzed dependencies and it this dialog box does not make any sense as I have already extended EOs and the tooling should be able to let me use these
My questions
- Why I am not able to remove old entities from VO dependencies
- Is it ok to leave the old EOs in "Selected" along with the newly extended EO ? What are the implications for this?
- I also thought about extending base associations, but did not go anywhere.
In general, I am ok with consuming an ADF BC jar that has entities etc. but not clear about removing dependencies of base EOs on VOs when entities are extended and consumed in a pre-existing project that used base entities.
I can send a project if any PM is willing to take a look at it.
Thanks,
ps:
I have already gone over the following info
http://technology.amis.nl/blog/215/organization-of-bc4j-domain-eo-and-business-vo-package
.. wants to create an enterprise data model in BC4J, reflecting the Enterprise Data Model set up in the RDBMS. All (or at least most) business rules will be implemented in the Middle Tier – to take the load of the database and also allow developers not comfortable with PL/SQL to define and maintain the business rules. It is clear that this means that all applications that need to access – and manipulate – the database, need to go through the BC4J foundation layer. Martijn wants to define the Entity Objects – and their business rules – only once and share that definition between different projects. Each projects can create its own ViewObjects on top of these shared Enterprise Entity Objects.
http://radio-weblogs.com/0118231/2005/09/29.html
I am currently working on a project for a partner where we will be using ADF BC as our model layer for a large application. In order to keep the footprint of each application module down to a reasonable size, we are intending to create a number of separate 'root' application modules for each functional area of the application. Within, these 'root' application modules we will then use nested application modules to further partition the application. All of the application modules will be accessing the same datasource and will need access to the same database objects.
In order to separate our code between the development team and into function areas, our initial thoughts were that we would create an ADF BC model project containing Entity Objects for all of the database tables e.t.c. as these are common amongst all functional areas. We have configured all of the EOs for validation rules, defaulting values and extending doDML() as appropriate. Happy at this stage we then created a simple .jar file to deploy all of the definitions. Upon creating a new ADF BC project for each functional area we added the jar file as a library import into the new project. However when we the tried to create some new View Objects via the JDev Wizard we were unable to see the imported Entity Objects.
Is the only way to share Entity Object definitions between different ADF BC projects to manually copy the source definition files into the new projects src directory? Since this would mean multiple copies of the same components, it could prove to be a maintenance nightmare.Is there a way of doing it without creating multiple copies of the same object definitions?
The developer is spot on in their ideas of layering and reuse, and even has created a library for their reusable entities. This last step is not something everyone thinks to do. The missing step is known as "importing" components, so with that one extra bit of knowledge under his belt, he should be able to do exactly what he envisions. My little article called Difference Between Adding and Importing Business Components tries to explain the difference and gives the menu options to choose to perform the importing.
Difference between adding and importing BC4J
http://radio-weblogs.com/0118231/stories/2005/08/11/differenceBetweenAddingAndImportingBusinessComponents.html
Working with Libraries of Reusable Business Components
http://download.oracle.com/docs/cd/B32110_01/web.1013/b25947/bcadvgen.htm#CHEFECGD

Hi,
since you followed the OC4J developer guide I think this question might be better handled there as well
OC4J
So in case you don't get an answer here on the forum, try it on the OC4J forum
Frank

Classic and extended Classic.....

Hi Guru's
Can we have classic and extended classic together..If yes what settings need to be done and how based on what system will diffrentiate the follow on documents creation.
Thanks in Adv.
IS

Yes, this can be achieved. By default you have to activate Extended Classic Scenario in the system. But using the BADI BBP_EXTLOCALPO_BADI, you can switch to Classic Scenario based on your requirement.
For more details please check documentation here in your SRM system
SAP Implementation Guide ->
Supplier Relationship Management ->
SRM Server ->
   Business Add-Ins (BAdIs) ->
    Control Extended Classic Scenario ->
     Activate Extended Classic Scenario
Regards
Kathirvel

Reverting to classic scenario in SRM7.1, from PPS and extended classic

Hello Experts,
Recently we have moved from SRM7 to SRM 7.01, in which we can have PPS without Extended classic scenario.
As business wants classic scenario, How can we make the system as classic , in which PPS and extended classic is activated.
any badi is available for this? Please help.
Regards,
Raju

Raju,
Basically you have few points to keep in mind. (yes you need to activate the SPRO config for extended classic, apart from this).
1. switch between extended classic and classic is actually defined by the backend logical system of the document. if thats SRM itself then it follows the path of extended classic or if it is ECC then it follows classic.
because its basically creating a follow on document and that explains the scenario.
2. it also depends on what object are you expecting to be created. from a SC many documents can be created.
a. PO in SRM
b. PO in ECC
c. PR in ECC
d. Reservation in ECC
- so, if you can define at any point that where is your document to be created and what is to be created you can control the flow.
Now to do this. if you have few options.
Option1:
1. set the object types(2) for product categories (config, backend document type).
2. implement BBP_EXTLOCALPO_BADI to switch off extended classic
Options 2:
1. in doc change badi, change the backend destination to ECC
2. in Badi BBP_TARGET_OBJTYPE pass the object type you want your follow on document to be.
hope this explains

BADI for Classic and Extended Classic Scenario

Hi,
   Please   provide list of Reports and BADI's for
       Classic and Extended Classic Scenario.
Thanks,
Srini

Hi,
In SRM there will be a number of BADI's are Available, We can utilize them according to the requirements
As per the request few important BAID are provided below..
Workflows
1). BBP_CHNG_AGNT_ALLOW:          Allow / Allow Change/Add Approver
This BADI is implemented not to allow users to change the approvers in the workflow.
2). BBP_WFL_SECUR_BADI:          Overwrites the authorization level of the approver
This BADI controls the restart of the workflow
Purchasing Related
1). BBP_PGRP_FIND:               Shopping Cart: Determine Responsible Purchasing Group(s)
This determines the responsible purchasing group for the shopping carts.
Shopping Cart Related
1). BBP_SC_MODIFY_UI:          BADI to Change Shopping Cart Layout
2). BBP_GROUP_LOC_PO:          Exit Grouping of Items for Local Purchase Orders
This splits local PO if more than one contract in a PO.
3). BBP_TARGET_OBJECTS:          Exit while determining target objects in backend
4). BBP_WF_LIST:               Change Worklists and Search Results Lists
This is used to restrict the search results for the user.
5). BBP_CTR_BE_CREATE:          Exit when Creating a Contract in the Backend System
6). BBP_CREATE_PO_BACK:          Exit while creating a purchase order in the backend system
This BADI is used to add the shopping carts attachments to the PO and also to make adjustments in payment terms, currency etcu2026
7). BBP_DOC_CHECK_BADI:     General BAdI in Cross-Check for Message Returns
8). BBP_DOC_CHANGE_BADI:     BAdI for Changing EBP Purchasing Documents
9). BBP_ECS_PO_OUT_BADI:     ECS: PO Transfer to Logistics Backend
Thanks
prasad .s

Can we use both Stand alone and Extended classic in one SRM system

Hi All,
Our client is now using Stand alone SRM system with back-end R/3 FI-CO system. Now they want to go Extended classic scenario for few product categories.
         Would it be possible to use both in one SRM system? If possible could you please provide what are the sequential steps to do this?
             Thanks in advance.
Regards,
Ram

Hi Ramesh,
How did you end up solving your problem, as i have the same scenario. Did you use this BADI (
SRM Server->Business Add-Ins->Control Extended Classic Scenario->Activate Extended Classic Scenario)? Based on my reading, it seems this BADI is relevant to switch between extended classic and classic scenarios.
From what i understand, we can control the standalone scenario via the define backend system configuration (SAP SRM -> SRM Server -> Technical Basic Settings -> Define Backend System for Product Category). In my scenario, I have one set of product categories, so i will likely need to implement this BADI (BBP_DETERMINE_LOGSYS, method:   DETERMINE_LOGSYS - SAP SRM -> SRM Server -> Business Add-Ins ->Shopping Carts and Requirement Items -> Determine Backend System / Company Code) in order to determine the correct backend system based on company/plant for example.
Did you then leave the extended classic scenario activated (IMG --> Supplier Relationship Management -> SRM Server-> Cross-Application Basic Settings->
Activate Extended Classic Scenario)?
Or how did you achieve both standalone and extended classic using one SRM server?
cheers,
AD

SRM standalone and extended classic

Hi Experts,
Configuration: ECC 6.0 (with Ehp4 installed - (not activated)
SRM 7.0
Just want to seek confirmation of my understanding re: SRM implementation scenarios. Is it possible to have a extended classic and standalone setup using the same SRM server with same client? Both will have the same product categories. These will be for two separate entities/companies.
Thanks in advance.
Regards.

Hi Mike,
How did you end up solving your problem, as i have the same scenario. Did you use this BADI (
SRM Server->Business Add-Ins->Control Extended Classic Scenario->Activate Extended Classic Scenario)? Based on my reading, it seems this BADI is relevant to switch between extended classic and classic scenarios.
From what i understand, we can control the standalone scenario via the define backend system configuration (SAP SRM -> SRM Server -> Technical Basic Settings -> Define Backend System for Product Category). In your scenario, you have one set of product categories, just like mine, so i assume you had to implement this BADI (BBP_DETERMINE_LOGSYS, method: DETERMINE_LOGSYS - SAP SRM -> SRM Server -> Business Add-Ins ->Shopping Carts and Requirement Items -> Determine Backend System / Company Code) in order to determine the correct backend system based on company/plant for example.
Did you then leave the extended classic scenario activated *
MG --> Supplier Relationship Management -> SRM Server-> Cross-Application Basic Settings->
Activate Extended Classic Scenario)?
Or how did you achieve both standalone and extended classic using one SRM server?
cheers,
AD

Implements versus Extends

I'm an inexperienced programmer.
After reading a number of articles I've been convinced that its generally better to use interfaces and implements, as opposed to classes and extended subclasses. However, I'm not sure how I should do that given my current situation?
I have a base class with a number of functions and variables. There is one function that I need to implement differently for a number of situations. At the moment I have something like...
class base {
int a;
int b;
void functionA() { does whatever; }
void functionB() { does whatever; }
class baseA extends base {
void functionC() { does whatever; }
class baseB extends base {
void functionC() { does whatever; }
class baseZ extends base {
void functionC() { does whatever; }
If I use implements instead of extends, doesn't that mean I have to include a copy of functionA and functionB in all of those subclasses? Isn't that inconvenient? Or is there a better way of doing this?
Thanks for any help!

I'm an inexperienced programmer.
After reading a number of articles I've been convinced
that its generally better to use interfaces and
implements, as opposed to classes and extended
subclasses. However, I'm not sure how I should do
that given my current situation?
I have a base class with a number of functions and
variables. There is one function that I need to
implement differently for a number of situations. At
the moment I have something like...
class base {
int a;
int b;
void functionA() { does whatever; }
void functionB() { does whatever; }
class baseA extends base {
void functionC() { does whatever; }
class baseB extends base {
void functionC() { does whatever; }
class baseZ extends base {
void functionC() { does whatever; }
If I use implements instead of extends, doesn't that
mean I have to include a copy of functionA and
functionB in all of those subclasses? Isn't that
inconvenient? Or is there a better way of doing this?
Thanks for any help!Intefaces aren't always the better choice, and I would say that the situation you descibe is one of those cases where they aren't the better choice.

Implements or extends first

I have an object B extends A and implements Comparable
what should I write in the class declaration
Public class B extends A implements Comparable<B>
or Public class B implements A extends Comparable<B>
Thanks very much

And I told you. Use the compiler. If you got an error message then what you tried was incorrect.
If however there is something you don't understand then try explaining what you typed in, what the compiler error message was and ask a specific question. Not just a vague "please help".

Implements and Extends?

Similar Messages

Maybe you are looking for