Is this what we refer to as design by contract?
If so, what about invariants? Are invariants related to good interface design?
If so, what about invariants? Are invariants related to good interface design?
No. One need a specification of the intended behaviour. Behind this specification lays the interface (data type, here a Object-class). This data type on the other hand can have different representations.
Design by contract is a term i didn't read as an agreed scientific term. It is used in OO-languages for some pattern, where you "generate" (read imply) a specification. E.g. two unrelated services use the same data type within their communication. This may be injected or included within their dependencies. To me its related to code generation. It may aid the collaborations between multiple developers across multiple projects to 'move faster'. I have limited and bad experience with this.
> If so, what about invariants? Are invariants related to good interface design?
Invariants in my book are then a synonym for mixins. Which in OO-Design would be represented via dependency inversion. Invariants can be necessary at best. Its no measure for a good interface. If your data types are specified such that invariants do not missbehave, they can be used.
But don't trust me on this.
I discovered the concept from books and documentations, for example:
- https://learn.adacore.com/courses/intro-to-ada/chapters/cont...
- https://www.eiffel.org/doc/solutions/Design_by_Contract_and_...
and it seemed to me the main concern was program correctness/consistency.
Maybe I mix up different concerns and good interface design is more about satisfying use case?
Please note my sibling answer which shows I am opinionated. I have memorized my own takes from such terms so researching about my answer may be time not used well. Sorry.
> - https://www.eiffel.org/doc/solutions/Design_by_Contract_and_...
Does indeed overlap. I only read about contract-based programming; contract by design via API documentation in a java environment.
> and it seemed to me the main concern was program correctness/consistency
It is. There are multiple factors to deploying correct software though.
> Maybe I mix up different concerns and good interface design is more about satisfying use case?
Apparently your are on the right track. But I would strongly agree on the latter. Such formal correctness proves didn't cross my career yet. But I am assuming safety-critical systems or systems haed to update may benefit here the most. Which would explain my lack of certainty.
Keep it up; Sorry.
It was my own understanding; Thanks for suggesting clarification. I falsely associated such mixins with encapsulated behaviour. It was my take on mixins and may have translated the term invariant wrong. Appreciated.