Register a collection of tested object and get one configuraton out of it

Question

I have a yml configuration file that list multiple application. Each application can contain multiple configuration. And of course each configuration can contain multiple mode

apps:
  - name: foo
    group:
      - group_1
    configs:
      - name: config_1
        options: [a, b, c]
        solution: solution path
        modes:
          - name: mode_1
            options: aaaa
          - name: mode_2
            options: ...
     - name: config_2
       ...

   - name: bar
     group:
       - group_2
     configs:
     ...

I have designed a Collection object that store all these applications as object. An application will have a name, group and a list of config object. Same for the config, it will have a name, options and a list of modes object...

My question lies here. One of the api of my framework will need a specific application configuration to be used. It will need an object that contain the name of an application, the name of one of it's config and a mode of this config.

class AppConfig:
    name: str
    config: str
    mode: str

def the_api(appconfig):
    pass

Is it better to store in the collection a list of every single type of configuration (flatten the entire yml into multiple AppConfig object) or do what I have done (Create an App object that contain a list of config...) filter the collection and create an AppConfig object that will be use by the api when needed?

Is there any design pattern for this ?

I believe that the answer might be just a question of time processing versus a well architectured framework that will be able to evolve easily. Does anyone had encounter this king of situation ?

Answer 1

I believe as Software Engineers we encounter this problem every time we write a function.

Do we pass in exactly what a function needs to do its job, or do we pass in a shared data structure which possibly holds much more?

The answer is it depends.

If for example the function in question is count() and it is counting the number of items in a hash set. Then it stands to reason that we would pass in the shared data structure of the hash set.

The alternative would be to force the caller to extract every item and pass it in to count(). The problem is that to the caller marshaling x items into a new structure and passing ti to another function, is more computationally expensive than just looking for each item and counting.

On the other hand it makes sense to pass in just the data that is needed to some operations such as add(1, 2). Making them use a common data structure only serves to make matters more complex.

For example the data structure would have to have a way to tell add() which of the numerous numbers it holds need to be added. Alternately there would need to be more than one version of add. eg: add_first_and_second(), add_first_and_third(), add_a_and_t(), ...

---

To get a bit more detailed, passing a shared data structure into a function is best when:

1. It reduces the total number of functions overall who directly access the shared data structure. (modularity)
2. It does not unnecessarily complicate the function, or the data structure. (complexity)
3. The data structure and function are always changeable together, and are deployed together. (cohesion)

Passing just the data needed by the function is best when:

1. It is used in many places by different modules/components. (modularity)
2. Not doing so would make using the function more complicated for the caller by passing along extra targeting information, or having multiple variants of the function. (complexity)
3. The cost of calling is expensive, such as when invoking an api across a network. (efficiency)

---

In your specific example I would lean toward passing in just the data required.

Because to pass in the config itself would increase the coupling between the configuration and this function.

• This decreases modularity as more functions must necessarily know how to handle a configuration object tree.
• These functions then need to be edited and deployed together to ensure consistent handling of the data-structure.
• Which causes issues for deployment (as it appears to be an external API) which requires all the binaries (libs and exe) on both sides of the call to be deployed together.