+ 2

Are Array-Backed Properties useful or not?

So, this question has been on my mind for quite some time. In a book dealing with design patterns in C++, I've found the use of so-called Array-Backed Properties. I like the idea and do see some situations were this technique might be handy, but I am hesitating to use it because I've seen literally no one else doing it, raising the question if it is simply not well-known or discouraged to use. If you don't know the concept, here is an example code I made a while ago (or just google it, you might end up reading the same text as I did): https://code.sololearn.com/cghQFhOsFekc/?ref=app So my question is if this concept seems useful or not and whether you would apply it in a project or rather not? I'm asking because I'm tinkering with how to approach a new code, and this might be handy, but again, I'm not too sure about it. I'm looking forward to hearing some opinions on the concept!

18th Nov 2018, 11:30 PM
Shadow
Shadow - avatar
3 Respostas
+ 6
I really wouldn't say that the resulting code is easier to refactor or to maintain. Adding a new property without array-backed properties require the same amount of work done. It claims that it is "as simple as adding an enum value and adding the getters and setters". I don't see how this is different from introducing a new variable and its corresponding getters and setters into the code. If you are going to tweak your calculations because changes you made are not independent of the methods, you'll still get your hands dirty. Sure, it can be useful in some cases. Some tricks displayed in the code are undeniably neat. I just wouldn't want this in a large project, not after weighing the pros and cons in its currently proposed form.
19th Nov 2018, 8:12 AM
Hatsy Rei
Hatsy Rei - avatar
+ 5
I'd never do it. It has issues with type differences so you might start with 3 unsigned int variables, but if you want one of them to become unsigned long, you have a mess on your hands. Technically, the code is the same except that your fancy getVolume code is likely slower than the hard coded: return sidelengths[Width] * sidelengths[Length] * sidelengths[Height];
19th Nov 2018, 2:36 AM
John Wells
John Wells - avatar
+ 3
Thanks for stating your opinions on this topic, John Wells & Hatsy Rei. I felt like the book reported too one-sided on this approach (well, can't really judge the author here), so hearing from others on possible downsides is important for me. Especially performant-wise it seems a 'hard-coded'version will perform better. I agree with you that I wouldn't want to use it in a large-scale project, so I suppose I'll refrain from doing so for now. Thanks for providing useful criticism again!
19th Nov 2018, 9:38 PM
Shadow
Shadow - avatar