3 ms·

For golang, single method interfaces are recommended as preferable. The problem with huge interfaces or classes is they can always become larger! While if you c

by loopz 7y ago

For golang, single method interfaces are recommended as preferable. The problem with huge interfaces or classes is they can always become larger! While if you compartmentalize single responsibility into separate components (may be several methods if applicable to the domain and design), each reason to change may be restricted to that bounded context only. If not, it's a signal design might need revisit. The problem with "Drawable" is that it is property/data, and not messaging-based, thus breaking encapsulation, even if it was behaviour-based.

seertaak 7y ago
> The problem with huge interfaces or classes is they can always become larger! That's definitely a good reason to prefer small interfaces; I hadn't thought of that but it certainly makes sense. That said, I think we may be referring to different things when we use the word "property". Stroustroup is talking about properties in the mathematical sense, i.e. he's talking about the properties of the operation "draw()" in the concept Drawable. Am I misunderstanding you? To my mind that's an operation and closer to "message" (emphasis on the verb aspect) rather than data or property.
- loopz 7y ago
  "Drawable" as a name is pretty bland, like patterns. Do we ever really say "drawable" out loud? So I suspect if we seek more meaningful objects and models, they become more active, have better names, improved design, etc. If you ask a janitor about Drawable, will he say it's all about draw()? So I think it's kind of a dreary default that we need to avoid and focus on who the actors are, what messages they will pass, and the hidden treasures they encapsulate (don't show, but tell!).
throwaway894345 7y ago
Frequently in Go I find that single-method interfaces are easier to work with when made into a closure. Instead of `type Foo interface { Foo() }`, I often find `type Foo func()` easier to work with. There are probably exceptions to this; I'm mostly just voicing my own observation.

by loopz 7y ago

seertaak 7y ago

> The problem with huge interfaces or classes is they can always become larger! That's definitely a good reason to prefer small interfaces; I hadn't thought of that but it certainly makes sense. That said, I think we may be referring to different things when we use the word "property". Stroustroup is talking about properties in the mathematical sense, i.e. he's talking about the properties of the operation "draw()" in the concept Drawable. Am I misunderstanding you? To my mind that's an operation and closer to "message" (emphasis on the verb aspect) rather than data or property.

loopz 7y ago
"Drawable" as a name is pretty bland, like patterns. Do we ever really say "drawable" out loud? So I suspect if we seek more meaningful objects and models, they become more active, have better names, improved design, etc. If you ask a janitor about Drawable, will he say it's all about draw()? So I think it's kind of a dreary default that we need to avoid and focus on who the actors are, what messages they will pass, and the hidden treasures they encapsulate (don't show, but tell!).

throwaway894345 7y ago

Frequently in Go I find that single-method interfaces are easier to work with when made into a closure. Instead of `type Foo interface { Foo() }`, I often find `type Foo func()` easier to work with. There are probably exceptions to this; I'm mostly just voicing my own observation.