CODEWITHSUNDEEP
c#oopdesign-patternsadapterfacade
Eido95
Eido95

Reputation: 1383

Facade vs. Adapter design pattern using network a stream

Let's assume that I have three SDK classes named Phone, DigitalClock and DigitalCompass which representing implicitly digital devices.

These classes supports:

Unfortunately, these classes CANNOT be changed and they don't inheritance from anything.

Now, I have a UDP service and TCP service that supports the following operations:

Problem: I want theese devices will be able to transmit and receive their streams through the internet.

Solutions: I thought about two ways to design the above problem, i tested them and they both work:

  1. Wrap every class with Facade-alike design pattern like so:
    • StreamablePhone, StreamableDigitalClock and StreamableCompass.
    • Every wrapper class will inheritance from IStreamableDevice.

Results: Phone->streams to->StreamablePhone->sends to->UDP Service->transmits to->NET.

  1. Wrap these classes with the Adapter design-pattern like so:
    • Adaptees: Phone, DigitalClock and DigitalCompass classes.
    • Adapters: The UDP service and the TCP service inheritance from interfaces(the following Targets) with matching names (IUdp* with UDP* service, ITcp with TCP service).
    • Targets:
      • UDP targets will be IUdpPhone, IUdpDigitalClock and IUdpDigitalCompass.
      • TCP targets will be ITcpPhone, ITcpDigitalClock nad ITcpDigitalCompass.

Results: Phone->streams to->IUdpPhone->transmit to->NET.

Which way should i choose to implement, consider it supports the scenario when more devices or more network services being add.

Upvotes: 0

Views: 524

Answers (1)

ekostadinov
ekostadinov

Reputation: 6940

One of the main differences in both patterns are the intention of the developer implementing them. In short Façade is:

A single entry-point that represents an entire subsystem

While the Adapter will:

Match interfaces of different classes

So in your case I'll go with the Façade, because you don't want to extend the functionality that is hidden from the Phone. What you're after (if i understand it correctly) is to simplify (and encapsulate) the communication between your sub-system and the Phone (end) devices. So the better match here is the Façade, since it defines a higher-level interface that makes the subsystem easier to use. If you want to read a bit deeper layering it, there is a concept called Federation in the Enterprise application integration.

Another pattern that can be useful here is the Command design pattern, since it encapsulates a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.

Upvotes: 2

Related Questions