Amazon.com is perhaps a better example. That site has multiple sign-in levels. It's not a binary state. I'm not sure what names they use, but I'll call them signed-in, signed-in-untrusted, and signed-out.
If you are fully signed-in, you can purchase something or make account changes. If you are signed-in-untrusted, you can put things in the cart associated with your account, but you can't purchase anything without typing a password. If you are signed out, you are fully dissociated from any account.
Note that you can refactor that single trinary property into two binary properties: signed-in/signed-out and trusted/untrusted. (Signed-out+trusted happens to be unused.)
Perhaps it's obvious, but it's true that every multi-state property (or set of properties) can be broken down into a set of binary properties like that, and the breakdown can be done in multiple ways. The resulting binary properties may not be have sensible names as they do in my example, but it can be done. In general, find all possible combinations of values for your set of many-state properties. Enumerate those combinations and write the numbers in binary. Each binary digit is a property in your new set of binary properties. There are multiple possible enumerations, so there are multiple possible mappings from a set of many-state properties to a set of binary properties.
For example, if you have a three-state property and a four-state property, then you'll a combination of 12 possible states. Number those 12 states. Write those numbers in binary. You'll need at least four binary digits. That means you'll have at minimum four binary properties. Those four properties can have 16 total states, so four of the states will be unused.
You can similarly decompose your properties into a set of three-state properties by writing your enumeration in base-three. I suppose you could also consider the current state of your program, with it's many multi-state properties (integers have lots of possible states, strings have even more), to be a single variable-base number that enumerates a state in the state-space of your program. If you consider the remaining input to your program to be part of your state, and the set of all possible outputs to be enumerated in a similar fashion, then the problem of programming is reduced to the building of a machine that maps numbers from one set to numbers in another. How hard can that be? So I'll need your project done by Monday.
If you are fully signed-in, you can purchase something or make account changes. If you are signed-in-untrusted, you can put things in the cart associated with your account, but you can't purchase anything without typing a password. If you are signed out, you are fully dissociated from any account.
Note that you can refactor that single trinary property into two binary properties: signed-in/signed-out and trusted/untrusted. (Signed-out+trusted happens to be unused.)
Perhaps it's obvious, but it's true that every multi-state property (or set of properties) can be broken down into a set of binary properties like that, and the breakdown can be done in multiple ways. The resulting binary properties may not be have sensible names as they do in my example, but it can be done. In general, find all possible combinations of values for your set of many-state properties. Enumerate those combinations and write the numbers in binary. Each binary digit is a property in your new set of binary properties. There are multiple possible enumerations, so there are multiple possible mappings from a set of many-state properties to a set of binary properties.
For example, if you have a three-state property and a four-state property, then you'll a combination of 12 possible states. Number those 12 states. Write those numbers in binary. You'll need at least four binary digits. That means you'll have at minimum four binary properties. Those four properties can have 16 total states, so four of the states will be unused.
You can similarly decompose your properties into a set of three-state properties by writing your enumeration in base-three. I suppose you could also consider the current state of your program, with it's many multi-state properties (integers have lots of possible states, strings have even more), to be a single variable-base number that enumerates a state in the state-space of your program. If you consider the remaining input to your program to be part of your state, and the set of all possible outputs to be enumerated in a similar fashion, then the problem of programming is reduced to the building of a machine that maps numbers from one set to numbers in another. How hard can that be? So I'll need your project done by Monday.