Is “file” also participate in open closed principle?

Question

I know according to open closed principle, something like class,interface,code.... should be unchanged when add new functions or contents, but is file also in this case?

I was designing a game, the game have some monster information, and the game (in client side) may download or replace some file if there are new monsters to add or update.

I was worrying what should be the format of monster information: 1 file with all monster information or each monster has individual file?

1.Store all monster information into a single file (e.g.:monsterlist.json),each time add new monster it will replace the file e.g.:

{  
    "monsterList":[
        {
            "id":1,
            "hp":100,
            "attack":230,
        },
        {
            "id":2
            "hp":500
            "attack":980
        }
    ]
}

2.Each monster has a individual file,each time add a new monster will also add a new monster json:

monster1.json

{
    "id":1,
    "hp":100,
    "attack":230,
}

monster2.json

{
    "id":2,
    "hp":500,
    "attack":980,
}

At start I think case 1 is most convenient, because when I add or update any monsters I only need to replace monsterlist.json, but for case 2, I need to know which json is new (may need extra row to store the update status in server database).

But suddenly I remember open closed principle, adding something new should not modify the current content, it seems not reasonable to replace a file when a new monster is added.

Note: I am not asking which format is better (which is opinion based), the example above is just the background information to illustrate why I would have this question. The thing I want to ask is just : is “file” also participate in open closed principle?

Answer 1

Short answer

No. The Open/Closed principle applies to object-oriented software constructs such as classes, not data.

Long answer

When evaluating programming patterns and principles, it's important to understand why the principle was created in the first place, how it applies to programming, and what exactly it applies to. Without that understanding, it's very easy to learn about a principle for the first time, think it applies to everything, and apply it indiscriminately or even in a way that causes harm.

For example, the phrase "premature optimization is the root of all evil" is misused all of the time to mean things like "don't optimize until later," or worse, applied to things for which it has no relevance, such as sensible software design. What the phrase really means is "measure first, then optimize only those parts of your code which your measurements say will produce tangible benefits." It doesn't say anything about not following sensible design principles from the start. In addition, that's not actually the entire phrase, so some meaning is lost if that's all you quote.

That said, let's examine the Open/Closed principle.

In object-oriented programming, the open/closed principle states "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification ¹

Object-oriented programming, as the principle implies, primarily involves code, not data. Some readers will argue that "code is data," or that "some data has object-oriented features such as inheritance," which are both true. But the principle that we're talking about here is intended to be used within the context of object-oriented programming in the traditional sense, not as a principle to be applied to data.

The Open/Closed principle is the O in SOLID, the five principles that, when applied together in an object-oriented software design, intend to make it more likely that a programmer will create a system that is easy to maintain and extend over time.²

Single responsibility principle

A class should have only a single responsibility (i.e. only one potential change in the software's specification should be able to affect the specification of the class)

Open/closed principle

"Software entities should be open for extension, but closed for modification."

Liskov substitution principle

"Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program." See also Design By Contract.

Interface segregation principle

“Many client-specific interfaces are better than one general-purpose interface.”

Dependency Inversion Principle

“Depend upon Abstractions, not on concretions.”

Notice the wording of these principles. They all refer to "software entities:" classes, modules, functions, interfaces and so on, all staples of the Object-Oriented paradigm. These are not data, in the traditional sense, though they may contain data. Data follows a different set of rules, and a different vocabulary: immutability, atomicity, durability, etc.

Read Robert C. Martin's Clean Code and you will get a very good perspective on the proper context in which these terms are used.

---

¹_{Meyer, Bertrand (1988). Object-Oriented Software Construction. Prentice Hall. ISBN 0-13-629049-3.}

²_{“SOLID Object-Oriented Design”, Sandi Metz (Duke University), Talk given at the 2009 Gotham Ruby Conference in May, 2009.}

Answer 2

Though I think @RobertHarvey's answer is really good, I would like to add an answer from a more practical point of view.

The answer to your question depends simply on how you map your OO constructs to files. If classes are in 1:1 relations to files, "change of class" means "change of file", there is no difference. If you store all classes of a specific layer or type in one file, and you want to add another class, you obviously must change the file when adding another class. And when you do not even have files (because your code is stored, for example, in a database), it is pretty obvious that files do not participate in the OCP.