Should we always design software with lists of things in mind?



Software that eats bananas, eats one banana at a time very nicely. The function is simple:
EatBanana(b:Banana) { ... }
Now if we have a bunch of bananas, we could do this to handle multiple:
BunchOfBananas.forEach(banana => EatBanana(banana))
And then the next evolution of this would be generalizing it to handle any type of food:
BunchOfFood.forEach(food => Eat(food))
And then wrap it up for re-use:
EatABunchOfFood(f:[Food]) { ... }

But should we do this? Or stick to using .forEach()?  Or should we just run multiple instances of a server that accepts one banana to eat?

This is something I've been encountering recently. Particularly with Google's Firebase.

We are building a server which handles many organizations' notifications. Is it better to generalize to lists of organizations per server, or do we let each server handle its respective organization's notifications? Ideally I think the former is the way to go, since the software can work both on one server or multiple, hence being more flexible (at the price of complexity).

And because I think the former is the way to go, I also think maybe languages or packages that handle lists of things first class may be worth investing time into. RxJS comes to mind, where everything is a stream (infinite list), allowing even higher order (I'm not sure how else to describe this) software to be created with more ease.

Comments

Popular Posts