3 ms·
Given a programming context we are always writing code on an abstraction layer, such a layer (which can be as granular as a language construct or a function) ca
by dgb23 5y ago
Given a programming context we are always writing code on an abstraction layer, such a layer (which can be as granular as a language construct or a function) can accommodate features. We essentially encode our feature in terms of the given abstraction(s).
Now I didn't read the book but I immediately thought of this: If we want to provide a feature, we should think of how our abstractions accommodate the feature. Are the assumptions or the interface of the abstractions in line with the functionality, or guarantees of the feature?
A good example of this would be HTTP REST. The interface is general and has clear, well defined semantics. It is a good abstraction for the web, since every request/response cycle has a clear way of reaching possible states and resources. It accommodates new features very well if they can be encoded in terms of HTTP verbs, hypertext representation and request/response cycles.