4 ms·
Probably because in general they are a code smell. They are anti-OO.
by oweiler 7y ago
Probably because in general they are a code smell. They are anti-OO.
- vbezhenar 7y agoThat's just not true. If I'm writing simplest REST service, I have to return JSON responses. To return JSON response, I have to write class corresponding to that response. And that will be data class. If I'm interacting with database, I'm writing data mapping classes. And that will be data class. Those are normal code that every developer writes every day. If you think that it's anti-OO, then I don't care about that OO. I care about writing performant, concise and extensible software.
- ivan_gammel 7y agoThat statement is valid in both contexts you mention. You do not need properties for data mapping and serialization - it’s possible to write a good OO code without getters and setters.
- antisemiotic 7y agoIf a useful feature is incompatible with OO, it's a problem with OO, not with the feature. Properties allow one to work with plain old data (not everything is meaningfully an object with behavior) without freezing the underlying implementation forever. Fewer (or maybe more decentralized) religious arguments like this is one of the few things I like about my job in C++. (Shame C++ doesn't have properties, these would come in handy in refactoring config handling code that I currently work on, but on the other hand the last thing C++ needs is yet another feature hidden under common syntax that may blow up allocations and runtime unexpectedly). EDIT: to clarify: for example, I consider std::optional as an example of a very "un-OO" type that's immensely useful. In general I like the idea from functional programming that complex types can be treated no different than primitives, rather than the OO way of wrapping and uplifting everything until even integers have methods.