Respond to comment

_posts/2024-06-12-simpler-encapsulation-with-immutability.html

@@ -164,4 +164,35 @@ <h2 id="comments-header">
         </div>
         <div class="comment-date">2024-06-13 13:55 UTC</div>
     </div>
+
+    <div class="comment" id="3b2e1954394849c4970a1ab30f692192">
+        <div class="comment-author"><a href="/">Mark Seemann</a> <a href="#3b2e1954394849c4970a1ab30f692192">#</a></div>
+        <div class="comment-content">
+            <p>
+                Thank you for writing. The danger of writing these article series is always that as soon as I've published the first one, someone comes by and puts a big hole through my premise. Well, I write this blog for a couple of independent reasons, and one of them is to learn.
+            </p>
+            <p>
+                And you just taught me something. Thank you. That is, at least, an elegant implementation.
+            </p>
+            <p>
+                How would you design the API encapsulating that implementation?
+            </p>
+            <p>
+                Clearly, arrays already have APIs, so you could obviously define an array-like API that performs the appropriate boundary checks. That, however, doesn't seem to model the given problem. Rather, it reveals the implementation, and forces a client developer to think in terms of the data structure, rather the problem (s)he has to solve.
+            </p>
+            <p>
+                Ideally, again channelling Bertrand Meyer, an object should present as an Abstract Data Structure (ADT) that doesn't require client developers to understand the implementation details. I'm curious what such an API would look like.
+            </p>
+            <p>
+                You've already surprised me once, and please do so once again. I'm always happy to learn something new, and that little stars-and-bars concept I've now added to my tool belt.
+            </p>
+            <p>
+                All that said, this article makes a more general claim, although its possible that the example it showcases is a tad too simple and naive to be a truly revealing one. The claim is that this kind of 'aggregate constraint' often causes so much trouble in the face of arbitrary state mutation that most programmers give up on encapsulation.
+            </p>
+            <p>
+                What happens if we instead expand the requirements a bit? Let's say that we will require the user to spend at least 90% of the budget, but no more than 100%. Also, there must be at least three prioritized items, and no individual item can receive more than a third of the budget.
+            </p>
+        </div>
+        <div class="comment-date">2024-06-14 14:22 UTC</div>
+    </div>
 </div>