4 ms·

It's a bad idea to add objects/classes/structs for no reason. If they are not pulling their conceptual weight they should be moved. Hierarchy has costs, flat is

by pbw 6y ago

It's a bad idea to add objects/classes/structs for no reason. If they are not pulling their conceptual weight they should be moved. Hierarchy has costs, flat is sometimes better. But as I wrote in the article attributes are like global variables to an object. Every boolean attribute you add to an object doubles the number of possible states. An object with 10 boolean variables can have 1024 states. I find it's better to tamp down on the number of attributes by carefully introduce select sub-objects that have value beyond just reducing the number of attributes. What has your experience been? How many attributes makes you start to wonder if a sub-object would be appropriate?

philipswood 6y ago
Agree in principle. Nice article - I like the idea of designing code (or looking at code) with the perspective of how it gets parsed by a human mind. Great code _looks_ super simple, effortless, until you try to write something similar to it and realise that there is a lot of effort in factoring it to be that simple. That said - I don't think minimising object members are the main point of attack. I don't find the number of _members_ to be that taxing to working memory. It seems to be naturally chunked: the members I'm working with and everything else. I don't need to keep all the members in mind. It's like stuff in a drawer - it's in one file so I can rummage to find the bits I need and keep them "in hand", going a small factor over the working memory limit is fine. (I'm not saying there isn't a retrieval cost, more members increase retrieval cost, potential confusion, etc. etc.) What seems to be a lot more taxing is keeping reference to relationships to other objects. Stuff NOT in the current file. Having to keep the relationships between a number of other objects/classes in mind is more taxing, because those need to be in working memory - and putting them there either means they are in long term memory (e.g. with a known codebase or library), or parsing it out by navigating through the codebase, tracing the relationships and understanding the intents. Ironically super-factored code can be a lot of effort to "get" at first, while intermediate quality code reads pretty easily. I find my mental map of a nicely factored object is more tied to it's intent/purpose or "meaning" rather than just the raw number of its members. Your PerfEvent example I'd parse it the same way, though.

by pbw 6y ago

philipswood 6y ago

Agree in principle. Nice article - I like the idea of designing code (or looking at code) with the perspective of how it gets parsed by a human mind. Great code _looks_ super simple, effortless, until you try to write something similar to it and realise that there is a lot of effort in factoring it to be that simple. That said - I don't think minimising object members are the main point of attack. I don't find the number of _members_ to be that taxing to working memory. It seems to be naturally chunked: the members I'm working with and everything else. I don't need to keep all the members in mind. It's like stuff in a drawer - it's in one file so I can rummage to find the bits I need and keep them "in hand", going a small factor over the working memory limit is fine. (I'm not saying there isn't a retrieval cost, more members increase retrieval cost, potential confusion, etc. etc.) What seems to be a lot more taxing is keeping reference to relationships to other objects. Stuff NOT in the current file. Having to keep the relationships between a number of other objects/classes in mind is more taxing, because those need to be in working memory - and putting them there either means they are in long term memory (e.g. with a known codebase or library), or parsing it out by navigating through the codebase, tracing the relationships and understanding the intents. Ironically super-factored code can be a lot of effort to "get" at first, while intermediate quality code reads pretty easily. I find my mental map of a nicely factored object is more tied to it's intent/purpose or "meaning" rather than just the raw number of its members. Your PerfEvent example I'd parse it the same way, though.