In one of my recent interviews, I was asked about the following questions, where in my answers were not so satisfactory. Can some one look into this and give me some compelling answers.
1) Difference between BusinessDeligate Vs SessionFacade ? My answer : BusinessDeligate provides a kind of transparancy to the client about the business methods. It basically decouples the client and business objects. BusinessDeligates are usually implemented by POJO's and would interact with ServiceLocator to find the remote objects, cache them etc. SessionFacade is a kind of interface for all business calls. It is adviced to have every business call go through SessionFacade. It is usually implemented by Stateless session bean and preferably it will have local interfaces with EntityBeans.
My answer was satisfactory neither to me nor to my interviewer. Can some one explain me in a better way. Does, in a design issue is it adviced to have both of them in place , Does each of them compliment each other, Does they replace each other, Can they be used alternatively.
2) Which is preferred Abstract Classes vs Interface, if so why ? MyAnswer: I said I would prefer Interface, as I can provide multiple implementations for the same interface. Then he immediately said, abstract classes can be inherited and we can provide different implementations as we like.
What is the correct explanation for this. Also why implementing an interface is preferred over inheriting. Is this a thumb rule or context based? I believe it should be a context based. If we have some default behaviour already availabl, we can make use of that by inheriting it.
Thanks & Regards, SK
SCJP 5.0, DB2 - 800, DB2 - 803, SCDJWS (On the way)
I'm not very familiar with enterprise design patterns in practice. But for your second question I'd say interfaces are generally preferable because one class can implement multiple interfaces whereas you can only inherit from one base class (in Java). Moreover totally different classes could implement the same interface to provide some common features or methods but it's mostly bad design to use inheritance just to express some common functionality for otherwise different classes. Inheritance should only be used when it's a true is-a relationship between a subclass and a superclass. Also you can treat a class which implements multiple interfaces as a type of each interface at runtime without the need to create different subclasses.
In my opinion these are at least the most important reasons to prefer interfaces over inheritance...
An abstract base class perhaps would be preferable if you want to provide some functionality for subclasses they should or must use. For this you could implement some methods and leave other methods abstract for implementation by subclasses.
You can even go further by factoring out all the code in the generic implementation into smaller classes so that most of the generic code simply delegates to those classes. That way you can still reuse most of the code used by the generic implementation even if you can't directly inherit from it.
In my opinion, the "correct" answer to 2) is "it depends". There are even situations where it's best to use both in concert.
Most probably, the interviewer wasn't looking for the one right answer, but was looking for whether you were able to have an intelligent discussion on the issue.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Oct 20, 2007
Thanks to you all for clarifying my doubts and thanks for providing a link on Business Deligate and Session Facade.
From the thread provided on Business Delegate and Session Facade, I see that SessionFacade is implemented as a Singleton pattern and usually SessionFacade is implemented using Statelss session beans. Now can we control that there would be only one Stateless Session bean acting as a SessionFacade, as bean lifecycle is dependent on container.
Also I remember reading some where that, all transactions should always begin in SessionFacade and end in same session facade. Is this correct? If so, can some one explain me concept here.
Simply put, a Session Facade provides the client with a high level application service interface; while Business Delegate gears towards reducing the compexity of accessing a business function/component. Both of them can create a high level function thats interacts with multiple business objects to simplify the calling.
Both of them are designed to reduce the coupling between the client and the business components.
Client -> BDs -> BCs(distributed)
Client -> SF -> BCs(destributed or local)
Client -> SF -> BDs-> BCs(destributed or local) --------------> BCs(destributed or local) [ June 29, 2008: Message edited by: Peter Hu ]
2) Which is preferred Abstract Classes vs Interface, if so why ?
Abstract class & Interface implementation are based upon system requirements with regards to class design.Abstract class would be a choice of advantage if we need to add any extra concrete functions in future without breaking classes that provides implementation for it. Interface would be of usefull if we are confirmed & final with it and we dont expect to have further functionalities in it.
Originally posted by Schandha Ravi: [QB] 2) Which is preferred Abstract Classes vs Interface, if so why ? QB]
A class has two parts - "what" & "how" "What" part is - method signatures "How" part is - method definitions Now, You know "what" is the class going to do, but not sure "how" it is going to do, then go for Interface. The "how" can be realized by many ways.
You know the "what" part and also know the "how" part but this "how" part can have some variations, then go for Abstract
You can't wake a person who is <b><i>pretending</i></b> to be asleep.<br />Like what <b>"it"</b> does not like - <i> Gurdjieff </i>