Interface class

Question

I do not understand how I can use the class interface. I have read many articles and tutorials about OOP related to an interface class, so I know what an interface is, but I understand how to use it in a real project.

For instance,

I made an IPayment interface class. and I have defined 2 methods that use common to all payment classes.

public interface IPayment { void MakePayment(OrderInfo orderInfo); void MakeRefund (OrderInfo orderInfo); } 

I made 3 classes of payments, which are CreditCardPayment, PaypalPayment and GooglePayment.

and I defined 2 methods in each class.

I got confused in this part, I need to create an OrderInfo class that contains order information that should be used to process the payment or refund. And each class needs different information.

CreditCartPayment class requires credit card No, expiry date .... But there is no other payment class.

And the GooglePayment class needs a Google order number, but there is no other class.

So finally, the OrderInfo class should have a lot of extra field. And it looks so dirty ...

Ex)

 Public class OrderInfo { /* For Common */ string orderNo {get; set;} string customerNo { get; set;} decimal amount {get; set;} /* For Credit Card */ string CCNum {get; set;} string expDate { get; set;} /* For Google */ string googleOrderID {get; set;} ... /* For Paypal */ ... } 

My question is:

In this case, is it right to use IPayment? or do I need to define each class with the correct parameters without an interface class?

I assume that the advantage of using an interface class is to easily define a payment class later. because the Interface class will show which methods are defined in each payment class. are there any other pros?

and do you have any tips for understanding the interface of an interface in the real world?

[EDIT]

Thanks for all the tips.

