You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: separated-interface/README.md
+77-56Lines changed: 77 additions & 56 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,26 +3,31 @@ title: Separated Interface
3
3
category: Structural
4
4
language: en
5
5
tag:
6
-
- Decoupling
6
+
- API design
7
+
- Decoupling
8
+
- Interface
7
9
---
8
10
11
+
## Also known as
12
+
13
+
* API Segregation
14
+
* Client-Server Interface
9
15
10
16
## Intent
11
17
12
-
Separate the interface definition and implementation in different packages. This allows the client
13
-
to be completely unaware of the implementation.
18
+
To define a client interface in a separate package from its implementation to allow for easier swapping of implementations and better separation of concerns.
14
19
15
20
## Explanation
16
21
17
22
Real world example
18
23
19
-
> An Invoice generator may be created with ability to use different Tax calculators that may be
20
-
> added in the invoice depending upon type of purchase, region etc.
24
+
> Consider a restaurant where the menu (interface) is separate from the kitchen operations (implementation).
25
+
>
26
+
> In this analogy, the menu lists the dishes customers can order, without detailing how they are prepared. Different restaurants (or even different chefs within the same restaurant) can use their own recipes and methods to prepare the dishes listed on the menu. This separation allows the restaurant to update its menu or change its chefs without disrupting the overall dining experience. Similarly, in software, the Separated Interface pattern decouples the interface from its implementation, allowing changes and variations in the implementation without affecting the client code that relies on the interface.
21
27
22
28
In plain words
23
29
24
-
> Separated interface pattern encourages to keep the implementations of an interface decoupled from
25
-
> the client and its definition, so the client is not dependent on the implementation.
30
+
> Defines a client interface separate from its implementation to allow for flexible and interchangeable components.
26
31
27
32
A client code may abstract some specific functionality to an interface, and define the definition of
28
33
the interface as an SPI ([Service Programming Interface](https://en.wikipedia.org/wiki/Service_provider_interface)
@@ -33,104 +38,120 @@ code at runtime (with a third class, injecting the implementation in the client)
33
38
34
39
**Programmatic Example**
35
40
36
-
**Client**
37
-
38
-
`InvoiceGenerator` class accepts the cost of the product and calculates the total
39
-
amount payable inclusive of tax.
40
-
41
-
```java
42
-
publicclassInvoiceGenerator {
41
+
The Separated Interface design pattern is a software design pattern that encourages the separation of the definition of an interface from its implementation. This allows the client to be completely unaware of the implementation, promoting loose coupling and enhancing flexibility.
43
42
44
-
privatefinalTaxCalculator taxCalculator;
43
+
In the given code, the `InvoiceGenerator` class is the client that uses the `TaxCalculator` interface to calculate tax. The `TaxCalculator` interface is implemented by two classes: `ForeignTaxCalculator` and `DomesticTaxCalculator`. These implementations are injected into the `InvoiceGenerator` class at runtime, demonstrating the Separated Interface pattern.
The tax calculation logic is delegated to the `TaxCalculator` interface.
47
+
First, we have the `TaxCalculator` interface. This interface defines a single method `calculate` that takes an amount and returns the calculated tax.
61
48
62
49
```java
63
50
publicinterfaceTaxCalculator {
64
-
65
51
doublecalculate(doubleamount);
66
-
67
52
}
68
53
```
69
54
70
-
**Implementation package**
71
-
72
-
In another package (which the client is completely unaware of) there exist multiple implementations
73
-
of the `TaxCalculator` interface. `ForeignTaxCalculator` is one of them which levies 60% tax
74
-
for international products.
55
+
Next, we have two classes `ForeignTaxCalculator` and `DomesticTaxCalculator` that implement the `TaxCalculator` interface. These classes provide the concrete logic for tax calculation.
The `InvoiceGenerator` class is the client that uses the `TaxCalculator` interface. It doesn't know about the concrete implementations of the `TaxCalculator` interface. It just knows that it has a `TaxCalculator` that can calculate tax.
These both implementations are instantiated and injected in the client class by the ```App.java```
105
-
class.
95
+
Finally, in the `App` class, we create instances of `InvoiceGenerator` with different `TaxCalculator` implementations. This demonstrates how the Separated Interface pattern allows us to inject different implementations at runtime.
106
96
107
97
```java
108
-
var internationalProductInvoice =newInvoiceGenerator(PRODUCT_COST, newForeignTaxCalculator());
98
+
publicclassApp {
99
+
publicstaticfinaldoublePRODUCT_COST=50.0;
109
100
101
+
publicstaticvoidmain(String[] args) {
102
+
var internationalProductInvoice =newInvoiceGenerator(PRODUCT_COST, newForeignTaxCalculator());
In this way, the Separated Interface pattern allows us to decouple the interface of a component from its implementation, enhancing flexibility and maintainability.
* Java's JDBC (Java Database Connectivity) API separates the client interface from the database driver implementations.
130
+
* Remote Method Invocation (RMI) in Java, where the client and server interfaces are defined separately from the implementations.
131
+
132
+
## Consequences
133
+
134
+
Benefits:
135
+
136
+
* Enhances flexibility by allowing multiple implementations to coexist.
137
+
* Facilitates testing by allowing mock implementations.
138
+
* Improves maintainability by isolating changes to specific parts of the code.
139
+
140
+
Trade-offs:
124
141
125
-
* You are developing a framework package, and your framework needs to call some application code through interfaces.
126
-
* You have separate packages implementing the functionalities which may be plugged in your client code at runtime or compile-time.
127
-
* Your code resides in a layer that is not allowed to call the interface implementation layer by rule. For example, a domain layer needs to call a data mapper.
142
+
* Initial setup might be more complex.
143
+
* May lead to increased number of classes and interfaces in the codebase.
* Adapter: Adapts one interface to another, which can be used alongside Separated Interface to integrate different implementations.
148
+
* Dependency Injection: Often used to inject the implementation of a separated interface, promoting loose coupling.
149
+
* Bridge: Separates an object’s interface from its implementation, similar to Separated Interface but usually applied to larger-scale architectural issues.
*[Patterns of Enterprise Application Architecture](https://www.amazon.com/gp/product/0321127420/ref=as_li_qf_asin_il_tl?ie=UTF8&tag=javadesignpat-20&creative=9325&linkCode=as2&creativeASIN=0321127420&linkId=e08dfb7f2cf6153542ef1b5a00b10abc)
153
+
*[Design Patterns: Elements of Reusable Object-Oriented Software](https://amzn.to/3w0pvKI)
154
+
*[Effective Java](https://amzn.to/4cGk2Jz)
155
+
*[Pattern-Oriented Software Architecture Volume 1: A System of Patterns](https://amzn.to/3xZ1ELU)
156
+
*[Patterns of Enterprise Application Architecture](https://amzn.to/3WfKBPR)
157
+
*[Separated Interface - Martin Fowler](https://www.martinfowler.com/eaaCatalog/separatedInterface.html)
0 commit comments