Implement interfaces and abstract classes

At the moment we have classes that are named like ConnectionInterface, using an Interface suffix to indicate that they have implementation expectations.

Those classes are actually abstract classes and should be refactored to behave like one. There are a few exceptions which are or should actually be interfaces that are implemented by other classes instead of extending an abstract class.

[faustbrian]

They would be managed in the same repository. I would restructure the repository to contain 3 folders that are managed by lerna as essentials, optional and types.

• essentials would be packages that are required to run a node like blockchain, pool, etc.
• optional would be packages like api, webhooks, etc.
• types would be packages that contain only the type defs

[paroxysm]

So, I thought about it some more, and even in their own types modules, you’d still have the circular dependency problem if your interfaces need to reference each other(method parameters or instance properties). If they’re all in a single module, they can all see each other so it’s all good, but if they’re in different modules, the types modules would have to have dependencies on each other and you run into the same problem, introducing a circular dependency among the types modules.

The only way that would work is if the dependencies are realized(so app.resolvePlugin<ImportedType>) in the concrete implementation, not on the interface layer, i.e interface Blockchain { get transactionPool() : TransactionPool }. But that isn’t a good approach because it restricts how you write your interfaces(to make sure you don’t reference a type what would result in a circular dependency)