I am writing code examples again. could you view this code?

 public interface IPayment { void MakePayment(OrderInfo orderInfo); // !! void MakeRefund (OrderInfo orderInfo); // !! } public class OrderInfo { protected string OrderNo {get; set;} protected string CustomerNo { get; set;} protected decimal Amount {get; set;} } public class CreditCardPaymentInfo : OrderInfo { string CCNum {get; set;} string ExpDate { get; set;} } public class GooglePaymentInfo : OrderInfo { string GoogleOrderID {get; set;} } public class PaypalPaymentInfo : OrderInfo { string PaypalID {get; set;} } public void MakePayment() { IPayment paymentModule; // Get Order Info if(orderType == "Paypal"){ paymentModule = new PaypalPayment(); PaypalPaymentInfo orderInfo = new PaypalPaymentInfo(); orderInfo.PaypalID = "TEST"; }else if(orderType == "Google"){ paymentModule = new GooglePayment(); GooglePaymentInfo orderInfo = new GooglePaymentInfo(); orderInfo.GoogleOrderID = "TEST"; }else{ paymentModule = new CreditCardPayment(); CreditCardPaymentInfo orderInfo = new CreditCardPaymentInfo(); orderInfo.CCNum = "1111111111111111"; orderInfo.ExpDate = "11/11"; } orderInfo.OrderNo = "123"; orderInfo.CustomerNo = "ABC"; orderInfo.Amount = 12.20m; paymentModule.MakePayment(); } 

An error occurs:

Error 1 'com.WebUI.Models.CreditCardPaymentInfo' does not implement the member of the interface 'com.WebUI.Models.IPaymentProcess.makeRefund (WebUI.Models.RefundModel)'

I think I need to fix the interface class. Does anyone know how to fix it?

Answer 1

One approach is to make OrderInfo base class and subclass its provider-specific types, for example:

 public class OrderInfo { /* For Common - Protected members are accessible to subclasses! */ protected string OrderNo {get; set;} protected string CustomerNo { get; set;} protected decimal Amount {get; set;} } public class CreditCardPaymentInfo : OrderInfo { /* For Credit Card */ string CCNum {get; set;} string ExpDate { get; set;} } public class GooglePaymentInfo : OrderInfo { /* For Google */ string GoogleOrderID {get; set;} ... } public class PaypalPaymentInfo : OrderInfo { /* For Paypal */ ... } 

Then you can implement your Payment classes like this and fulfill the requirements of the IPayment interface:

 public class PaypalPayment : IPayment { public void MakePayment(PaypalPaymentInfo orderInfo) { ... } public void MakeRefund (PaypalPaymentInfo orderInfo) { ... } } 

Since PaypalPaymentInfo can be used wherever OrderInfo is OrderInfo , this is a valid implementation of IPayment . You can follow the same pattern for your credit card and Google payments.

Answer 2

The correct way to implement this is to make a class for each type of payment, but use them as a general IPayment . So you will have:

public class CreditPayment : IPayment

public class GooglePayment : IPayment

public class PaypalPayment : IPayment

Then use the payment:

 public class PaymentUser { private IPayment _payment; public PaymentUser(//args) { //Which payment to be used would be based on args. Using a factory here is common _payment = new CreditPayment(//args); } } 

Now you have an IPayment that was created for you, and you don't care what type he does not know if he will fulfill your contract!

So, somewhere along the line you can say

 public void MakePayment(OrderInfo order) { _payment.MakePayment(order); } 

And you don’t even know what type of IPayment you used. This increases extensibility because you don’t care what type this method executes if it adheres to the IPayment interface.

Answer 3

Let me explain this with a simple example.

Think of a simple method (e.g.,) by saying int rectanglePerimeter(int x, int y) . This method simply takes two numbers, multiplies them and returns the result. Now you can implement it in two ways:

first: using multiplication

  return x*y; 

second: by adding

  int res = 0; for(int i=0; i< length; i++){ res+= width; } return res; 

Now, if you want the consumer code of this method not to be implementation dependent, you can simply define an Interface that has the method signature as int rectanglePerimeter(int x, int y) . This can be implemented by different implementation structures in different ways, but everyone will have to adhere to the definition of the method, and your consumer code template will not change depending on the implementation.

Now let's look at a more practical example of Database queries execution using the Connection interface. Since there are several database providers, they all have different implementations (database drivers) to support connecting to the database, but they all support the same methods as in the Connection interface, for example. commit() , createStatement() , rollback() and close() .

This makes use of implementation independent. As you can imagine, Interface serves as a service contract between consumers and service providers. It is possible that both consumers and service providers are your own classes or may be from two different groups / organizations.

Answer 4

I will give you an example of how the interface works. In any case, you have many aspects to using the interface.

Interface inheritance (aka type inheritance): This is also known as subtyping. Interfaces provide a mechanism for determining the relationship between other unrelated classes, usually by specifying a set of common methods, each of which the implementation class must contain. Inheritance of interfaces contributes to the development of the concept of a program for interfaces not for Implementation. It also reduces the dependency of communication or implementation between systems. In Java, you can implement any number of interfaces. This is more flexible than implementation inheritance, as it does not block you from specific implementations that make it difficult to maintain subclasses. Therefore, care should be taken not to disrupt the implementation of classes by changing interfaces.

Example:

Suppose we have a class called Person .

Person contains such fields as: age, first name, last name, identifier, military identifier (for example, for military service), place of work, etc. Now you want to provide personal information to several institutions, such as work, army, facebook. Your job doesn’t want to hear all about your military facebook ID or pseudonym. Therefore, we create several interfaces: MilitaryItf, WorkItf , WebPersonItf . In . In WebPersonItf you define methods get / set Nick name, First Name, gmail and so on. In Nick name, First Name, gmail and so on. In MilitaryItf you provide get / set` for age, health, military ID, start and end dates of service .... Finally, each agency uses only the interested methods received from "Person".

Answer 5

The interface is used to use classes that are not inherited from the same base. What you did for the three classes looks great. But you can also create a "base class" that you can use to inherit functions in your interface.

Your problem with OrderInfo is not related to the interface, but to the fact that you basically need a different type of object. More or less, your interface is not suitable for your CreditCartPayment class.

One way is to create a class that inherits the OrderInfo class, say CredidCardOrderInfo and use it with the CreditCardPayment class. You can use any instance of the CreditCardOrderInfo class, as if it were an instance of OrderInfo . Then you add the line

 CreditCardOrderInfo info = orderInfo as CreditCardOrderInfo; if (info == null) throw new ArgumentException("orderInfo has no credit card order info"); 

It keeps things together ... but still dirty.

Answer 6

The purpose of the interface is to allow an entity that contains a reference to an object that implements it in order to use this object, not knowing which of the possible possible implementations may turn out to be. Thus, an interface should, as a rule, define only methods that will be potentially useful for all classes that implement it.

Based on your scenario, it looks like it is not an interface for a payment processing class, but rather an IOrderWithPayment interface, for objects that need to encapsulate some information about the order form and a payment processor object that can accept it (i.e. specific information about order). Then this interface will have MakePayment and MakeRefund methods that transmit order information to the payment processor. An object containing IOrderWithPayment would not have to worry about what type of order information or a payment processor was encapsulated inside it, since each class that implements IOrderWithPayment encapsulates order information and payment processors that are compatible with each other.

Please note that one common class could be defined that could handle all compatible combinations of order-information objects and a payment processor, provided that these objects included suitable declarations of what they can accept, but some pretty advanced concepts. At the moment, it is probably easier to identify the various types that encapsulate compatible combinations of objects.