5 ms·

Good interfaces should primarily have reasonable and well documented pre and post conditions. This is very apparently not so in the oil change example in the ar

by jupp0r 4y ago

Good interfaces should primarily have reasonable and well documented pre and post conditions. This is very apparently not so in the oil change example in the article. It's completely stunning to me how frequently this is forgotten in spite of having been a key component of object oriented programming when it was invented (ie smalltalk days, before I was born).

whitepoplar 4y ago
Can you clarify what you mean by this?
- 8note 4y ago
  For instance, does the old oil need to be drained before filling new oil? Does the car need to be checked for leaks? At the end of filling in new oil, how much oil should be in the car? How much left over?
- jupp0r 4y ago
  Sure, here are some postconditions for ChangeOil(): - engine has appropriate amount of oil in it - oil filter in place - drain plug torqued correctly - dip stick present - oil cap on No matter what the outcome of the operation (ie error paths or happy path), ChangeOil promises to return with the car in a state that fulfills those conditions. In order to do that, some preconditions need to be fulfilled too: - car has some amount if oil in engine - car is able to start - no major noises
  - AgentOrange1234 4y ago
    Yes and frame conditions… Wheels should still where they were, nothing stolen from the glovebox, no bodies added to the trunk, brake lines uncut, etc.
sterasody 4y ago
Is this what we refer to as design by contract? If so, what about invariants? Are invariants related to good interface design?
- tommyage 4y ago
  > Is this what we refer to as design by contract? 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.
  - sterasody 4y ago
    Thanks for your reply! I will need more research to reflect on the examples you give. I discovered the concept from books and documentations, for example: - https://learn.adacore.com/courses/intro-to-ada/chapters/contracts.html https://learn.adacore.com/courses/intro-to-ada/chapters/cont... - https://www.eiffel.org/doc/solutions/Design_by_Contract_and_Assertions 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?
    - tommyage 4y ago
      > Thanks for your reply! I will need more research to reflect on the examples you give. 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_ 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.

by jupp0r 4y ago

whitepoplar 4y ago

Can you clarify what you mean by this?

8note 4y ago
For instance, does the old oil need to be drained before filling new oil? Does the car need to be checked for leaks? At the end of filling in new oil, how much oil should be in the car? How much left over?
jupp0r 4y ago
Sure, here are some postconditions for ChangeOil(): - engine has appropriate amount of oil in it - oil filter in place - drain plug torqued correctly - dip stick present - oil cap on No matter what the outcome of the operation (ie error paths or happy path), ChangeOil promises to return with the car in a state that fulfills those conditions. In order to do that, some preconditions need to be fulfilled too: - car has some amount if oil in engine - car is able to start - no major noises
- AgentOrange1234 4y ago
  Yes and frame conditions… Wheels should still where they were, nothing stolen from the glovebox, no bodies added to the trunk, brake lines uncut, etc.

sterasody 4y ago

Is this what we refer to as design by contract? If so, what about invariants? Are invariants related to good interface design?

tommyage 4y ago
> Is this what we refer to as design by contract? 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.
- sterasody 4y ago
  Thanks for your reply! I will need more research to reflect on the examples you give. I discovered the concept from books and documentations, for example: - https://learn.adacore.com/courses/intro-to-ada/chapters/contracts.html https://learn.adacore.com/courses/intro-to-ada/chapters/cont... - https://www.eiffel.org/doc/solutions/Design_by_Contract_and_Assertions 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?
  - tommyage 4y ago
    > Thanks for your reply! I will need more research to reflect on the examples you give. 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_ 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.