array List Program

[shriya hegde]

Hi,

I had been to an interview and they asked me this question.

Employee class has an arrayList of Employee Object with id (long), name(Sting), lname(string).
Employee class will not extend comparable or comparator.

There is a Test class which has 2 methods which will takes empList as argument.
First method should remove duplicate objects (duplicate with respect to id) fom array List
Second method should sort empList array on first name.

Could you please guide me how to implement these 2 methods.

[Joanne Neal]

Well presumably you gave the interviewer some sort of answer. What did you tell/show him ? What makes you think it was wrong ? Did the interviewer give you any feedback ?

[shriya hegde]

For removing duplicates we can put it in set. But I didn't know how to implement it exactly.

To sort first I said Employee can extend comparable or comparator. And then he said think that Employee class was writeen by somebody else and it
doesnt extend comparator and comparable then what you ll do

[Joanne Neal]

If you are going to put them into a Set, you might as well choose a SortedSet of some sort. So then you look at the javadoc for SortedSet and see what classes implement it. Then look at the Javadoc for those classes and see if there is any way they can handle objects that don't implement Comparable.

[dennis deems]

You can always write a comparator external to the class it compares. In fact I prefer this, as I find classes that implement their own comparator to be kind of ugly.

[Winston Gutkowski]

Dennis Deems wrote:You can always write a comparator external to the class it compares. In fact I prefer this, as I find classes that implement their own comparator to be kind of ugly.

Hmmm. Not so sure about that. Firstly, what is equals() if not a form of comparison? Also, some classes (eg, Integer, String ...) simply scream "Comparable" to me.

My solution, if you're interested, is a NaturalOrder class that extends Comparator and emulates a Comparable class's "natural" order. That way, you can always use a Comparator if you want. I also have an InverseOrder one.

Winston

[dennis deems]

Winston Gutkowski wrote:

Dennis Deems wrote:You can always write a comparator external to the class it compares. In fact I prefer this, as I find classes that implement their own comparator to be kind of ugly.

Hmmm. Not so sure about that. Firstly, what is equals() if not a form of comparison? Also, some classes (eg, Integer, String ...) simply scream "Comparable" to me.

I said "Comparator", not "Comparable". An instance of a class which implements Comparable can compare itself to another instance. A Comparator is a utility that can compare two instances of some class.

[Joanne Neal]

Dennis Deems wrote:You can always write a comparator external to the class it compares. In fact I prefer this, as I find classes that implement their own comparator to be kind of ugly.

That's what I was trying to hint at. I was hoping the OP would learn to user Javadoc to find solutions to his problem.

[Winston Gutkowski]

Dennis Deems wrote:I said "Comparator", not "Comparable". An instance of a class which implements Comparable can compare itself to another instance. A Comparator is a utility that can compare two instances of some class.

Erm, yes. I do understand the distinction. Perhaps I didn't understand your "I find classes that implement their own comparator to be kind of ugly" statement.

A Comparator is simply an alternate ordering. Nothing more, nothing less. Perhaps it's my background in databases, but I understand that tables (or collections) in Java cannot always be ordered the way we would like (cf. secondary indexes in a database). My solution simply allows any ordering, including the class's own, to be provided by a Comparator. Don't you think that might make the design of a new ordered collection or sort more straightforward?

Winston

[dennis deems]

Winston Gutkowski wrote:

Dennis Deems wrote:I said "Comparator", not "Comparable". An instance of a class which implements Comparable can compare itself to another instance. A Comparator is a utility that can compare two instances of some class.

Erm, yes. I do understand the distinction.

Then why are you using them interchangeably? You seem to be saying that wherever it is appropriate to implement Comparable, it is therefore also appropriate to implement Comparator.

Perhaps I didn't understand your "I find classes that implement their own comparator to be kind of ugly" statement.

To my mind, it violates the principle of separation of concerns. Why should any arbitrary instance of class Bottle be able to sort a collection of Bottles? That's straying somewhat from the task a Bottle is intended for.

A Comparator is simply an alternate ordering. Nothing more, nothing less. Perhaps it's my background in databases, but I understand that tables (or collections) in Java cannot always be ordered the way we would like (cf. secondary indexes in a database). My solution simply allows any ordering, including the class's own, to be provided by a Comparator. Don't you think that might make the design of a new ordered collection or sort more straightforward?

I think your NaturalOrder and InverseOrder ideas are great. But I don't see how that supports the notion that a class implementing its own Comparator is a good idea. I think it's wrong for the design of a class to be influenced by whatever may or may not be happening in a database.