This analogy has helped me to understand the importance of programming to an interface. It presumes that technology advances more quickly than the domain in which the problem that we are trying to solve lies.
Suppose Jack and Jill each own a grocery store. When their stores opened a few years ago, Jack saw cash as the present and future de facto standard in payments. As a result, the rest of his system assumed cash as the payment method. Jill was slightly more open-minded and still wanted to be able to accept cheques. This meant that the parts of her system connected directly with payments had to be more generic than Jack’s – they were concerned only with the transaction amount. As long as the payment was valid, the method was irrelevant.
Fast forward a few years and Jack and Jill start noticing people asking if they can pay by card. Some would-be customers have to buy their groceries elsewhere because they've stopped carrying cash altogether. Both store owners decide that in order to stay in business, they need to start accepting card payments. Jack installs a card machine alongside his cash register but in order to integrate it, he has to completely redesign the rest of his system to work with cash and card payments. On the other hand, Jill just has to install the card machine and she's up and running. The rest of her system isn't concerned with the implementation of accepting payments. Jill takes the lion's share of the area's grocery business while Jack is busy redesigning and implementing his new system.
The moral of the story: to future-proof our code and follow the principle of programming to an interface, we should focus on what we are doing and not how we are doing it. (This analogy could be extended to other coding principles, loose coupling being an obvious example.)
Blair, thanks! To summarize, you mean that by going for a more generic way of payments (ie an interface), it was easier to add support for other payment methods later on. In OOP terms: a class implementing a interface.
This analogy has helped me to understand the importance of programming to an interface. It presumes that technology advances more quickly than the domain in which the problem that we are trying to solve lies.
Suppose Jack and Jill each own a grocery store. When their stores opened a few years ago, Jack saw cash as the present and future de facto standard in payments. As a result, the rest of his system assumed cash as the payment method. Jill was slightly more open-minded and still wanted to be able to accept cheques. This meant that the parts of her system connected directly with payments had to be more generic than Jack’s – they were concerned only with the transaction amount. As long as the payment was valid, the method was irrelevant.
Fast forward a few years and Jack and Jill start noticing people asking if they can pay by card. Some would-be customers have to buy their groceries elsewhere because they've stopped carrying cash altogether. Both store owners decide that in order to stay in business, they need to start accepting card payments. Jack installs a card machine alongside his cash register but in order to integrate it, he has to completely redesign the rest of his system to work with cash and card payments. On the other hand, Jill just has to install the card machine and she's up and running. The rest of her system isn't concerned with the implementation of accepting payments. Jill takes the lion's share of the area's grocery business while Jack is busy redesigning and implementing his new system.
The moral of the story: to future-proof our code and follow the principle of programming to an interface, we should focus on what we are doing and not how we are doing it. (This analogy could be extended to other coding principles, loose coupling being an obvious example.)
Blair, thanks! To summarize, you mean that by going for a more generic way of payments (ie an interface), it was easier to add support for other payment methods later on. In OOP terms: a class implementing a interface.
Exactly, Ana. Apologies for the verbosity of my comment, thank you for your summary.
No problem, Blair! It was a good read! Thanks for your post reply! 🙂