About abstract method

Hi, there are many abstract methods In the abstract java.awt.Graphics class. when I write a class extends Component(for example JPanel), override the paint(Graphics g) method, then I can invoke the abstract methods in the Graphics class to draw in my Component.
So I think there is a class extends the Grahpics class, but is secret to us. and the JDK designer how to design these class structor?
Thanks a lot,
Regards.

The reason that why most of the methods of the Graphics class are abstract is because to have an implementation for them, the underlying platform must be used, for example: g.drawLine(0,0,100,100) would on Linux end up on the native side making the call:
XDrawLine(display,drawable,gc,0,0,100,100);whereas on Windows it would be something else. There is not platform independent way to draw on the screen.
Tuomas Rinta

Similar Messages

Which of the following are true about abstract methods in EJB 2.0

Hi guys I'm beginner to EJB and i got some unanswered questions.
Can any one of you please.. give answers?
Thanks if you do...
Which of the following are true about abstract methods in EJB 2.0
CMP?
Choose all correct answers:
1. Abstract accessor methods should not be exposed in the EJB
component's interface
2.Abstract accessor/mutator methods are used to access and modify
persistent state and relationship information for entity objects
3.Abstract Accessor/Mutator methods do not throw exceptions
4.The EJB developer must implement the Accessor/Mutator methods
5.Abstract accessor methods may or may not be exposed in the EJB
component's interface
2.Which ONE of the following is true?
Choose the best answer:
1.Local interfaces cannot have a relationship with other Entity
components
2.Local interfaces cannot be used for Stateless Session EJB
3.Local interfaces can be a part of Object's persistent state
4.Local interfaces have the same functionality as that of a
stateless Session EJB
3.Which of the following describe the <cmr-field> in a EJB 2.0
descriptor?
Choose all correct answers:
1.A Local interface/Entity can be a value of a <cmr-field>
2.There is no <cmr-field> in EJB 2.0 descriptor
3.It is used to represent one meaningful association between any
pair of Entity EJBs, based on the business logic of the Application
4.It provides a particular mapping from an object model to a
relational database schema
5.It allows the Local Entity interfaces to participate in
relationships
4.Which of the following are the advantages of using Local interfaces
instead of dependent value classes?
Choose all correct answers:
1.Local Entity Interfaces can participate in Relationships
2.The life cycle of Local Entity Interfaces is managed by EJB
container, intelligently
3.Local Entity Interfaces can be used in EJB QL Queries
4.Local Entity Interfaces can be a part of the <cmp-field> but not
<cmr-field>
5.Which of the following are true about Local interfaces
1.A local interface must be located in the same JVM to which the EJB
component is deployed
2.Local calls involve pass-by-reference.
3.The objects that are passed as parameters in local interface
method calls must be serializable.
4.In general, the references that are passed across the local
interface cannot be used outside of the immediate call chain and must
never be stored as part of the state of another enterprise bean.
6.Which of the following specifies the correct way for a client
to access a Message driven Bean?
Choose the best answer:
1. via a Remote interface
2. via Home interface
3. Message driven bean can be accessed directly by the client
4. both 1 & 2
5. none of the above
------------------------------------------------------------------------7.Which of the following statements are true about message-driven
bean Clients?
------------------------------------------------------------------------Choose all correct answers:
They can create Queue and QueueConnectionFactory objects
They can create Topic and TopicConnectionFactory objects
They can lookup the JNDI server and obtain the references for
Queue and Topic and their connection Factories
Only 1 and 2 above

