Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Designing Good Interfaces

pboyd.io

Post reply on HN
Print view View original

21–30 of 32 posts

Re: Designing Good Interfaces

#21

Post by tommyage »

sterasody wrote: post #13
jupp0r wrote: post #6

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

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

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

Re: Designing Good Interfaces

#23

Post by Joker_vD »

DeathArrow wrote: post #15

An interface is a contract. It shouldn't be concerned with implementation details and it should contain the absolute minimum to do the work. public ResultType ChangeOil(Car c, Oil oil = null); is enough. In the actual implementation of the interface we can check if oil is null and if it is, provide own oil which fits car. If oil is not null, we can check if it is enough and if the type fits car type. We also can retu…

> It shouldn't be concerned with implementation details

And then, when some poor programmer finally comes to writing an actual implementation, he finds out that it's literally impossible without magic.

Re: Designing Good Interfaces

#25

Post by sterasody »

tommyage wrote: post #21
sterasody wrote: post #13

Earlier quoted context omitted.

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

> 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 specificatio…

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?

Re: Designing Good Interfaces

#26

Post by bedobi »

Name_Chawps wrote: post #24
bedobi wrote: post #22

Don't mean to be uncharitable, but the author seems unaware of basic FP concepts. There's a reason why most OO languages are moving more and more towards FP.

Which FP concepts would help here?

Prefer functions that return things over void methods, prefer immutability over mutability, prefer pure functions that declare (and require) their dependencies as inputs etc etc.

Re: Designing Good Interfaces

#27

Post by bedobi »

macintux wrote: post #7
codazoda wrote: post #5

My first question was, where does “inventory.GetOil()” come from. Is this just a package that wasn’t mentioned? Not being a Go expert, are packages typically global like this? Would that be a good way to implement this function/method (in a package that then becomes available everywhere in main() as opposed to passing it)? Ah, well, maybe I missed the point entirely.

After writing almost entirely functional code for the last 10 years, I find it really hard to read and reason about anything that looks like this.

Totally agree, commented something similar. Both the before and after code shown is impossible to reason about magic. The idea that programming interfaces should be good is good, but this example isn't the best IMO.

Re: Designing Good Interfaces

#28

Post by Jtsummers »

tommyage wrote: post #21
sterasody wrote: post #13

Earlier quoted context omitted.

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

> 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 specificatio…

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?

Re: Designing Good Interfaces

#29

Post by AgentOrange1234 »

jupp0r wrote: post #12
whitepoplar wrote: post #10

Earlier quoted context omitted.

Can you clarify what you mean by this?

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…

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.

Re: Designing Good Interfaces

#30

Post by emurillo510 »

why not just check the array if it's empty? post doesn't give a good example.

I argue that the "better way" has more conceptual overhead. if this was a large project. just changing oil would require to understand many ideas.

Post reply on HN