5 ms·

If I were solving this problem in C# I'd probably lean towards defining specific properties of objects in interfaces, rather than just through a type hierarchy.

If I were solving this problem in C# I'd probably lean towards defining specific properties of objects in interfaces, rather than just through a type hierarchy. So we might have the interface ISecurityWithIsin , IOption etc. This has the advantage of allowing a.) easy use of mocking, dependency injection for testing. b.) Classes can implement more than one of these interfaces. The question then becomes- where do you put your base, shared functionality (e.g. a method that is common to all stocks with Isin numbers). Possibly this becomes another set of classes...

tomp 14y ago
The problem with interfaces is that you have to reimplement all the code for the basic functionality in every class. Scala-like traits, which are basically interfaces with optional implementation, should help here. Also, if you're using a flat type hierarchy where classes never inherit, but only extend interfaces, you're better of using a different language which natively supports a structural typing style, such as Go, OCaml, or Objective C.
- tomgallard 14y ago
  True- but in this case the classes looked relatively simple (i.e. they were carrying data, but not operating on it) Taking the interface approach further, your classes that operate on your data would take in objects by interface e.g.: public class IsinValidator ... public bool Validate(IIsinSecurity security) {}
- anuraj 14y ago
  Just use polymorphic associations (weak linking) wherever you want to enable code reuse and the implementation is not tightly linked to the class hierarchy. It is about how you think in terms of OO.
- colomon 14y ago
  In the Moose / Perl 6 world, we use roles for this. (I know the idea is borrowed from elsewhere, but I don't know where.) As a Perl 6 programmer, I have almost completely given up on traditional inheritance, because roles capture everything I want from inheritance with greater robustness. To be fair to original article, this does mean I'm doing my best to avoid type hierarchies...
  - cygx 14y ago
    I know the idea is borrowed from elsewhere, but I don't know where. It probably originated in Flavors, an object system for Lisp (see http://en.wikipedia.org/wiki/Flavors_%28computer_science%29 http://en.wikipedia.org/wiki/Flavors_%28computer_science%29)
    - chromatic 14y ago
      It was a combination of dissatisfaction with multiple inheritance (see Perl 5, C++), interfaces (see Java), and mixins (see Perl 5, Ruby), as well as an acknowledgement that aspects (see Java) and multimethods (see Common Lisp) solve part of the problem well and part of the problem poorly. Then Allison and I saw Dr. Black present the Smalltalk traits paper and she realized that their formalism was exactly what I'd been talking about informally, so we borrowed that instead.
      - tomp 14y ago
        How are roles different from mixins? The only difference that I can think of is that mixins are declared at class declaration, is that what you mean?
        chromatic 14y ago
        Roles have specific composition rules which forbid name collisions; there's no last-in wins rule. Roles also provide type allomorphism which is much less ambiguous than duck typing.
JoeAltmaier 14y ago
Right. Smaller, atomic classes help with this. But then you have a snowstorm of classes, all with more-or-less helpful names. That's complicated too. Probably the better answer though. Sometimes the code is complex because the problem is complex.

tomp 14y ago

The problem with interfaces is that you have to reimplement all the code for the basic functionality in every class. Scala-like traits, which are basically interfaces with optional implementation, should help here. Also, if you're using a flat type hierarchy where classes never inherit, but only extend interfaces, you're better of using a different language which natively supports a structural typing style, such as Go, OCaml, or Objective C.

tomgallard 14y ago
True- but in this case the classes looked relatively simple (i.e. they were carrying data, but not operating on it) Taking the interface approach further, your classes that operate on your data would take in objects by interface e.g.: public class IsinValidator ... public bool Validate(IIsinSecurity security) {}
anuraj 14y ago
Just use polymorphic associations (weak linking) wherever you want to enable code reuse and the implementation is not tightly linked to the class hierarchy. It is about how you think in terms of OO.
colomon 14y ago
In the Moose / Perl 6 world, we use roles for this. (I know the idea is borrowed from elsewhere, but I don't know where.) As a Perl 6 programmer, I have almost completely given up on traditional inheritance, because roles capture everything I want from inheritance with greater robustness. To be fair to original article, this does mean I'm doing my best to avoid type hierarchies...
- cygx 14y ago
  I know the idea is borrowed from elsewhere, but I don't know where. It probably originated in Flavors, an object system for Lisp (see http://en.wikipedia.org/wiki/Flavors_%28computer_science%29 http://en.wikipedia.org/wiki/Flavors_%28computer_science%29)
  - chromatic 14y ago
    It was a combination of dissatisfaction with multiple inheritance (see Perl 5, C++), interfaces (see Java), and mixins (see Perl 5, Ruby), as well as an acknowledgement that aspects (see Java) and multimethods (see Common Lisp) solve part of the problem well and part of the problem poorly. Then Allison and I saw Dr. Black present the Smalltalk traits paper and she realized that their formalism was exactly what I'd been talking about informally, so we borrowed that instead.
    - tomp 14y ago
      How are roles different from mixins? The only difference that I can think of is that mixins are declared at class declaration, is that what you mean?
      - chromatic 14y ago
        Roles have specific composition rules which forbid name collisions; there's no last-in wins rule. Roles also provide type allomorphism which is much less ambiguous than duck typing.

JoeAltmaier 14y ago

Right. Smaller, atomic classes help with this. But then you have a snowstorm of classes, all with more-or-less helpful names. That's complicated too. Probably the better answer though. Sometimes the code is complex because the problem is complex.