• Overview
• Setup
• Problems
• Solution
• Conclusion

• This repository helps me 😊 clarify the interface's robustness as well as its benefits
• This repository will simulate an add-to-cart action of one specific Customer

• We have 2 projects for this demo, DemoLibrary (class library) and Interface (Console):

  

• In DemoLibrary project:

  $\textcolor{gray}{\textsf{CustomerModel}}$

  

  $\textcolor{gray}{\textsf{PhysicalProductModel}}$

  

• In Interface project:

  $\textcolor{gray}{\textsf{Program}}$

  • We simulate an add-to-cart action by calling a $\textcolor{Yellow}{\textsf{AddSampleData()}}$ method
  • We also have a customer that do a add-to-cart action through $\textcolor{Yellow}{\textsf{GetCustomer()}}$ method

Result of the program:

• We get 3 rows as a result of each shipped product listed in the cart to a customer.

  

• Let's say the above code works fine, but in the future, we may have more requirements like the Customer told the development team "I want to sell more products like digital products and it will be sent via the customer's email".

• So we have not touched an interface yet, the solution that is coming to my mind is to create a $\textcolor{gray}{\textsf{DigitalProductModel}}$ and modify an existing code that is already working fine, this modified action is not recommended, it's a risk and takes time to do testing again to make sure it works as expected.

• In this case, this function is standalone, it does not involve other use cases, but if it does, it means we need to retest all of them, which requires more effort to do that.

• One last thing, just look at a $\textcolor{gray}{\textsf{DigitalProductModel}}$, we are violating a DRY principle as well

  

• To solve these problems, we are going to use an Interface, adding and modifying some stuff to do it right.

• Create an Interface named $\textcolor{gray}{\textsf{IProductModel}}$

  

• Create a new class named $\textcolor{gray}{\textsf{DigitalProductModel}}$ and implement $\textcolor{gray}{\textsf{IProductModel}}$, implement for $\textcolor{gray}{\textsf{PhysicalProductModel}}$ as well

  

• Modify a $\textcolor{gray}{\textsf{Program}}$

  • To be able to solve all the problems, I just need to change the data type from $\textcolor{gray}{\textsf{PhysicalProductModel}}$ to $\textcolor{gray}{\textsf{IProductModel}}$ without changing the logic of the code.
  • And one more thing is that I was able to add a digital product to the cart
  • In the future, if our Customers need more types of products, the only thing we do is create a class that represents that type of product and let it implement our Interface and that's done

• The final result:

  

• So after using an Interface, we can see some of the benefits of an Interface:
  • Scalability: Interfaces make our code base more scalable. It shows up when we assume a customer makes a new requirement for a digital product
  • Code Reuse: Let's remember how we achieve DRY principle by creating and implementing an $\textcolor{gray}{\textsf{IProductModel}}$
  • loose coupling: In the first version of $\textcolor{gray}{\textsf{Program}}$, we can see Main method is depend on PhysicalProductModel, I mean this method only allows 1 type PhysicalProductModel. But with Interface, we can achieve a loose coupling
• Interface has many more than 2 benefits, but in this demo, I think that is all I can understand.
• To go into depth for knowledge of Interface, I am going to explore the SOLID principles