Conceptual "stacks" and code levels in programming

Question

I’ve been thinking a lot lately about how code is organized in a layered way. I thought of four different ways:

• Activation - in particular, objects are instances of classes. However, in several languages ​​(e.g. python), classes are also objects that were created from a metaclass. This way you can get a stack of object instances.
• Inheritance - you get a stack of superclasses. Even if you have multiple inheritance, you end up probably have a way to turn it into a stack (e.g. MRO in python).
• Namespaces - A domain is usually also multi-layered.
• Challenges - The call stack is probably the most familiar and oldest conceptually. This is the main part of programming.

You can argue that instantiating is just another call stack, and that inheritance is just another namespace stack, but no matter what I thought of.

Does anyone have any other conceptual stacks that fit here, or are calls and namespaces summarizing all this? Any other thoughts?

Answer 1

I think this is a very good question, because it makes us think about how we structure the software. Structuring software is necessary to create an abstraction layer between the code and its architecture.

Recently, I have come to the conclusion that horizontal layering is a convenient method, but vertical splitting is more useful . An example of horizontal layering is the classic DAL-> BAL-> GUI script, while vertical splitting divides the application into supported functions.

The stack model is obviously present in the horizontal stratification model. But also with a vertical breakdown of functionality, you can find a stack model. What I find particularly attractive with respect to vertical splitting is the idea that each of my vertical slices can have its own stack of horizontal layers, an idea that looks like models that are becoming increasingly popular, like CQRS. There may also be dependencies between the vertical sections of your application, which again are modeled as a stack. But sometimes this is not enough , and you need a more complex abstraction than a stack like graph .

Distracting from this, I think that the reason we like to think in stacks is that we can see things at different levels of abstraction by clicking / stack on demand. Other structures, such as Graphs , are sometimes more suitable for describing problems, such as dependencies between components, but they are more complex and therefore not as convenient as stacks.

This is also the reason why multiple inheritance was imposed: a dependency graph (multiple inheritance) is much more difficult to understand than a simple stack (single inheritance).

What else can be modeled as a stack? Honestly, I think we have a lot here, and you are very far away:

• Hierachies inheritance (single inheritance)
• horizontal, architectural layers
• vertical architectural layers (component)
• simple, linear relationships (call sequences, wrappers, facades)

Answer 2

I'm not sure what you're referring to, but another type of "stack" may be dependent. For example, if A uses classes B and C, and class B uses D and E, while class C uses F, then you get a stack of layers like this:

+---------+ | A | +-----+---- | B | C | +-----+---+ | DE | F | +-----+---+ 

Also, I think that what you call a “namespace” was more generally called a “package”, which is a collection of related classes.

Answer 3

As far as I understand your question, you are trying to think about how to implement an object-oriented runtime. You are right that the stack can be used for most problems, but I believe that concepts are more important than their implementation. Maybe you should be more specific. What is the reason for this question. Do you have a specific problem that you cannot solve?