You appear to be using the "inheritance is my hammer" ideology... Lemme try to explain. Maybe it's just me, but I seem to have managed to unlearn much of my OO schooling due to seeing industry abuses of it, and have rediscovered how to make OO fun again.

I see over-reliance on inheritance as one of the major pitfalls of OO design. When you see something complicated, the right thing to do is not to hack around it to make a more complicated solution, but to step back, look at the design, and clean it up. In this case, inheritance is your hammer, but the solution appears to be composition and chaining objects together.

If you are making a FooBarThing, don't let it extend FooThing and BarThing, or mixin Foo or Bar and subclass Thing, it doesn't have to be so complicated.

Have a MetaThing that takes any array of Things, and (though some combination functions) runs them together. If Things were Filters, a FooBarThing might run the filter results of Foo into a Bar, for example. This can even be totally dynamic, as in MetaThing(new FooThing,new BarThing).

If FooThing and BarThing are not sufficiently alike to have a common superclass, we have a problem, and we appear to be going down the mixin path. But I have found that if you make your objects real enough (nothing like Base without knowing what a Base really IS), you don't go down the mixin path.

I can go on further, but in case this doesn't make sense I'll wait and see if anyone understands what I've just said. The basic idea is "inheritance is only one tool in OO; and it is overused -- we can blame some of this on bad schooling from Java -- KISS still applies". If the mighty hammer of composition/encapsulation and polymorphism were used at an equal level as inheritance to solve design problems, much of the world's code would be a lot simpler and more maintainable.

As we go to further and further extents to make OO feel right, we lose the grasp of what OO is supposed to be. Keep it simple, design such that these situations do not occur, and when they do (and they will), find simple solutions out without symbol table manipulation and evals and such -- it is better to keep things clean and basic.

Anyhow, by no means am I an expert in my theory, and it's not the only way, but I do find OO much less distasteful when I start to temper the inheritance-hierachy thoughts that are so common these days, and start to put order back into designs. OO design that can't be articulated in simple diagrams can't succeed. The entire black box concept can't devolve into the "great ball of mud" designs java programs face. Anyhow, this has little to do with simon...but it's an interesting thing to watch. Using inheritance as the proverbial hammer is a gateway drug to overcomplicated interfaces. Mix in sic some functional programming, and remember what procedural programming taught you about simplicity being the only way to maintaince. And by no means build a shoehorn. Ever. (Unless you run a cobbler shop)

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.