3 ms·

When it comes to interface design, I draw top & down to middle. Find what interface or mechanism that is the common thing that makes the lower-level agnostic an

When it comes to interface design, I draw top & down to middle. Find what interface or mechanism that is the common thing that makes the lower-level agnostic and the upper-level about applying or reapplying that mechanism in varying contexts. Some might call that thing a 'narrow waist' but I don't quite equate it to that although it's a good example. Is the thing you want a stream of bytes, sequence of messages, unsequenced messages, or priority-ordered messages? The problem with bottom-up is that you don't know the context. The problem with top-down is that you do know the context--and can leak it into what should be without. I find the latter works out better if you're aware of avoiding it. How do you avoid not having context without going top-down? An analogy in UX would be Windows vs Mac. Windows builds things then puts the UI on what they've built--in many different kinds of settings places. Mac figures out what information & controls the user should have and how to name and group them. Edit: I actually have a recent real-world example. Making a subsystem for querying and mutating things, what they are doesn't matter. We set out making an 'adjust' operation and a 'move' operation because we wanted to preserve paired decrement/increment amount for moves. We were also certain that we only needed to move between two things, or adjust many things but only of one kind. We got all the way up to the top where the public API was getting close to complete. We discovered use-cases that made sense to to more than those operations. We were able to shuffle things around and ended up with a fully-capable 'adjust' operation that can work on any number of kinds/things, and a fully-capable 'move' operation that can work on any number of kinds/things. On top of that we added checks to only do what we need now. The more general things were substantially harder to make work efficiently which is why we chose not to do it when we were sure we didn't need it. We were wrong.

mirekrusin 4y ago
I don't get what you're trying to say. You know the context. You have the whole problem in front of you. The question is about which direction you're going to solve it. For "you want a stream of bytes, sequence of messages, unsequenced messages, or priority-ordered messages?" the answer is you probably want type parametrized iterator at this level if you can ask this kind of question. To put it in other words you put more attention into trying to find underlying composition of algebras in problems than doing adhoc, inlined imperative constructions littered with if statements that you add every time some issue is discovered.
- karmakaze 4y ago
  An example of what I'm describing is separation of mechanism and policy, but not specifically in the sense of OS authorization. The policy is where the different contexts are applied and the machanism is free of context but capable of executing it.
- karmakaze 4y ago
  I didn't understand what this meant when I first read it. Now I see it's basically saying the same thing as I was trying to get across. The "underlying composition of algebras" are the mechanisms and policies with the components being the mechanisms and the differing compositions being the policies chosen when used. If this same pattern can be used for all problems, then you're effectively skipping the step where in my case I would find a partially pre-composed set and make that the interface.

mirekrusin 4y ago

I don't get what you're trying to say. You know the context. You have the whole problem in front of you. The question is about which direction you're going to solve it. For "you want a stream of bytes, sequence of messages, unsequenced messages, or priority-ordered messages?" the answer is you probably want type parametrized iterator at this level if you can ask this kind of question. To put it in other words you put more attention into trying to find underlying composition of algebras in problems than doing adhoc, inlined imperative constructions littered with if statements that you add every time some issue is discovered.

karmakaze 4y ago
An example of what I'm describing is separation of mechanism and policy, but not specifically in the sense of OS authorization. The policy is where the different contexts are applied and the machanism is free of context but capable of executing it.
karmakaze 4y ago
I didn't understand what this meant when I first read it. Now I see it's basically saying the same thing as I was trying to get across. The "underlying composition of algebras" are the mechanisms and policies with the components being the mechanisms and the differing compositions being the policies chosen when used. If this same pattern can be used for all problems, then you're effectively skipping the step where in my case I would find a partially pre-composed set and make that the interface.