Thanks for your reply Mike! I had a feeling Generics were going to save the
day. So now my interfaces are working easily enough, but I have trouble
once I get to my implementation:
public class HibernateConfirmationDetailsDao<T extends ConfirmationDetails>
extends
HibernateGenericDao<T, Long> implements
ConfirmationDetailsDao<T> {
public HibernateConfirmationDetailsDao() {
super(ConfirmationDetails.class);
}
...
}
The super(ConfirmationDetails.class); line errors, stating: "The constructor
HibernateGenericDao<T,Long>(Class<ConfirmationDetails>) is undefined". I'm
guessing I need something like: super(T.class) but T.class is not valid.
Any idea on how to express this?
Thanks again!
Mike Horwitz wrote:
>
> On Jan 7, 2008 6:11 PM, leojhartiv <[EMAIL PROTECTED]> wrote:
>
>>
>> I'm using the GenericDao approach discussed provided by appfuse.
>>
>> I have a DAO that is used to persist/get
>> ElectronicFormsConfirmationDetails
>> objects, where ElectronicFormsConfirmationDetails extends
>> ConfirmationDetails:
>>
>> public class ElectronicFormsConfirmationDetails extends
>> ConfirmationDetails
>> {
>>
>> private DocumentDeliveryPreferences documentDeliveryPreferences;
>>
>> ...
>> }
>> public class ConfirmationDetails extends IDObject {
>>
>> private TaxEntity taxEntity;
>> private Confirmation confirmation;
>> private ElectionEvent electionEvent;
>> private ActiveStatus activeStatus;
>> private ConfirmationType confirmationType;
>>
>> ...
>> }
>>
>> public interface ElectronicFormsConfirmationDetailsDao extends
>> GenericDao<ElectronicFormsConfirmationDetails, Long> {
>>
>> public ElectronicFormsConfirmationDetails findCurrentElection(
>> TaxEntity taxEntity);
>>
>> }
>>
>>
>> Now I'm going to have additional ConfirmationDetails types that will
>> extend
>> ConfirmationDetails, for instance:
>>
>> public class ServiceProviderConfirmationDetails extends
>> ConfirmationDetails
>> {
>>
>> private AccessType accessType;
>> private ServiceProvider serviceProvider;
>> private boolean participating;
>>
>> ...
>> }
>>
>> And its associated DAO will have many shared methods (but will certainly
>> have some that are unique to ServiceProviderConfirmationDetails):
>>
>> public interface ServiceProviderConfirmationDetailsDao extends
>> GenericDao<ServiceProviderConfirmationDetails, Long> {
>>
>> public ServiceProviderConfirmationDetails findCurrentElection(
>> TaxEntity taxEntity);
>>
>> }
>>
>> I'm finding that I'm generating a great deal of similar code due to this
>> scenario, so I was thinking of creating a ConfirmationDetailsDao, having
>> it
>> extend GenericDao and having the ServiceProviderConfirmationDetailsDao
>> and
>> ElectronicFormsConfirmationDetailsDao extend that:
>>
>>
>> public interface ConfirmationDetailsDao extends
>> GenericDao<ConfirmationDetails, Long> {
>>
>> public ConfirmationDetails findCurrentElection(
>> TaxEntity taxEntity);
>>
>> }
>>
>> public interface ElectronicFormsConfirmationDetailsDao extends
>> ConfirmationDetailsDao {
>> //Nothing yet
>> }
>>
>> public interface ServiceProviderConfirmationDetailsDao extends
>> ConfirmationDetailsDao {
>> //Nothing yet
>> }
>>
>>
>> This way, using Hibernate's polymorphism support, I would think I
>> wouldn't
>> need to write specific findCurrentElection methods for each
>> ConfirmationDetails DAO type.
>>
>> However, I'm not sure this approach is going to work. For instance, if I
>> try to retrieve a ElectronicFormsConfirmationDetails object, using my
>> ElectronicFormsConfirmationDetailsDao:
>>
>> ElectronicFormsConfirmationDetails confirmationDetails =
>> electronicFormsConfirmationDetailsDao
>> .findCurrentElection(taxEntity);
>>
>> I receive the following compile-time error: "Type mismatch: cannot
>> convert
>> from ConfirmationDetails to ElectronicFormsConfirmationDetails"
>>
>> This makes sense, obviously, as my method signature for my
>> ElectronicFormsConfirmationDetailsDao, returns a ConfirmationDetails
>> object
>> as it is declared in the ConfirmationDetailsDao object. I can cast the
>> object and the code works:
>>
>> ElectronicFormsConfirmationDetails confirmationDetails =
>> (ElectronicFormsConfirmationDetails)
>> electronicFormsConfirmationDetailsDao
>> .findCurrentElection(taxEntity);
>>
>> But it feels like a clunky solution to the problem. How can the client
>> know
>> for sure that the returned ConfirmationDetails object is a
>> ElectronicFormsConfirmationDetails subclass?
>>
>> Does anyone have any suggestions on my approach? Is there a better way I
>> can cut down on the redundancy in my DAO code, while not requiring the
>> client to cast calls?
>
>
> The simplest solution would probably be to use generics as per the
> GenericDao. So instead of
>
> public interface ConfirmationDetailsDao extends
> GenericDao<ConfirmationDetails, Long>
>
> Do something like
>
> public interface ConfirmationDetailsDao<T extends ConfirmationDetails>
> extends GenericDao<T, Long>
>
> Mike
>
>>
>>
>>
>> Thanks for your help!
>> Leo
>>
>> --
>> View this message in context:
>> http://www.nabble.com/GenericDao-and-Class-Hierarchy---Approach--tp14672300s2369p14672300.html
>> Sent from the AppFuse - User mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/GenericDao-and-Class-Hierarchy---Approach--tp14672300s2369p14676912.html
Sent from the AppFuse - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
