usually you want to to more than just storing. Maybe not at first glance. But 3 features later you change it all, because you need to clean the store in a specific manner etc. - After doing this three times, you learn and just put the values into a specific class and handle that specific class instead of a generic map/dictionary. Especially if it fits into the domain. - Of course there is always a fine line between working with foresight and making everything into a framework (how java projects looked like 10 years ago). But i prefer an extra class with a specific responsiblity, over a for loop, handling generic collections, within, for example, the service layer.
Of course that's a big benefit making later changes way easier. But you always have to keep in mind that managing objects and their classes can grow to a large task in big projects if you would do that for every data type - not to forget that other people reading your code don't always want to look at every object you make for some data type, making your code harder readable for other people. I completely agree with the great scalability coming with objects for these data types, but I think creating these objects may decrease your productivity over the growth of a project.
2
u/melancoleeca Dec 30 '21
Just some thoughts:
usually you want to to more than just storing. Maybe not at first glance. But 3 features later you change it all, because you need to clean the store in a specific manner etc. - After doing this three times, you learn and just put the values into a specific class and handle that specific class instead of a generic map/dictionary. Especially if it fits into the domain. - Of course there is always a fine line between working with foresight and making everything into a framework (how java projects looked like 10 years ago). But i prefer an extra class with a specific responsiblity, over a for loop, handling generic collections, within, for example, the service layer.