Earlier quoted context omitted.
Wait, is kevinmahoney.co.uk your blog?
No, just a software engineer
[deleted]
Applying “make invalid states unrepresentable”
31–40 of 193 posts
Re: Applying “make invalid states unrepresentable”
#32Related video on this subject: https://www.youtube.com/watch?v=IcgmSRJHu_8
I thought about that video today when integrating with an old SOAP API. I need to find the name+some property of some persons. Instead of having a list with [(name1, prop1), (name2, prop2),...], I get two distinct lists of [name1, name2,..] and [prop1, prop2,..]. In practice I think the lists will always match. But there is nothing stopping them from not being the same length, or even worse: one having a gap..
Put an assertion. It's better to throw early rather than dealing with wrong data later.
Re: Applying “make invalid states unrepresentable”
#33I'm not sure that this is what I think about, when I think of "Making Invalid States representable" (A concept that I practice).
That said, it's an excellent, commonsense article that describes a highly usable approach to information architecture.
I also agree that OOP programmers have always considered their designs to "represent the 'Real World'™." In my experience, I use OOP constructs to represent many things that should never be exposed to the user (like messages, adapters, states, and state transitions).
There's the classic usability concept of the "Mental Model." That is the model that the user builds in their head, as they navigate the UX. These mental models can be drastically different from what happens internally, and a good UX designer can reinforce a desired model (which the user may then ignore).
Re: Applying “make invalid states unrepresentable”
#34While this is great if you know exactly what you want to achieve, it does “lock you in” those constraints on a more fundamental level. More times than I can count I’ve seen business requirements change to require those “unrepresentable” states, and since you’ve now designed you whole data model around it you need to add awful hacks to make it work. The timeline example is actually very telling. A lot of times you’d a…
Additionally, turning (startDate, endDate) into a set of dates will make the code more complex in some places. Before:
SELECT event FROM events WHERE endDate Whatever additional complexity you
add to your codebase to query end
dates.Re: Applying “make invalid states unrepresentable”
#35Re: Applying “make invalid states unrepresentable”
#36Earlier quoted context omitted.
> I think a large contributor to the problem is story-oriented development, where all that matters in the sprint is "getting it done" and not looking at the broader context. I think that's exactly backwards. This kind of overcomplicated representation usually happens because people put too much effort into designing their representations up front. If you follow story-oriented development and only implement the parts…
To be fair, both are possible scenarios: - A team spends too much time over-engineering a representation for something that could be more easily maintained using a simple model - A team spends too little time considering the edge cases with a representation because they feel pressure to deliver the feature within a short space of time
And they often happen at the same time, too. I've seen situations where developers over-plan a system in advance, then spend ages hacking smaller features and changes into it to meet quick turnaround times, instead of taking proper step back and being aware of when their original design needs to be revised.
Re: Applying “make invalid states unrepresentable”
#37Not certain I get the needless attack on OOP in this text. The error could just as well have happened in any alternative to OO. What is needed is the realization that there is that there is a schedule that needs to have full control over the times to not create coordination issues. That is a realization that is utterly independent of the OOP-ness of the eventual solution.
Re: Applying “make invalid states unrepresentable”
#38While this is great if you know exactly what you want to achieve, it does “lock you in” those constraints on a more fundamental level. More times than I can count I’ve seen business requirements change to require those “unrepresentable” states, and since you’ve now designed you whole data model around it you need to add awful hacks to make it work. The timeline example is actually very telling. A lot of times you’d a…
I agree that this is an issue, but I think the answer is simply using a very flexible basic data representation (which admits invalid state) and then using predicates to refine it. e.g. starting with a list of (start,end) intervals and then adding predicates for valid intervals (start If any of the requirements change, it's easy to either add more predicates or relax/even outright remove them.
Re: Applying “make invalid states unrepresentable”
#39Earlier quoted context omitted.
A set doesn't necessarily imply an ordering (unless this article is about some specific programming language, but it seemed fairly generic to me). e.g. Java and C++ have many Set implementations, some sorted (e.g. a TreeSet) and some not (e.g. HashSet)
That's the point. There's no ordering of the items. So the representation can never have an error like [yesterday, tomorrow, today]. It's just a set of (yesterday, tomorrow, today).
Doesn't that just push all the responsibility onto every piece of code that uses the datatype? 'Remember to sort the contents of this set every time before using it' sounds like it is asking for trouble.