As used in most programming ecosystems, "interface" is a formal construct that specifies a set of methods and parameters implemented by a provider (typically, a class or service). This is all well and good, but it is too granular for another kind of conversation. For example, how could I define the concept of "daemon"? A daemon exhibits the following behaviors:
It runs automatically, in the background
It typically does not provide a direct way for users to interact; rather, it may be contactable via some sort of remoted API
It performs a service that benefits the user indirectly instead of directly
(That's not intended to be a perfect definition, but rather a suggestive/approximate one.)
The question is: how can I "say", in code, "this entity is a daemon"? The behaviors I'm describing are not at the level of methods and parameters. We could certainly imagine creating an interface that implies all of the attributes above. However, notice that several of the attributes I listed are actually negations (does not provide a direct way for users to interact...). Interfaces don't support the negation of features. Also, interfaces are too brittle to be helpful at this level of detail; the remoting interface to a daemon might be log files and config files, a message queue, a web service, a DB, or something else--and might change over the life of a project as design improves--without changing this characteristic.
What we need is a way to specify behavioral constraints and intentions at a higher level -- not with methods, but with patterns (not necessarily GoF style), maybe, or "behavioral profiles". There are architecture languages, but I think these may be overly formalized enterprise IT patterns with complex xml schemas and hundreds of elements in deep hierarchies. I'm looking for something much simpler--possibly as simple as naming a broad characteristic: "provides a way for an external actor to inspect, configure, and control", and then requiring an "implementation" (specific components and traditional interfaces) to point back to that characteristic and claim that they satisfy it.
We might be able to use marks to make claims about satisfying a behavioral profile.
As used in most programming ecosystems, "interface" is a formal construct that specifies a set of methods and parameters implemented by a provider (typically, a class or service). This is all well and good, but it is too granular for another kind of conversation. For example, how could I define the concept of "daemon"? A daemon exhibits the following behaviors:
(That's not intended to be a perfect definition, but rather a suggestive/approximate one.)
The question is: how can I "say", in code, "this entity is a daemon"? The behaviors I'm describing are not at the level of methods and parameters. We could certainly imagine creating an interface that implies all of the attributes above. However, notice that several of the attributes I listed are actually negations (does not provide a direct way for users to interact...). Interfaces don't support the negation of features. Also, interfaces are too brittle to be helpful at this level of detail; the remoting interface to a daemon might be log files and config files, a message queue, a web service, a DB, or something else--and might change over the life of a project as design improves--without changing this characteristic.
What we need is a way to specify behavioral constraints and intentions at a higher level -- not with methods, but with patterns (not necessarily GoF style), maybe, or "behavioral profiles". There are architecture languages, but I think these may be overly formalized enterprise IT patterns with complex xml schemas and hundreds of elements in deep hierarchies. I'm looking for something much simpler--possibly as simple as naming a broad characteristic: "provides a way for an external actor to inspect, configure, and control", and then requiring an "implementation" (specific components and traditional interfaces) to point back to that characteristic and claim that they satisfy it.
We might be able to use marks to make claims about satisfying a behavioral profile.