CODEWITHSUNDEEP
javaoopinterface
GlaIZier
GlaIZier

Reputation: 835

Is it better to create universal DAO or separate it to the smaller ones in this situation?

I have been involved into a Java project that gets payment information from different payment agents, processes it and stores to our billing system (database).

As we had different agents and thus different payment protocols we had sometimes similar and sometimes different methods to work with payments. Some protocols require to add, check and remove payments, some required check status of payment and add payment, and others require to implement very specific to protocol methods. So it is difficult to design hierarchy of DAO interfaces.

Eventually we created a universal DAO interface that supports all of possible methods to do with payments and one implementation of this DAO interface for each payment agent. In case of payment agent doesn't support specific method implementation throws UnsupportedOperationException(). E.g.:

    piblic interface Dao {
        void addPayment(Payment p);
        void removePayment(Payment p);
        ...
        String getVersion();
    }

    public PaymentAgentDao implements Dao {
        public void addPayment(Payment p) {...}
        public void removePayment(Payment p) {...}
        public String getVersion() {
            throw new UnsupportedOperationException();
        }
    }

    public AnotherAgentDao implements Dao {
        public void addPayment(Payment p) {...}
        public void removePayment(Payment p) {
            throw new UnsupportedOperationException();
        }
        public String getVersion() {...}
    }

I'm wonder is it the best way to handle such situation? Another way is to create specific interfaces (I principle in SOLID) but there will be code duplicity because of the impossibility to create interfaces hierarchy. There are no base methods that supports all payment agents. What is the best practice to handle such situations?

Upvotes: 1

Views: 167

Answers (1)

evgenii
evgenii

Reputation: 1235

I think it's correct what you've got, but it can be slightly improved.

  • I think better name for the interface is Agent or even PaymentAgent, because that is the type of the objects in the system. I'd insist you have single type for all those, but the objects are going to be different like people - all similar, but do same things a bit differently. So, one agent simply does the payment, another one checks something, third one can do black magic...

  • In addition to interface I'd create an abstract class PaymentAgentAdapter with all the methods concrete, but doing nothing. This way all concrete objects of those agents would need to implement only methods, which they actually need. This helps having code a bit shorter.

  • I would consider throwing UnsupportedOperationException an inconvenience or even incorrectness as it'd require to try-catch all the methods of an Agent on client side.

Upvotes: 1

Related Questions