search

OlexG / Patterns

Simples demos of various design patterns in javascript and typescript.
0 stars 0 forks source link

Adapter API is a bit contrived #5

Closed mattfbacon closed 3 years ago

mattfbacon commented 3 years ago

The adapter should not take the target as an argument. Instead there should be a choice between what backend the adapter takes. This is because the adapter right now is specific to Target, yet you could subclass Target to make it incompatible.

Also, it's a bit weird to have the compatible adapter implement IncompatibleAPI. I would suggest renaming that. One way to do it would be to make it a template, where the default for the parameter is any, and you specify it as API<Record<...>> for Adapter.

Finally I think you should add multiple APIs to show how the adapter works with all of them, providing the same API to the client.

mattfbacon commented 3 years ago

This naturally applies to Structural/adapter.ts.

OlexG commented 3 years ago

I followed this source - https://refactoring.guru/design-patterns/adapter. Here the adapter is individual to the target api. I guess the point is that while you want the API to stay the same, the implementation details change which is why it implements IncompatibleAPI.

mattfbacon commented 3 years ago

I understand what you mean that the adapter is individual to the target API but a distinction needs to be made between the interface and the actual adapter. The interface to the adapter should by nature be the same for all adapters whereas the implementation by nature changes. Because of this, the IncompatibleAPI interface is not sufficient to restrict the type of displayList on the adapter because of the any type.