Hi guys I'm beginner to EJB and i got some unanswered
questions.
Can any one of you please.. give answers?
Thanks if you do...
Which of the following are true about abstract methods
in EJB 2.0
CMP?
Choose all correct answers:
1. Abstract accessor methods should not be exposed
d in the EJB
component's interfacefalse
2.Abstract accessor/mutator methods are used to
access and modify
persistent state and relationship information for
entity objectstrue
>
3.Abstract Accessor/Mutator methods do not throw
exceptionstrue
>
4.The EJB developer must implement the
Accessor/Mutator methodsfalse
5.Abstract accessor methods may or may not be exposed
in the EJB
component's interfacetrue
2.Which ONE of the following is true?
Choose the best answer:
1.Local interfaces cannot have a relationship with
other Entity
componentsfalse
2.Local interfaces cannot be used for Stateless
Session EJBfalse
3.Local interfaces can be a part of Object's
persistent statefalse
4.Local interfaces have the same functionality as
that of a
stateless Session EJBtrue
3.Which of the following describe the <cmr-field> in a
EJB 2.0
descriptor?
Choose all correct answers:
1.A Local interface/Entity can be a value of a
<cmr-field>true
2.There is no <cmr-field> in EJB 2.0 descriptorfalse
3.It is used to represent one meaningful association
between any
pair of Entity EJBs, based on the business logic of
the Applicationtrue
4.It provides a particular mapping from an object
model to a
relational database schematrue
5.It allows the Local Entity interfaces to
participate in
relationshipstrue
4.Which of the following are the advantages of using
Local interfaces
instead of dependent value classes?
Choose all correct answers:
1.Local Entity Interfaces can participate in
Relationshipsis
2.The life cycle of Local Entity Interfaces is
managed by EJB
container, intelligentlyis
3.Local Entity Interfaces can be used in EJB QL
Queriesnot
4.Local Entity Interfaces can be a part of the
<cmp-field> but not
<cmr-field>not
>
>
5.Which of the following are true about Local
interfaces
1.A local interface must be located in the same JVM
M to which the EJB
component is deployedtrue
2.Local calls involve pass-by-reference.true
3.The objects that are passed as parameters in local
l interface
method calls must be serializable.false
4.In general, the references that are passed across
s the local
interface cannot be used outside of the immediate
e call chain and must
never be stored as part of the state of another
r enterprise bean.true
>
6.Which of the following specifies the correct way for
a client
to access a Message driven Bean?
Choose the best answer:
1. via a Remote interfacefalse
2. via Home interfacefalse
3. Message driven bean can be accessed directly by
the clientfalse
4. both 1 & 2false
5. none of the abovetrue.
>
----------------7.Which of the following statements
are true about message-driven
bean Clients?
----------------Choose all correct answers:
They can create Queue and QueueConnectionFactory
objectsthe container can, dunno bout clients
>
They can create Topic and TopicConnectionFactory
objectsthe container can, dunno bout clients
>
They can lookup the JNDI server and obtain the
references for
Queue and Topic and their connection Factories
true
Only 1 and 2 abovefalse
somebody correct me if i'm wrong

Misunderstanding about abstract methods

I think my compiler just taught me something, and after reading the JLS I concluded that I had a misconception about abstract methods. However, if someone could confirm this I would feel more comfortable.
I had defined a class structure like so:public abstract class Grandpa{
public abstract void do();
public abstract class Pa extends Grandpa {
public void do(){
// whatever
public class Child extends Pa {
}I got a compile error indicating that Child must implement do(). I had thought that since there was an implementation provided by Pa that Child didn't need to supply one, but I guess I was wrong. Right? :-)

Nested where? Inside Pa? Other? Static?Inside Pa.
It sounds like you're satisfied, but if you want to
continue the discussion, I'll make the standard
request. Come on, you know it, say it with me: Provide
a small, complete, working (in that it doesn't
compile) example that demonstrates this. :-)Yeah, that's exactly what I was working on for the bug report, but I can't get the compile error in my small example. Argh! I'll have to go back some time and build it up to match the other classes until I get the error, because I still get it consistently with the real thing. I have no idea what the key factor is, though - I've tried everything obvious and I don't have time to work through it right now.
No prob. It's a pleasant break from arguing with UJ.
:-)Glad I could offer you a distraction. :-) I'll post here again if I ever figure out what the deal is.

Newbie question about abstract methods

