[jupp0r]

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).

[sterasody]

Is this what we refer to as design by contract?

If so, what about invariants? Are invariants related to good interface design?

[tommyage]

> 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.

[Jtsummers]

Invariants are not a synonym for mixins, I'm not even sure where that idea might have come from. Invariants are assertions that are true throughout a program or subset of a program (like loop invariants). Where did you get this notion they were synonyms for mixins and what would that even mean?

[tommyage]

> Invariants are not a synonym for mixins, I'm not even sure where that idea might have come from. Invariants are assertions that are true throughout a program or subset of a program (like loop invariants). Where did you get this notion they were synonyms for mixins and what would that even mean?

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.

[sterasody]

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/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?

[tommyage]

> 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_...

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.

[whitepoplar]

Can you clarify what you mean by this?

[jupp0r]

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]

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.

[8note]

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?