3 ms·
Why not both?
by ainiriand 2y ago
Why not both?
- deleted 2y ago[deleted]
- chikere232 2y agoBecause building for extensibility adds real complexity for a hypotetical need If you want the code to do something different later, change, replace or extend it then... when you actually know what it needs to do
- ainiriand 2y agoI am not sure that is something that applies 100%, but I understand the concern. It is my understanding that we should try to build solutions to current problems, and be open to future use cases that could involve small additions in functionality. It would be stupid to design an unmodifiable system just because some parts can be deleted and we are not sure what future needs are. Code should always be easy to extend, in my opinion.
- pjturpeau 2y agoIf it is easy to understand, then it is easy to extend.
- kraftman 2y agoConversations like this are always difficult to discuss at a high level because the way we implement the words we use can be very different. Code can be written in a way that a lot of complexity is added in order to make it extensible, or it can be written in a way where simplification is used to make it extensible. Both authors would agree that extensible is good.
- ainiriand 2y agoThat is an excellent and pragmatic point of view.
- chikere232 2y agoIt's not an absolute and there are occasional good design decisions made in the name of extensibility But what is an unmodifiable system? If it's code in your control, it can be changed, right?