mirror of
https://github.com/nasa/openmct.git
synced 2025-05-12 13:33:14 +00:00
[API] Add proposals for capability changes
WTD-1237
This commit is contained in:
parent
8f8dd6c11f
commit
7d94e20c8f
@ -848,3 +848,56 @@ level, this contradicts the proposal to
|
|||||||
"green field" feel of developing applications on a useful
|
"green field" feel of developing applications on a useful
|
||||||
platform.
|
platform.
|
||||||
|
|
||||||
|
## Capabilities as Mixins
|
||||||
|
|
||||||
|
Change the behavior of capabilities such that they act as
|
||||||
|
mixins, adding additional methods to domain objects.
|
||||||
|
Checking if a domain object has a `persistence` capability
|
||||||
|
would instead be reduced to checking if it has a `persist`
|
||||||
|
method.
|
||||||
|
|
||||||
|
Mixins would be applied in priority order and filtered for
|
||||||
|
applicability by policy.
|
||||||
|
|
||||||
|
### Benefits
|
||||||
|
|
||||||
|
* Replaces "capabilities" (which, as a concept, can be hard
|
||||||
|
to grasp) with a more familiar "mixins" concept, which has
|
||||||
|
been used more generally across many languages.
|
||||||
|
* Reduces interface depth.
|
||||||
|
|
||||||
|
### Detriments
|
||||||
|
|
||||||
|
* Requires checking for the interface exposed by a domain
|
||||||
|
object. Alternately, could use `instanceof`, but would
|
||||||
|
need to take care to ensure that the prototype chain of
|
||||||
|
the domain object is sufficient to do this (which may
|
||||||
|
enforce awkward or non-obvious constraints on the way these
|
||||||
|
mixins are implemented.)
|
||||||
|
* May complicate documentation; understanding the interface
|
||||||
|
of a given domain object requires visiting documentation
|
||||||
|
for various mixins.
|
||||||
|
|
||||||
|
## Remove Applies-To Methods
|
||||||
|
|
||||||
|
Remove all `appliesTo` static methods and replace them with
|
||||||
|
appropriate policy categories.
|
||||||
|
|
||||||
|
### Benefits
|
||||||
|
|
||||||
|
* Reduces sizes of interfaces. Handles filtering down sets
|
||||||
|
of extensions in a single consistent way.
|
||||||
|
|
||||||
|
### Detriments
|
||||||
|
|
||||||
|
* Mixes formal applicability with policy; presently, `appliesTo`
|
||||||
|
is useful for cases where a given extension cannot, even in
|
||||||
|
principle, be applied in a given context (e.g. a domain object
|
||||||
|
model is missing the properties which describe the behavior),
|
||||||
|
whereas policy is useful for cases where applicability is
|
||||||
|
being refined for business or usability reasons. Colocating
|
||||||
|
the former with the extension itself has some benefits
|
||||||
|
(exhibits better cohesion.)
|
||||||
|
* This could be mitigated in the proposed approach by locating
|
||||||
|
`appliesTo`-like policies in the same bundle as the relevant
|
||||||
|
extension.
|
||||||
|
Loading…
x
Reference in New Issue
Block a user