Does 'open-closed principle' also includes files and data of the app? According to https://softwareengineering.stackexchange.com/a/296955/248528, it says files and data are't included, but it doesn't mentions if they should be included.

Suppose I have 2 ways to define the locale string of my app:

Method 1 : all locale strings in a single file:


        'en':'Welcome to use the app',
        'es':'Bienvenido a usar la aplicación'

pseudo code to load locale : load locale.json directly

how to add a new locale: edit locale.json, add a new key at each string

Method 2 : one json for each locale


    'hello_message':'Welcome to use the app'

    'hello_message':'Bienvenido a usar la aplicación',

pseudo code to load locale : search and load all locale_xx.json files in specific app data folder

how to add a new locale : add a new locale_xx.json file in specific app data folder

My question is, suppose I may need to add a new locale in the future, and the code to handle keeps unchanged, is Method 2 preferred because it follows 'open-closed principle?

  • 1
    The SOLID principles apply to classes, not data. Legions of programmers get themselves into serious trouble trying to apply the SOLID principles (which are already not well-understood by most folks) to other things. Mar 2, 2018 at 4:38

1 Answer 1


This is about more than the open closed principle. This is about predicting change. Predicting change is hard.

Method 1 (a single file) makes it easy to add new features. It makes it hard to add new languages.

Method 2 (a file for every language) makes it easy to add new languages but hard to add new features.

I call this the interleaving problem. Your config file is laid out linearly so it has one dimension. But you're subject to change from two dimensions.

You can either lay your config out in two dimensions, use editing tools that present it in two dimensions, just deal with the interleaving when it happens, or try to force the future to behave the way you expect. After decades at this I can tell you the future does as it likes.

A sneaky trick that I've used is to abuse the file system by making an entire folder into your config. Fill it with files named title.en and title.es. Then you can sort it either way.

I've seen people solve this with spread sheets or databases but I prefer to use a lightweight solution if I can.

The open closed principle centers on the idea of organizing so that change can happen without having to edit what already works. Believe it or not the sneaky trick follows that fairly well.

  • Yeah, but should files/data follow rules like 'open-closed principle'? Mar 2, 2018 at 5:17
  • @RobertHarvey better? Mar 2, 2018 at 5:33
  • Actually, I think programmers under-use database technology. Obviously standing up a database server is neither practical or desirable in many circumstances, but embeddable databases like Sqlite (as much as I loathe it) are often good solutions to a lot of these sorts of problems. That said, there is definitely benefit to end-user editable configuration files. I'm not sure if that concern applies here, if not, there are a lot of benefits to using a database. Mar 2, 2018 at 21:52
  • @DerekElkins: You loathe it? Why? Mar 2, 2018 at 22:05
  • @RobertHarvey I think many of its "features" are misfeatures (including the "manifest typing" thing), and they aren't just presented as "these are the design decisions we made" but as if Sqlite is so much better for having made them. I've also run into annoying limitations like lack of a real datetime type/functions, lack of recursive queries though those have since been added but not window functions. You definitely feel the difference when compared to something like Sql Server. All that said, Sqlite seems alone in its niche and is a better alternative than even an embedded key-value store. Mar 2, 2018 at 23:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.