Different Actor Core With Different GUI Interface On Child Class

[Brainstorms]

Jimmy01, in your case, you would not need to run "Preserve Run-Time Class".  This is because once your Actor Core override completes, there's generally nothing left to do with the actor object wire.

In the general case of using this technique, you will want to return an object wire back to its original class, and that's one of the purposes of "Preserve Run-Time Class".

Using it with Actor Core overrides is a prominent case where it's not needed.

[AristosQueue (NI)]

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

Never inherit a concrete class from another concrete class.

In other words, if you have class A and you actually create objects of class A while running your program, do not create a class B inheriting from A. Instead, create a class C that you never actually instantiate, move all the content of A that you want to share into C, and then make A and B both inherit from C. That way every bit of functionality you can always decide to share or to not share without violating any inheritance principles (see Liskov Substitution Principle in Wikipedia if you've never heard of it).

[Brainstorms]

Strive to create SOLID software:

S = SRP = Single Responsibility Principle

O = OCP = Open / Closed Principle

L = LSP = Liskov Substitution Principle

I = ISP = Interface Segregation Principle

D = DIP = Dependency Inversion Principle

[Amiri]

I just looked up Liskov Substitution Principle after AQ's post and came across this whole SOLID principle which I have never heard of...so very much that I do not know...

Brainstorms & AQ - is there a definitive book or other recommended reading that you guys would suggest for learning more about this?

[jon_mcbee]

The best book I have seen on this topic is Agile Software Development by Bob Martin.  Shameless plug, I jost posted a blog article on Dependency Inversion here.

[Amiri]

Thanks jon_mcbee. I actually have Agile Software Development in my Amazon wishlist, might be time to purchase.  I think I had heard about that one from Nancy Jones or Elijah at some point.  I'll have to check out your blog post.

[Brainstorms]

Robert Martin pretty much "wrote the book" on this subject, as Jon points out...

[mike_nrao]

'Never inherit a concrete class from another concrete class' ... that seems a little extreme.  AQ, by saying that you're actually misconstruing Liskov Substitution Principle and encouraging people to break the open/closed principle!

If what you say were true, then you think VI Server hierarchy was a bad idea?

Please don't misinterpret LSP to mean never have an inheritance tree deeper than 1 level.  LSP tells us inheritance is fine as long as we don't violate any pre-and-post conditions or history constraints, and as long as invariants are preserved in the subtype.

I rarely take my code deeper than 1 level of inheritance, and often can devise a better solution preferring composition over inheritance, but I wouldn't go so far as to suggest 'never' inherit from a concrete class!  Some OO design patterns encourage deep inheritance (State Pattern for example).

I understand the point you're getting at in the scenario you propose, but if I may elaborate on it:

If you have class A and want to design a substitute class B, consider the following:

a) Will class B's methods violate any of the pre-or-post conditions of class A?

b) Will class B contradict any invariants of Class A.

c) Will class B include any methods that allow state changes to A that were not permissible in class A.

If the answer to all of these is NO, then it's probably fine to directly inherit B from A.  If the answer to any of those is YES, then you have other options to consider:

1) Modify inheritance hierarchy: Create class C as a parent for A and B, where C includes common data and behavior.  Be aware that this requires re-validation of all code that used class A since you just broke the open/closed principle.

2) Composition: B includes A, but actually shouldn't be used as a direct substitute.  Do this when you're willing to admit there was a flaw in you logic thinking B 'is-a' A or satisfies substitution. 

3) (usually what I settle on) Define an Interface and move common data and functionality to another class: Create 'virtual' class C that defines the interface (one that doesn't violate LSP) to A and B, then create class D that includes the data and methods common to A and B.  A and B can then be composed of D, and delegate responsiblity to D's methods where applicable or define their own implementation as needed.  This still initiallly breaks open/closed principle, but makes it less likely you'll have to break it again later!

Hope this shines some light!  If you're still learning what all the above even means, then for now the blanket statement 'never inherit a concerete class from another concerete class', is probably a good mantra.

[AristosQueue (NI)]

Michael Lacasse wrote:

'Never inherit a concrete class from another concrete class' ... that seems a little extreme.  AQ, by saying that you're actually misconstruing Liskov Substitution Principle and encouraging people to break the open/closed principle!

Yes I am!

"Never inherit from concrete" is just another way of stating the Dependency Inversion principle. 🙂

Remember, none of the 5 principles can be upheld universally (that's provable). And the refactoring for a new derived class *with new requirements* is one that you can never actually future proof against. The balance point for "minimum refactoring and when you do refactor you can do so with mechanical transformation" is, in my experience, "never inherit a concrete from a concrete".

So, yeah, I sacrfice a "nearly impossible to satisfy goal of 'O'" in favor of a "easy to fulfill goal of 'D' and 'L'."

It's also the strongest piece of advice I'll give to a new programmer or to someone attempting a refactoring on an unfamiliar code base. It's your route of least resistance.

[AristosQueue (NI)]

> If the answer to all of these is NO, then it's probably fine to directly inherit B from A. 

> If the answer to any of those is YES, then you have other options to consider:

You missed the biggest question... are any of those likely to diverge in the future? For two concrete classes, the answer is almost definitely "yes." As soon as you have a concrete entity that users actually depend upon, they'll start making feature requests to make that entity special and exceptional, generally in ways that make it diverge ever so slightly from the related concrete classes.

By the way, I'm not the only person who advocates "never inherit concrete from concrete".

The More Effective C++ book advocates this strongly.  That's an industry standard textbook. See Item 33 in that book.

Here's a StackOverflow link talking about Item 33:

https://stackoverflow.com/questions/16724946/why-derive-from-a-concrete-class-is-a-poor-design

There's a JAVA discussion about going so far as to remove concrete inheritance from the language:

http://www.coderanch.com/t/327427/java/java/Banning-concrete-inheritance

Here's a StackOverflow that mentions that gets into the topic... one guy mentions that it's ok as long as you do *private* inheritance. LV doesn't have private inheritance... the only language that I know of that has that is C++.

https://stackoverflow.com/questions/3887871/is-inheritance-of-concrete-classes-evil