As far as the S/W engineering take away -- simply put, an interface allows two disparate pieces of code to work together. One compiled piece of code, for example, can interact with another piece of code, which could be written and compiled years after the initial.
Interfaces – The Most Important Software Engineering Concept
11–20 of 43 posts
Re: Interfaces – The Most Important Software Engineering Concept
#12Opinion: If interfaces is the most important software engineering concept, then the most important interface is the one used to control I/O. Different approaches. Fun to think about.
Re: Interfaces – The Most Important Software Engineering Concept
#13Hi, I'm the author. I submitted this yesterday, but I didn't even get 1 upvote, so I'm glad to see it here today as I think it is a very important topic for discussion. Feedback from the submission on Reddit has suggested that this article is too long which I now acknowledge. I'd be happy to hear any critiques you have.
Good article. Interfaces and modularity are core concepts, worthy of much attention. Especially questions like how to do functional decomposition, finding the right abstractions, and good interface design. I'll chew on your statements about the success of Python. Though my first love was LISP, I'm now far more comfortable leaning on static typing and composition. --- The best book on software design I've ever read wa…
Thanks for the link. Let me repay you with one:
http://www.amazon.com/Design-Essays-Computer-Scientist/dp/02...
Re: Interfaces – The Most Important Software Engineering Concept
#14I think coupling and cohesion stand out as fundamental software design principles. (I wouldn't say it's "interfaces" as I can imagine interfaces with tight coupling or low cohesion.)
"Coupling" I understand, as sort of opposed to "modularity". What do you mean by "cohesion" in this context?
Re: Interfaces – The Most Important Software Engineering Concept
#15Awesome write up. While I agree that dynamically typed languages -- by their loosely defined API requirements -- are more difficult to scale, it's not difficult to add type checking and/or provide a well structured public API where necessary. I think statically typed languages go too far in the other direction. Tyr type and API definitions are too strict leading in a ton of unnecessary effort (ie boilerplate), increa…
> I think statically typed languages go too far in the other direction. Tyr type and API definitions are too strict leading in a ton of unnecessary effort (ie boilerplate), increased surface area for potential bugs, and overly restrictive limits that require 'creative' workarounds to effectively write code.
Given this description of statically typed languages, I'm guessing you haven't tried OCaml or Haskell.
Re: Interfaces – The Most Important Software Engineering Concept
#16Thanks for posting!
Re: Interfaces – The Most Important Software Engineering Concept
#17I have been skeptical of the notion of "interface" lately.
First of all, there is comment from Erik Meijer who said something like "interface without laws is useless" (he was referring to "interface" as a concept in OOP languages, and by "laws" he meant some algebraic laws). Basically what he wanted to know was the algebra, not just interface.
And if you look at it from Curry-Howard correspondence perspective, where programs are proofs and types are theorems, then basically, since type is an interface, you could say that theorems are interfaces in mathematics. So there already is a very precise notion of what is interface.
On the other hand, I also kinda like the notion of DSL as an interface, as described in the recent article here on HN: http://degoes.net/articles/modern-fp/
What seems to be the main contention here - should the interface just use the names (akin to philosophical nominalism) and leave them open to interpretation or should it somehow encode the properties of things it describes (akin to philosophical realism)?
Re: Interfaces – The Most Important Software Engineering Concept
#18Awesome write up. While I agree that dynamically typed languages -- by their loosely defined API requirements -- are more difficult to scale, it's not difficult to add type checking and/or provide a well structured public API where necessary. I think statically typed languages go too far in the other direction. Tyr type and API definitions are too strict leading in a ton of unnecessary effort (ie boilerplate), increa…
> I think statically typed languages go too far in the other direction. Tyr type and API definitions are too strict leading in a ton of unnecessary effort (ie boilerplate), increased surface area for potential bugs, and overly restrictive limits that require 'creative' workarounds to effectively write code. Given this description of statically typed languages, I'm guessing you haven't tried OCaml or Haskell.
I was specifically referring to statically typed OOP.
You're right, I haven't tried OCaml or Haskell so I can't make a qualitative judgement on how easy/hard type coercion is in either.
Re: Interfaces – The Most Important Software Engineering Concept
#19I think coupling and cohesion stand out as fundamental software design principles. (I wouldn't say it's "interfaces" as I can imagine interfaces with tight coupling or low cohesion.)
"Coupling" I understand, as sort of opposed to "modularity". What do you mean by "cohesion" in this context?
The ideal is low coupling and high cohesion. That's supposed to mean your system is composed of parts that can be understood separately. Low coupling means that the innards of each module are isolated from the others. High cohesion means that each module presents a clear and distinct purpose.
Thinking in terms of interfaces (in the general sense) helps towards this ideal. If an interface is cluttered with dozens of functions, it's a sign that it could be refactored into more cohesive units.
Re: Interfaces – The Most Important Software Engineering Concept
#20Hi, I'm the author. I submitted this yesterday, but I didn't even get 1 upvote, so I'm glad to see it here today as I think it is a very important topic for discussion. Feedback from the submission on Reddit has suggested that this article is too long which I now acknowledge. I'd be happy to hear any critiques you have.
An interface is the intersection between the system and the environment.
An implementation is the system minus the interface
These definitions seem at odds with each other. The first sentence would imply that the interface is part of the implementation, but the second says that the implementation and the interface are exclusive. What do you feel you gain by defining things in this way, as opposed to saying something like "the interface is the portion of the implementation with which the system interacts"?