Entry Way

Prefice: Abbrev. sentences because can't type 2 much. Small sentences aren't dogmatic, just can't explain. These opinions likely to change even if they are opinions. This is for software geeks, probably.

Inheritance sounds neat. Looks neat. Can be neat. In practice, it can be very confusing. Easy to get lost in structural relationships rather than functionality. It's elegance is luring. It is one of the few things that seems correct, but often comes up with disaster. But it *can* be good.

I feel like a castaway sometimes. Seems like there are two sides of the fence: you design and think OO (object oriented) or you are a "QAD" hacker.

The "Design Patterns" approach to OO seems to answer many of my doubts about OO and "design" in general.

Thinking of an object in terms of functionionality (like Tcl/Tk's "commands") seems better. Encapsulating variation rather than data seems healthy. Focusing on object responsibility rather than an object's "is-ness" seems good. Embracing object aggregation (of other objects) for delegation purposes can work better than inheritance. There's great power in a well defined interface.

"Design Patterns" emerge from dealing with similiar problems. Lots of problem solving leads to a "pattern".

In architecture, one pattern is entry ways. It feels unnatural to enter/exit a building that has no overhang above the door. The back of stripmalls have those doors stuck on the building. Workers exit them to smoke. They look bare. Uninviting. The "pattern" of overhangs developed over time. They work.

Better not type anymore!