What are the things to be kept in mind when aiming for a good class design? [closed]

Question

Yesterday I have attended interview in one Leading IT Service company. Technical interview was good, no issues, then I have moved to another set of round about Management, Design and Process. I have answered everything except the below question.

Question asked by interviewer:

Let say you are developing a class, which I am going to consume in my class by extending that, what are the key points you keep in mind? Ex, Class A, which has a method called "method A" returns a Collection, let say "list". What are the precautions you will take?

My Answer: The following points I will consider, such as:

1. Class and method need to be public
2. Method 1 returns a list, then this needs to be generics. So we can avoid class cast exception
3. If this class will be accessed in a multi-threaded environment, the method needs to be synchronized.

But the interviewer wasn't convinced by my points. He was expecting a different answer from me but I am not able to get his thought process, what he was excepting.

So please provide your suggestions.

Answer 1

I would want you holding to design principles of Single Reaponsibility, Open/Close, and Dependency Injection. Keep it stateless, simple, and testable. Make sure it can be extended without needing to change.

But then, I wasn't interviewing you.

Answer 2

A few more points which haven't been mentioned yet would be:

1. Decent documentation for your class so that one doesn't have to dig too deep into your code to understand what functionality you offer and what are the gotchas.
2. Try extending your own class before handing it out to someone else. This way, you personally can feel the pain if you class is not well designed and thereby can improve it.
3. If you are returning a list or any collection, one important question you need to ask is, "can the caller modify the returned collection"? Or "is this returned list a direct representation of the internal state of your class?". In that case, you might want to return a copy to avoid callers messing up your internal state i.e. maintain proper encapsulation.
4. Plan about the visibility of methods. Draw an explicit line between public, protected, package private and private methods. Ensure that you don't expose any more than you actually want to. Removing features is hard. If something is missing from your well designed API, you can add it later. But you expose a slew of useless public methods, you really can't upgrade your API without deprecating methods since you never know who else is using it.

Answer 3

If you are returning a collection, the first thing you should think about is should I protect myself from the caller changing my internal state e.g.

List list = myObject.getList();
list.retainAll(list2);

Now I have all the elements in common between list1 and list2 The problem is that myObject may not expect you to destroy the contents of the list it returned.

Two common ways to fix this are to take a defensive copy or to wrap the collection with a Collections.unmodifiableXxxx() For extra paranoia, you might do both.

The way I prefer to get around this is to avoid returning the collection at all. You can return a count and a method to get the n-th value or for a Map return the keys and provide a getter, or you can allow a visitor to each element. This way you don't expose your collection or need a copy.