Update Week4/prep-exercises/1-wallet/README.md

robvk · remarcmij · web-flow · commit 7f816fc9ba7e · 2023-05-04T11:40:26.000+02:00
Co-authored-by: Jim Cramer &lt;remarcmij@gmail.com&gt;
diff --git a/Week4/prep-exercises/1-wallet/README.md b/Week4/prep-exercises/1-wallet/README.md
@@ -31,7 +31,7 @@ As this will not be easy, let's go through a few of the concepts again but then
 
 ### Public Interface vs Private Implementation
 
-Imagine that our various wallet implementations (however simplistic they may be) will be used as libraries by third party developers, perhaps as part of a banking application. We would expect those developers to access the functionality of our wallet through the methods that we provide for that purpose. We consider that to be the _public interface_ of our wallet, i.e. a contract between ourselves as library owner and the users of the library. If third party developers would be allowed to manipulate the internals of the wallet (e.g. `cash`, `dailyAllowance`, etc.) we can no longer guarantee its correct functioning. We consider those internals to be _private implementation details_, and we would want the reserve the right to make implementation changes/improvements. So long as such changes have no impact on what can be observed through the _public interface_ (i.e. we honour the "contract") there should not be a problem.
+Imagine that our various wallet implementations (however simplistic they may be) will be used as libraries by third party developers, perhaps as part of a banking application. We would expect those developers to access the functionality of our wallet through the methods that we specifically provide for that purpose. We consider that to be the _public interface_ of our wallet, i.e. a contract between ourselves as library owner and the users of the library. If third party developers would be allowed to manipulate the internals of the wallet (e.g. `cash`, `dailyAllowance`, etc.) we can no longer guarantee its correct functioning. We consider those internals to be _private implementation details_, and we would want the reserve the right to make implementation changes/improvements. So long as such changes have no impact on what can be observed through the _public interface_ (i.e. we honour the "contract") there should not be a problem.
 
 In the _closure_ version of our wallet the internal values (`cash`, `dailyAllowance`, etc.) are well protected against unwanted modification. Those values are simply not accessible outside of the `createWallet()` function.
 
