From cf79a6edcbc76ce1917dbd95c038fb56964d11ed Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andrei=20B=C4=83ncioiu?= Date: Mon, 16 Sep 2024 12:20:37 +0300 Subject: [PATCH] Adjust guidelines. --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index 0dbbc93..0b32b61 100644 --- a/README.md +++ b/README.md @@ -39,6 +39,8 @@ One controller is backed by **one transaction factory and one outcome parser** ( Generally speaking, it's recommended to receive input parameters as abstractions (interfaces) in the public API of the SDKs. This leads to an improved decoupling, and allows for easier type substitution (e.g. easier mocking, testing). +Exception to the rule above: when receiving easily constructable objects (plain structures, DTOs) as input parameters, it's perfectly fine to receive them as concrete types. + Generally speaking, it's recommended to return concrete types in the public API of the SDKs. The client code is responsible with decoupling from unnecessary data and behaviour of returned objects (e.g. by using interfaces, on their side). The only notable exception to this is when working with factories (abstract or method factories) that should have the function output an interface type. For example, have a look over `(User|Validator)WalletProvider.generate_keypair()` - this method returns abstract types (interfaces). ### **`pay-attention-to-types`**