Great question. I think when first designing the interface we should be anticipating that things will almost certainly change in the future. Therefore we should design our interfaces with flexibility in mind. I think it's a good idea to consider the Single Responsibility Principle in order to segregate the interfaces appropriately. For example, is updating really the same responsibility as updating? Probably not, so we should segregate those responsibilities into different interfaces.
In terms of existing code, I think the answer depends on whether or not you can guarantee that all the consumers of the interface will know about the change. For example, if you're making your own application that will all be packaged together, most likely you can just refactor things and update the implementations accordingly. However, if you are writing a library that lots of users consume, and you change you interface, then their code will break. So in those cases, it might be better to role out a new interface and leave the old one their for legacy.
Thank you for the response Sam. I haven't thought about the legacy when working with libraries, that's a clear example for the Single Responsibility and the Interface Segregation principles working together to get a better code since if applied correctly my hypothetically case wouldn't exist at all!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hey Edwin,
Great question. I think when first designing the interface we should be anticipating that things will almost certainly change in the future. Therefore we should design our interfaces with flexibility in mind. I think it's a good idea to consider the Single Responsibility Principle in order to segregate the interfaces appropriately. For example, is updating really the same responsibility as updating? Probably not, so we should segregate those responsibilities into different interfaces.
In terms of existing code, I think the answer depends on whether or not you can guarantee that all the consumers of the interface will know about the change. For example, if you're making your own application that will all be packaged together, most likely you can just refactor things and update the implementations accordingly. However, if you are writing a library that lots of users consume, and you change you interface, then their code will break. So in those cases, it might be better to role out a new interface and leave the old one their for legacy.
Thank you for the response Sam. I haven't thought about the legacy when working with libraries, that's a clear example for the Single Responsibility and the Interface Segregation principles working together to get a better code since if applied correctly my hypothetically case wouldn't exist at all!