LVOOP guidelines

[shoneill]

I was browing through the actor framework discussions on the NI site yesterday and I came across a statement by AQ.

Never inherit a concrete class from another concrete class

I had to think about that for a second.  The more I think about it, the more I realise that all of the LVOOP software I have been writing more or less adheres to this idea.  But I had never seen it stated so succinctly before.  Now that may just be down to me being a bit slow and all, but in the muddy and murky world of "correct" in OOP-land, this seems to be a pretty good rult to hold on to.

Are there others which can help wannabe plebs like me grasp the correct notions a bit better?  How about only ever calling concrete methods from within the owning class, never from without?  I'm learning for a long time now, but somehow, my expectations of LVOOP and the reality always seem a little disconnected.  AQs statement above helped crystallise out some things which, up to that point, had been a bit nebulous in my mind.  Well, I say I'm learning..... I'm certainly using my brain to investigate the subject, whether or not I'm actually LEARNING is a matter for discussion... The older I get, the less sure I am that I've actually properly grasped something.  The old grey cells just seem to get more sceptical with time.  Maybe that in itself is learning...

[PiDi]

More general idea: prefer composition over inheritance. Inheritance is the strongest relationship in OO-world ("something IS something else") and should be used sparingly. It introduces high coupling, and thus lowers modularity and flexibility of the design. It can be usually avoided by using composition. For example, if you're in need of extending concrete class features or replacing some functionality, instead of inheriting from concrete class (as in AQs statement) you can use proxy pattern.

Another one I like is tell, don't ask, which acts as sanity checker whenever I'm creating accessor or doing something with the data that belongs to the object outside of this object.

[G-CODE]

shoneill, Mercer said something prior to the sentence you quoted that is important to include in his statement about inheritance - specifically that it is "general" advice.

Quote

A general piece of advice that applies to ALL object-oriented software:

Never inherit a concrete class from another concrete class.

I can think of a recent example where inheritance was a useful tool, but I broke from that convention. However, I would say that generally (most of the use cases I encounter) I would not want concrete classes inheriting from other concrete classes. 

[MikaelH]

The only time I inherit a concrete class, is when I have a Class Called e.g. Instrument123, that has many methods and been verified and work perfectly.
Then a new model comes out "Instrument123+", that just needs tweaking in one method or so, to get the same behavior as the old instrument.
I guess I do this because I'm lazy, but that's when I do it.

[JKSH]

On 1/6/2017 at 4:50 PM, shoneill said:

Never inherit a concrete class from another concrete class

One thing's not clear to me: Does that statement mean, "You should not inherit from a concrete class, ever", or does it mean "you should not make a concrete class inherit from a concrete class, but you can let an abstract class inherit from a concrete class"?

Also, before we get too deep, could you explain, in your own words, the meaning of "concrete"?

 

On 1/7/2017 at 1:53 AM, planet581g said:

shoneill, Mercer said something prior to the sentence you quoted that is important to include in his statement about inheritance - specifically that it is "general" advice.

I can think of a recent example where inheritance was a useful tool, but I broke from that convention. However, I would say that generally (most of the use cases I encounter) I would not want concrete classes inheriting from other concrete classes. 

Agreed, I'd call it a "rule of thumb" instead of saying "never".

An example where multi-layered inheritance make sense, that should be familiar to most LabVIEW programmers, is LabVIEW's GObject inheritance tree. Here's a small subset:

• GObject
  • Constant
  • Control
    • Boolean
    • Numeric
      • NamedNumeric
        • Enum
        • Ring
      • NumericWithScale
        • Dial
        • Knob
    • String
      • ComboBox
  • Wire

In the example above, green represents abstract classes, and orange represents concrete classes. Notice that concrete classes are inherited from by both abstract and concrete classes. Would you ("you" == "anyone reading this") organize this tree differently?

On 1/6/2017 at 4:50 PM, shoneill said:

How about only ever calling concrete methods from within the owning class, never from without?

What's the rationale behind this restriction?