hey, I'm working on a web application that I was given and I'm a little confused about
some of the code in some of the classes. These are some methods in this abstract class. I don't understand
how this post method works if the method it's calling is declared abstract. Could someone please tell me how this works?
    public final Representation post(Representation entity, Variant variant) throws ResourceException {
        prePostAuthorization(entity);
        if (!authorizeGet()) {
            return doUnauthenticatedGet(variant);
        } else {
            return doAuthenticatedPost(entity, variant);
protected abstract boolean authorizeGet();Thanks
Edited by: saru88 on Aug 10, 2010 8:09 PM

Abstract Methods specify the requirements, but to Implement the functionality later.
So with abstract methods or classes it is possible to seperate the design from the implementation in a software project.
Abstract methods are always used together with extended classes, so I am pretty sure that you are using another class.
Btw: Please post the Code Keyword in these brackets:

About abstract method read() in class InputStream (third message)

The subclass FilterInputStream is not abstract and extend InputStream: have you ever seen the implementation of that method in the source code available in SDK? It only calls that abstract method!!! I think it is not a very simple problem and anyway the answer is not in my diffrent books. Thanks for your non trivial answer.

Please post this as a "reply" in your original thread
http://forum.java.sun.com/thread.jspa?threadID=5192979&tstart=0
Don't start a new thread, simply reply to one of the other posts in the original thread (there is a button "reply" on the right hand side).

About abstract method read() in class InputStream

I would like to know if behind the method
public abstract int read() throws IOException
in the abstract class InputStream there is some code that
is called when I have to read a stream. In this case where can I find
something about this code and, if is written in other languages, why
is not present the key word native?
Thanks for yours answers and sorry for my bad english.

Ciao Matteo.
Scusa se ti rispondo in ritardo... ma ero in pausa pranzo.
Chiedimi pure qualcosa di pi? specifico e se posso darti una mano ti rispondo.
Le classi astratte sono utilizzate per fornire un comportamento standard lasciando per? uno o pi? metodi non implementati... liberi per le necessit? implementative degli utilizzatori.
Nel caso specifico la classe InputStream ? una classe astratta che lascia non implementato il metodo read(). Tu nel tuo codice non utilizzerai mai questa classe come oggetto, ma nel caso specifico una sua sottoclasse che ha implementato il metodo read().
Se vai nelle api di InputStream vedrai che ci sono diverse sottoclassi che estendono InputStream. Guarda ad esempio il codice di ByteArrayInputStream: in questa classe il metodo read() non ? nativo ma restituisce un byte appartenente al suo array interno.
I metodi nativi (ad esempio il metodo read() della classe FileInputStream) non hanno implementazione java ma fanno invece riferimento a delle chiamate dirette al sistema operativo.
Per quanto riguarda la classe FilterInputStream di cui parlavi: essa nel suo costruttore riceve un InputStream. Questo significa che si deve passare nel costruttore non la classe InputStream (che ? astratta) ma una classe che la estende e che quindi non sia astratta. Il motivo per il quale FilterInputStream faccia riferimento a una classe di tipo InputStream al suo interno, ? che in java gli stream di input e di output possono essere composti l'uno sopra l'altro per formare una "catena" (a tal proposito vedi per maggiori dettagli uno dei tani articoli che si trovano in rete.... ad esempio ti indico questo http://java.sun.com/developer/technicalArticles/Streams/ProgIOStreams/). Comunque per dirla in due parole: tu puoi voler usare un FileInputStream per leggere un file, ma se hai bisogno di effettuare una lettura pi? efficiente (quindi bufferizzata) puoi aggiungere in catena al FileInputStream un oggetto di tipo FilterInputStream (nel caso specifico un BufferedInputStream che non ? altro che una sottoclasse di FilterInputStream).
Spero di aver chiarito qualche tuo dubbio!
Ciao
Diego

About abstract method read() in class InputStream (second message)

I know but my question needs other arguments. When the Java virtual machine must help me in reading some input stream, I imagine it uses some calls to the operating system: I would like to know if behind that method there is something which seems a system call even if is abstract and so without apparently code.

Please post this as a "reply" in your original thread
http://forum.java.sun.com/thread.jspa?threadID=5192979&tstart=0
Don't start a new thread, simply reply to one of the other posts in the original thread (there is a button "reply" on the right hand side).

Abstract method and class

I'm a beginner in Java and just learn about abstract method and class.
However, i am wondering what is the point of using abstract method/class?
Because when I delete the abstract method and change the class name to public class XXXX( changed from "abstract class XXXX), my program still runs well, nothing goes different.
Is it because I haven't encountered any situation that abstract method is necessary or ?
Thanks!

Yes - you probably haven't encountered a situation where you need an abstract.
Abstract classes are not designed to do anything on their own. They are designed to provide a template for other classes to extend by inheritance. What you have build sounds like a concrete class - one which you are creating instances of. Abstract classes are not designed to be ever instantiated in their pure form - they act like a partial building block, which you will complete in a class which extends the abstract.
An example might be a button class, which provides some core functionality (like rollover, rollout etc) but has an empty action method which has to be overwritten by a relevant subclass like 'StartButton'. In general, abstract classes may not be the right answer, and many people would argue that it is better to use an interface, which can be implemented instead of extended, meaning that you can ADD instead of REPLACING.
Not sure if that helps.. there are whole chapters in books on this kind of thing, so it's hard to explain in a couple of paragraphs. Do some google searches to find out more about how they work.

Superclass and subclass and abstract method

Hi all,
I am a little bit confused about abstract methods.
I define a superclass without abstract keyword and an abstract method inside the superclass. Then I write a subclass to extend the superclass.
When I compile the source code I get error. It looks like I can't initiate an instance from the supercalss and/or subclass. If I put abstract key word in the superclass definition there is no problem at all. So my question: does abstract method needed to be defined in an abstract superclass only?
Thank for you input.

Abstract methods can only be declared in an abstract class.

About abstract interface and it's method

Hi !!
HttpSession session = request.getSession();
getSession() is the Method of HttpSession and it is the abstract interface..
right ??
so how can we call the abstract method and ..
here... request is the object of HttpServletRequest which is abstract interface so how can we make an Object of this abstract interface...
I m very confused Please solve my Querry ASAP

As far as I can tell, these three threads are all the same person asking the same question.
http://forum.java.sun.com/thread.jspa?threadID=5188609
http://forum.java.sun.com/thread.jspa?threadID=5188638
http://forum.java.sun.com/thread.jspa?threadID=5188603
How obnoxious.

Confusion about abstract drawImage-methods in jdk1.3

I have discovered that...
According to jdk1.3 and jdk1.3.1 API there are only abstract drawImage-methods in Graphics and Graphics2D class. That should mean they are not implemented hence you can't use them. Nevertheless they use them on tutorials and i was wondering which of them are actually working?
According to my JBuilder4 there are 2 implemented drawImage-methods in Graphics2D
drawImage(BufferedImage img, BufferedImageOp op, int x, int y) and
drawImage(Image img, AffineTransform xform, ImageObserver obs)
But!
According to tutorials they use
g2.drawImage(bi, 0, 0, this); which means they use
drawImage(BufferedImage img, int x, int y, ImageObserver observer) from the Graphics class
Has anyone tried drawingImages on a Canvas that can explain to me which one to use?

Your confusion is understandable. Let's recap:
* Graphics is an abstract class. This implies that in order for there to be an instance of one, there must be a subclass with a concrete implementation (i.e. all abstract method implemented)
* Graphics2D is an extension of Graphics and is also an abstract class. It adds all the support for the Java2D features, including support for BufferedImage.
So - when you get a graphics context - where is the implementation of the class coming from? The answer is that the Graphics instance you will use is provided by the platform-specific toolkit that your JDK implementation provides.
Incidentally, from JDK 1.2 onward, graphics contexts are guaranteed to be implementations of Graphics2D. This implies that the following conversion will always work:
   public void paintComponent(Graphics g)
       // Guaranteed to work
       Graphics2D g2 = (Graphics2D) g;
       g2.setPaint(Color.orange);
   }As to which version of drawImage() you should use: if your image is not already in a BufferedImage you should use the one that takes an Image as the first parameter.
Mitch Goldstein
Author, Hardcore JFC (Cambridge Univ Press)
[email protected]

A question about a method with generic bounded type parameter

Hello everybody,
Sorry, if I ask a question which seems basic, but
I'm new to generic types. My problem is about a method
with a bounded type parameter. Consider the following
situation:
abstract class A{     }
class B extends A{     }
abstract class C
     public abstract <T extends A> T someMethod();
public class Test extends C
     public <T extends A> T someMethod()
          return new B();
}What I want to do inside the method someMethod in the class Test, is to
return an instance of the class B.
Normally, I'm supposed to be able to do that, because an instance of
B is also an instance of A (because B extends A).
However I cannot compile this program, and here is the error message:
Test.java:16: incompatible types
found   : B
required: T
                return new B();
                       ^
1 errorany idea?
many thanks,

Hello again,
First of all, thank you very much for all the answers. After I posted the comment, I worked on the program
and I understood that in fact, as spoon_ says the only returned value can be null.
I'm agree that I asked you a very strange (and a bit stupid) question. Actually, during recent months,
I have been working with cryptography API Core in Java. I understood that there are classes and
interfaces for defining keys and key factories specification, such as KeySpec (interface) and
KeyFactorySpi (abstract class). I wanted to have some experience with these classes in order to
understand them better. So I created a class implementing the interface KeySpec, following by a
corresponding Key subclass (with some XOR algorithm that I defined myself) and everything was
compiled (JDK 1.6) and worked perfectly. Except that, when I wanted to implement a factory spi
for my classes, I saw for the first time this strange method header:
protected abstract <T extends KeySpec> T engineGetKeySpec
(Key key, Class<T> keySpec) throws InvalidKeySpecExceptionThat's why yesterday, I gave you a similar example with the classes A, B, ...
in order to not to open a complicated security discussion but just to explain the ambiguous
part for me, that is, the use of T generic parameter.
The abstract class KeyFactorySpi was defined by Sun Microsystem, in order to give to security
providers, the possibility to implement cryptography services and algorithms according to a given
RFC (or whatever technical document). The methods in this class are invoked inside the
KeyFactory class (If you have installed the JDK sources provided by Sun, You can
verify this, by looking the source code of the KeyFactory class.) So here the T parameter is a
key specification, that is, a class that implements the interface KeySpec and this class is often
defined by the provider and not Sun.
stefan.schulz wrote:
>
If you define the method to return some bound T that extends A, you cannot
return a B, because T would be declared externally at invocation time.
The definition of T as is does not make sense at all.>
He is absolutely right about that, but the problem is, as I said, here we are
talking about the implementation and not the invocation. The implementation is done
by the provider whereas the invocation is done by Sun in the class KeyFactory.
So there are completely separated.
Therefore I wonder, how a provider can finally impelment this method??
Besides, dannyyates wrote
>
Find whoever wrote the signature and shoot them. Then rewrite their code.
Actually, before you shoot them, ask them what they were trying to achieve that
is different from my first suggestion!
>
As I said, I didn't choose this method header and I'm completely agree
with your suggestion, the following method header will do the job very well
protected abstract KeySpec engineGetKeySpec (Key key, KeySpec key_spec)
throws InvalidKeySpecException and personally I don't see any interest in using a generic bounded parameter T
in this method header definition.
Once agin, thanks a lot for the answers.

...is not abstract and does not override abstract method compare

Why am I getting the above compile error when I am very clearly overriding abstract method compare (ditto abstract method compareTo)? Here is my code -- which was presented 1.5 code and I'm trying to retrofit to 1.4 -- followed by the complete compile time error. Thanks in advance for your help (even though I'm sure this is an easy question for you experts):
import java.util.*;
   This program sorts a set of item by comparing
   their descriptions.
public class TreeSetTest
   public static void main(String[] args)
      SortedSet parts = new TreeSet();
      parts.add(new Item("Toaster", 1234));
      parts.add(new Item("Widget", 4562));
      parts.add(new Item("Modem", 9912));
      System.out.println(parts);
      SortedSet sortByDescription = new TreeSet(new
         Comparator()
            public int compare(Item a, Item b)   // LINE CAUSING THE ERROR
               String descrA = a.getDescription();
               String descrB = b.getDescription();
               return descrA.compareTo(descrB);
      sortByDescription.addAll(parts);
      System.out.println(sortByDescription);
   An item with a description and a part number.
class Item implements Comparable
      Constructs an item.
      @param aDescription the item's description
      @param aPartNumber the item's part number
   public Item(String aDescription, int aPartNumber)
      description = aDescription;
      partNumber = aPartNumber;
      Gets the description of this item.
      @return the description
   public String getDescription()
      return description;
   public String toString()
      return "[descripion=" + description
         + ", partNumber=" + partNumber + "]";
   public boolean equals(Object otherObject)
      if (this == otherObject) return true;
      if (otherObject == null) return false;
      if (getClass() != otherObject.getClass()) return false;
      Item other = (Item) otherObject;
      return description.equals(other.description)
         && partNumber == other.partNumber;
   public int hashCode()
      return 13 * description.hashCode() + 17 * partNumber;
   public int compareTo(Item other)   // OTHER LINE CAUSING THE ERROR
      return partNumber - other.partNumber;
   private String description;
   private int partNumber;
}Compiler error:
TreeSetTest.java:25: <anonymous TreeSetTest$1> is not abstract and does not over
ride abstract method compare(java.lang.Object,java.lang.Object) in java.util.Com
parator
            public int compare(Item a, Item b)
                       ^
TreeSetTest.java:41: Item is not abstract and does not override abstract method
compareTo(java.lang.Object) in java.lang.Comparable
class Item implements Comparable
^
2 errors

According to the book I'm reading, if you merely take
out the generic from the code, it should compile and
run in v1.4 (assuming, of course, that the class
exists in 1.4). I don't know what book you are reading but that's certainly incorrect or incomplete at least. I've manually retrofitted code to 1.4, and you'll be inserting casts as well as replacing type references with Object (or the erased type, to be more precise).
These interfaces do exist in 1.4, and
without the generics.Exactly. Which means compareTo takes an Object, and you should change your overriding method accordingly.
But this raises a new question: how does my 1.4
compiler know anything about generics? It doesn't and it can't. As the compiler is telling you, those interfaces expect Object. Think about it, you want to implement one interface which declares a method argument type of Object, in several classes, each with a different type. Obviously all of those are not valid overrides.

Non-abstract methods in a Abstract class

Abstract Class can contain Non-abstract methods.
and Abstract Classes are not instantiable as well
So,
What is the purpose of Non-abstract methods in a Abstract class.
since we can't create objects and use it
so these non-abstract methods are only available to subclasses.
(if the subclass is not marked as abstract)
is that the advantage that has.(availability in subclass)
??

For example, the AbstractCollection class (in
java.util) provides an implementation for many of the
methods defined in the Collection interface.
Subclasses only have to implement a few more methods
to fulfill the Collection contract. Subclasses may
also choose to override the AbstractCollection
functionality if - for example - they know how to
provide an optimized implementation based on
characteristics of the actual subclass.Another example is the abstract class MouseAdapter that implements MouseListener, MouseWheelListener, MouseMotionListener, and that you can use instead of these interfaces when you want to react to one or two types of events only.
Quoting the javadocs: "If you implement the MouseListener, MouseMotionListener interface, you have to define all of the methods in it. This abstract class defines null methods for them all, so you can only have to define methods for events you care about."

Abstract method which when implemented will have different parameters

Hello to all,
I have an assignment but not looking for someone to do it for me. I am only searching for a suggestion on how to do the following.
Imagine having an application that needs to provide an estimate of the rent for different buildings.
Basically I start with by having a class name Building. This class has an abstract method called estimateRent.
I then create two classes that extend the class Building which are named Apartment and House. Both need to have the method estimateRent.
However the problem is that the rent for the Apartment is calculated on the nights passed in the flat and the people in it, while the rent for the House is just calculated on a month bases.
This means the estimateRent method requires to have different parameters depending if it is implemented inside the Apartment class or the House class.
Now I only know of two options.
The first option is to not declare the estimateRent method as an abstract method inside the Building class and just implemented inside the Apartment and House with different parameters. I do not like this option since in the future if a new Building comes in then I would like to impose the fact that that object needs to have a calculate method.
The second option is to make the estimateRent method as abstract inside the Building class however takes a parameter of either a String array or else a Map. Then the estimateRent within the Apartment class would search for the elements tagged as nights and people, and the House class would only search for the elements tagged as months!
However do not know if there are any other, better ways on how to do this. I am using Java 1.4 however if you only have answers for Java 5.0 then please post them again since I always like to learn something new :)
Thank You for any comments.
tx

