As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Let's say I'm extending JFileChooser and making an easy-to-use version, which I'm calling SimpleFileChooser.
It is structured such that it can either be DIALOG_TYPE_OPEN or DIALOG_TYPE_SAVE — hence, JFileChooser's showOpenDialog() and showSaveDialog() methods are superfluous. I replace them with a method called showDialog() which returns a boolean, but this is where I find myself in a dilemma:
Should I override the open/save methods and add #Deprecated tags to
them so that the API user knows they've been superseded? Would that
violate the annotation's original purpose?
Or would a notice in the documentation be enough? If so, where should
this notice be placed: in the class summary or above the overridden
methods? Should I even override the methods in the first place?
Thanks in advance.
I think you are actually building a facade, a simplified version of already existing API. Thus instead of inheritance you should use composition. Hide the original JFileChooser inside your new class and provide simpler API.
As a last resort you can provide public JFileChooser getRaw() method to access wrapped object if some other code needs it.
#Deprecated means you should not use that particular class or method anymore as it will be removed in the future. That annotation is designed for that.
So to answer shortly, if you dont want API users to use the method anymore you should use #Deprecated. Because else you will end up with users that still use methods/classes that you remove in future builds and their projects will be broken when they update.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I am reading OOPS concepts and got stuck on Abstraction. I am not able to fully understand the concept. As I am feeling that it doesn't belongs to OOPS only. It was also used in C. But how
java abstraction different from C language abstraction. I know it is not a good question
for this forum but i am not able to get the perfect answer.
abstraction means to hide or to separate the complex details of one part of code to other part. say, you have to use a method that does complex calculation, and gives some result. So instead of writing your method inline, its better to write it in a method that just expose the signature (params and return type). in that way your caller (of method) remains unaware of complex code behind the method.
in general, when you use library function in c/c++ or APIs in java, it is also an abstraction.
So indeed, abstraction is not only OOP, but a general concept can be applied anywhere (even beyond the programming).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am scratching my head over understanding the use of a ForwardingMap?
What are the cases that one might use it?
ForwardingXxx classes provide decorator pattern implementations for all JDK and Guava collections, including Map.
Read more on Guava's wiki and in Effective Java 2nd Edition, Item 16: Favor composition over inheritance:
To summarize, inheritance is powerful, but it is problematic because
it violates encapsulation. It is appropriate only when a genuine
subtype relationship exists between the subclass and the superclass.
Even then, inheritance may lead to fragility if the subclass is in a
different package from the superclass and the superclass is not
designed for inheritance. To avoid this fragility, use composition and
forwarding instead of inheritance, especially if an appropriate
interface to implement a wrapper class exists. Not only are wrapper
classes more robust than subclasses, they are also more powerful.
Basically it lets you customize possibly non-extendable Maps without adding dependencies on actual Map implementation.
The default Map classes are all final. That means you can't extend them. When you want to create a map with some special behavior, you need to write your own class which implements the whole Map interface and forwards all methods to an internal Map.
The ForwardingMap makes this simpler for you by already being an extendable class which implements Map and forwards everything to an internal map. That means you can create your own Map implementation by extending it. When you do that, you only need to implement selected methods and not all of them.
One use-case might be a map which automatically validates all entries you put into it or one which automatically updates a database when it's changed.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm looking here at a summary of "interfaces" in Java: http://docs.oracle.com/javase/tutorial/java/IandI/summary-interface.html
The first line states, "An interface defines a protocol of communication between two objects."
Is that really accurate? From my understanding, an interface is just a contract promising to offer some set of members/methods, which could be used by any arbitrary number of clients (so long as they have proper access per the access modifiers). Am I missing some "other side" of the contract which would make an interface "between two objects"?
EDIT: From the answers/comments (and the votes to close! :-[ ), I think I have it figured out. I think I was just getting hooked on the "between two objects" and assuming it meant "between ONLY two objects", which was apparently a wrong assumption. Thanks!
From my understanding, an interface is just a contract promising to
offer some set of members/methods
That's pretty close to the definition of a protocol.
I wouldn't call it inaccurate. If anything, it's just an oversimplification.
You're right that any number of clients can use the object implementing an interface. And for that matter, you would be right to say that the client doesn't have to be an object (it could be a static method in a class, meaning it's hard to say that the client is an object). But the point about defining a protocol for communication is not wrong, even if requires thinking through a different paradigm.
Whenever you use an object you use it always from another object. You don't call a method from more than an object at the same time.
So if A offers an interface, then B relies on it and C too but A is still offering an interface to B and C separately.
The method signatures defined in the Interface are the enforcement. You have the implementer of the interface on one side, and the client on the other who calls the implementer.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have a main class in java which has no attributes and methods. It only contains a main method which calls methods of other classes.
How can I show this class in a UML class diagram?
You should use Association to show this relationship. Association is shown by just connecting two class with a straight line.
If you also want to show the direction of association then you can use directed arrow.
You should question whether you need that class. It doesn't sound like it is performing as an object, instead its a superclass with no meaning within an OO context (ie: it has no meaning within your subject matter, holds no state and performs no actions aside from the main method).
Nothing necessarily wrong with that, but its not considered good practise. I would consider merging that main method into another class that has a meaning within your application.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am experiencing the pain of developing an API based on (Selenium2) Webdriver and here is my dilemma.
I have basically 4 packages:
com.example.qa.pageobject
com.exmaple.qa.setup
com.example.qa.test
com.example.qa.utils
In com.example.qa.test, i have test classes that "USE" classes from other packages.
I am ending up in the following test method.
#Test
public void testScenario16786() {
Login login = new Login();
login.setUp();
AddSingleDomain asd = new AddSingleDomain();
asd.addSingleDomain();
AddARecord ar = new AddARecord();
ar.AddARecordTest();
}
Now, this seems to be a very bad example of developing in Java, which almost seems procedural. Is there any other way of doing it ? Are there some RULES that i need to be aware of while designing an API, which will be used by others ? i am sure that this is somewhat of a classical problem and has been solved before, i just want to know what are the many ways of resolving this, like:
One resolution, could be to use Factory Pattern, and based on a key, a specific class is instantiated, which is good but is there a more elegant way ?
Your test class is necessarily procedural - a repeatable set of steps, that's fine.
The commonly recommended approach is to use the Page Object pattern and selenium also provides a PageFactory object to help you (see end of the page):
page objects
You might find the presentation "How to Design a Good API & Why it Matters" by Joshua Bloch to be helpful.