Re: Confusion With Inheritance

Responding to Feathers...

I swear every time someone mentions concepts in the "problem space" I go blank. There are no concepts in the problem space other than those we put there and we can reconceptualize as we need to to make software development more effective. 

.

Say what?!? The problem space is the domain where the requirements are formulated. Most customer problem spaces are quite conceptual with notions like Account, Arbitration, ..., Zone.

Those concepts certainly exist independently of software or software developers. At the OOA level a domain expert who knows nothing about software or the developer's solution should be able to describe what an object is and what its responsibilities are fairly accurately just from the name. If not, the developer has screwed up the abstraction.


That's one view of development.. and it's rather platonic.. the idea that there are these concepts floating around out there independent of us. The issue I notice is that when people think those concepts are given, they don't explore alternatives, and often the "given" concepts aren't the best ones for software.

I submit there are very strong reasons why one wants software to map very closely to the relevant problem space concepts. (In fact, one can argue that one reason the OO paradigm exists is to allow exactly that sort of of correspondence.) Any complex solution needs a basic structure upon which the details are hung. In addition, in most customer problem spaces things change and that is reflected in requirements changes that cause the software to be changed. (Computing spaces tend to be mathematically defined so they are less subject to change at a fundamental level, though technical implementation technologies change.)

Customer's don't like change any more that software developers do. So they accommodate change in a manner that causes least disruption to their environment. Any requirements changes that filter down to the software will already reflect those accommodations. Now if the basic software structure closely reflects the fundamental structure of the customer's problem space, then accommodating those requirements changes should affect only the details hung off that structure. That's because the customer has already chosen the path of least disruption.

OTOH, suppose the software structure does not closely parallel the customer's fundamental structure. Then we risk needing to change the fundamental structure of the software to accommodate a simple requirements change (IOW, a massive shotgun refactoring).

The primary tool we have for ensuring good mapping to the problem space lies in OOA solutions because those define what is important to the customer. That is, the OOA solution is necessarily the customer's view of the world and its fundamental structure. Then when we migrate through OOD/P and add solution elements to accommodate the computing spaces, we do so within the OOA structure and the preserves the necessary architectural mapping for long-term maintainability.

So there is no problem with exploring alternatives to address things like nonfunctional requirements within the constraints of the computing space. But it needs to be a disciplined exploration that preserves the fundamental OOA structure.



I am curious, though. I have a description of a language interpreter in this blog: http://www.artima.com/weblogs/viewpost.jsp?thread=120750

It's something I've been working on in my spare cycles. If you're game, I'd love to hear what the "problem space" is for my interpreter and whether I'd be screwed if I didn't use them in the work I'm doing.

By your own admission, you don't have a customer problem space yet because you have not defined any goals for utility (i.e., what sorts of problems the language should be good at solving, what sorts of developer Hot Buttons you want to support, etc.).

OTOH, there are <at least potentially> several relevant problem spaces: linguistics, interpreter design, hardware computational models (Turing & von Neumann), set and graph theory, etc. IOW, many of the classic computing spaces because your problem basically exists in the computing space since it is a 3GL.

From the blog blurb my impression is that you have chosen to mix & match from existing languages as a shortcut to dealing with the technical problem spaces above. Since this is essentially a recreational activity that's fine. But I think that if this were a commercial undertaking you would have less flexibility with the definition of quality and would have to deal with the technical fundamentals directly. In that case you would be driven to provide meta-models and extract invariants from those problems spaces that would ultimately be reflected in syntax. Those invariants would, in turn, drive the abstractions for the interpreter software.

Of course the interpreter itself is a distinct subject matter with its own problem space. Once the language meta-model and syntax is defined one faces a quite different problem in converting that representation into machine instructions correctly. Clearly you would need abstractions based on the linguistic properties, abstractions for parsing and syntax processing (e.g., BNF-based), and abstractions for the platform.

Apropos of our overall discussion, I assert that you would not have a lot of choice about the abstractions you extract from those problem spaces at the OOA level. For example, in a BNF processing context objects like Production and Terminal are tough to avoid. Similarly, for lexical analysis syntactic notions like Statement, Expression, and Token are tough to avoid.

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.

Quantcast