The implementation changes, yes.Yes that I could understand in the Strategy Pattern (in the document I read it was being compared with the Template Pattern).
Then you need to refactor your design.I tought about that, however if you read my first post you will notice that I have different criteria on which the costs need to be estimated. While the costs for a flat are estimated on the people staying in and nights slept there, the costs for the house are based only on the months stayed there regardless of the people living in. Now for me I feel that it is bad programming practice to create one method that can have all the parameters required for any scenario. I mean the following is NOT something I am going to do:
estimateCosts(int nights, int people, int months ... etc);
That's not a very elegant way of going about it.
What is the "Context" going to have?Yep I agree, but so far my limited brain has only come up with that! I am open to any other sugestion! always if i understand it first!
Basically the Context would better be named as Criteria and it would be an interface as follows:
interface Criteria{}
Then I would create two classes that implement the Criteria object as follows:
class AppartmentCriteria implements Criteria{
public Result estimateCosts(int nights, int people);
class HouseCriteria implements Criteria{
public Result estimateCosts(int months);
Now when I recieve the inputs, depending on the scenario the Criteria is typecasted and the correct parameters passed and we recieve the Result.
I feel the above sucks since I am not seeing it as an object oriented way of doing this out! Is there any other sugestions! The refactoring thing I am intrested in! however really I can not see how such a call to that method could be refectored!
Thank You,
tx.
PS: Sun has blocked my other account as well, and this time they did not even send me an email to confirm that I was registered successfuully :( Is there someone I can contact on this? I guess next time I will reply with tx53m :)

About abstract method

Similar Messages

Maybe you are looking for