conceptual "stacks" and code layers in programming

Question

I have been thinking a lot lately about how code gets organized in a layered way. I have been thinking of four different ways:

1. Instantiation -- specifically objects are instances of classes. However, in several languages (like python), classes are also objects that were instantiated from a metaclass. So you can end up with an instance stack of objects.
2. Inheritance -- you end up with a stack of super classes. Even when you have multiple inheritance you end likely have a way to turn it into a stack (like the MRO in python).
3. Namespaces -- scope is typically layered too.
4. Calls -- the call stack is probably the most familiar and the oldest conceptually. It is the mainstay of programming.

You could argue that instantiation is just a different sort of call stack, and that inheritance is just another namespace stack, but regardless these are what I thought of.

So does anyone have any other conceptual stacks that fit in here, or do calls and namespaces sum it all up? Any other thoughts?

Answer 1

I'm not sure what you're getting at, but another type of "stack" might be dependencies. For example, if A uses classes B and C, and class B uses D and E, while class C uses F, then you end up with a stack of layers like this:

+---------+
|    A    |
+-----+----
| B   | C |
+-----+---+
| D E | F |
+-----+---+

Also, I think what you are calling a "namespace" would more generally be called a "package", which is some sort of set of related classes.

Answer 2

As far as I understand your question you are trying to think about how to implement an object oriented runtime environment. You are right that a stack could be uses for most of the problems but I think that the concepts are more important than how they are implemented. Maybe you should be more more specific. What is the reason for this question. Do you have a particular problem you can not solve?

Answer 3

I think this is a very good question in that it makes us think about the way we structure software. Structuring software is necessary to create a layer of abstraction between the code and its architecture.

I have lately come to the conclusion that horizontal layering is a convenient technique, but vertical partitioning is more useful. An example of horizontal layering would be the classical DAL->BAL->GUI scenario while vertical partitioning divides the application into the features that it supports.

The model of a stack is obviously present in the horizontal layering model. But also when vertically partitioning functionality you can find the stack model. What I find particularly appealing about vertical partitioning is the idea that each of my vertical slices can have its own horizontal layering stack, an idea that is resembled in patterns that grow more and more popular like CQRS. There can also be dependencies between the vertical partitions of your application, again modeled as a stack. But sometimes this is not sufficient and you need a more sophisticated abstraction than a stack, such as a graph.

Abstracting away from that, I think the reason we like to think in stacks is because we can see things at varying levels of abstraction, pushing/popping things on the stack on demand. Other structures like Graphs are sometimes more suited to describe problems like dependencies between components, but they are more complicated and thus not as convenient as stacks.

That is also the reason why multiple inheritance was ditched: A graph of dependencies (multiple inheritance) is much harder to understand than a simple stack (single inheritance).

What else can be modeled as a stack? Frankly, I think what we have here is quite a lot and get's you very far:

• Inheritance Hierachies (single inheritance)
• horizontal, architectual layers
• vertical architectual layers (feature composition)
• simple, linear dependencies (call sequences, wrappers, facades)