Win a copy of Spring Boot in Practice this week in the Spring forum!

Dinesh Sadhvani

+ Follow
since Apr 04, 2001
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Dinesh Sadhvani

Very good questions as I had similar questions in my mind sometime back.
1.) Most examples I have seen use factory classes to create almost every concrete class in the system. Is there ever a time where you don't need a factory to create a class or it is not a good idea?
Well this is a good design philosophy, which you will see in most systems being built. This is a pattern which a) separates the construction of being scattered across multiple places in code
b)sometimes an appropriate class is instantiated and cast to an interface and returned. (combination of Factory and a Manager). This way client code is shielded with nitty-gritty details and is simply a nice layer to your application. So if you have a code change you have only one place.
2.) Same as the factory classes, most examples I have seen create an interface class for every concrete class in the system. Is there ever a time where this is not needed or not a good idea?
pretty much as explained above.
3.) The Factory and Abstract Factory patterns seem to require that concrete classes inherit from an abstract base class. Is this is a hard requirement or will implementing an interface instead of extending the abstract class abide by the pattern rules as well?
no hard and fast rules as such....Abstract Factories are not typically used all that often in fact. I personally like implementing an interface (u can implement multiple interfaces ...not stuck with one.....
One way of doing this maybe is to have a user-group to role mapping in your tree (or ?). And then the methods in EJB are tied to role(s).
This is pretty interesting. Well I have looked at the EJBController pretty close in our project last year. There are some advantages with using this design:-
-> Higher Abstraction
-> Web-tier is more clearly separated from presentation-tier.
->Scalability is forced as you keep transactions demarcated at EJB / business-tier but not right from Web-tier.
But one should also see the possible limitations:
->Does a extra Controller all that much for me?
as I already have a Controller in Web-tier(Struts, Action Servlet).
-> It may hinder users in case of transactions being passed around from non-EJB environments if supported in future.
We decided not to go with this approach as it seemed overkill and we used a simple Business Delegates which use Service Locators and obtain the appropriate Service.
Well two things here
one is a simple object passing yes u can pass objects declare <struct>'s in CORBA idl. U can return these or pass these (in or inout or out).

another is Pass-by-Value with CORBA 2.3 u can pass objects by Value using the Value and ValueHolder interfaces.

Hope it helps
21 years ago
CORBA: Its used primarily if you have legacy apps and u want to connect with your app. So a Java (CORBA)client can call C++/COBOL/JAVA/... CORBA Server.
EJB: provide you much more than CORBA with all services like Security,Transactions,Concurrency etc......
Theres no such advantage of using CORBA and EJBs together, if possible one shud use only one of them as there are some disdvantages to using CORBA with EJBs i.e. u cannot propogate your security context, transacation context from CORBA. Plus the disadvantage of using CORBA is lack of **good***polymorphic remote object support...remember the narrow and then cast the requirement of RMI-IIOP......
21 years ago