Is updating a macro value in the Xcode preprocessor's macros violating the open–closed principle?

Question

For example, for some Xcode projects, if I have some places that defines a number at some .cpp files:

const int PAGE_MAX=5;

and a new requirement comes that needs to change PAGE_MAX, I need to modify the .cpp file, and it is violating the principle. What if I define PAGE_MAX with macros? For example,

const int PAGE_MAX=XCODE_MACRO_PAGE_MAX;

but XCODE_MACRO_PAGE_MAX is not defined in other headers ,.c,or .cpp files, instead I add the define in the Xcode → Preprocessor macro session:

XCODE_MACRO_PAGE_MAX=5

When I need to update the value, I open the project in Xcode and go to the "Preprocessor macros" session to change the value of XCODE_MACRO_PAGE_MAX in the UI, for example, from XCODE_MACRO_PAGE_MAX=5 to XCODE_MACRO_PAGE_MAX=6.

While I don't need to edit the .cpp file, the macro replaces XCODE_MACRO_PAGE_MAX with the new value, which feels the effect as if changing the .cpp file actually when changing the macro value. Is it violating the open–closed principle (OCP)?

Answer 1

If your requirements have permanently changed, just change the code already. Anything else - including slavish devotion to the open-closed principle - is abstraction for abstraction's sake and does not improve your codebase in any way.

Answer 2

First, make sure you have understood that the OCP is not violated at the time when you change some source code, see my answer here for a detailed explanation. The OCP is followed or violated at the time when a certain component is designed, and whether the OCP is followed or violated depends on the fact it's behaviour can or cannot be changed without changing it's source code afterwards.

In it's strongest form, the OCP is about binary components which might be reused in a parametrized fashion by someone who does not even has access to the source code. Still, I think the principle can also be applied to components deployed in source - the technical impossibility to change the source code of a component isn't mandatory for the OCP, it is about the non-necessity changing the code.

Now in the described case, this boils down to the question

• what exactly counts as the source code of your component? Is the XCode project file (the place where XCODE_MACRO_PAGE_MAX lives) part of the source, or not?

• can this component be reused and adapted in a black-box fashion, for example by different groups or people who will never change the source code?

I guess in the described case, it makes usually most sense to count the cpp and header files together with the related XCode project file as the source code of your component. In this case, the component is not OCP compliant.

However, I can also imagine a scenario where you define a group of headers and cpp files (without the XCode project itself) as "the source code of your component", and deploy this group of files into different XCode projects with different XCODE_MACRO_PAGE_MAX settings (maybe projects in different Git repositories). In that case, I think it could be justified to say your component is following the OCP - in some sense.

So in short, it depends on where you draw the borders of what belongs to a component, and the responsibilities for the maintenance of the component's source code itself vs it's parametric parts.

Note that following the OCP should have always a clear purpose, since it comes for the price of higher complexity. If the person or team who maintains the headers, cpps and project file for the component is the same, and your project does not have different build configurations with different PAGE_MAX values, then moving the default PAGE_MAX value into a macro XCODE_MACRO_PAGE_MAX in the project file introduces will probably not be worth the hassle. And when in doubt, prefer the simpler solution over the more complex one.

Answer 3

Step back a bit, and look at the purpose of the OCP: it is part of a set of principles or rules used to make your code better, more robust and maintainable. Making your code better is the actual goal. Any time the OCP would actually make your code worse (presumably this will be rare), set it aside for that particular change.

The larger question here might be, what would you get in return for the effort of introducing the macro? Do you expect this component to only ever be used in one place, or many places with different PAGE_MAX settings? It is part of your job to manage resources, including your time. Does it make sense to spend extra time on this right now?

You don't have to know about multiple uses now. If it does end up (unexpectedly) being used in more than one place, with different PAGE_MAX settings, that is the time to introduce an external parameter -- or parameter object that can provide multiple settings, as in my experience it's seldom just one setting required.

Answer 4

The open-closed principle is there to help you. So if you have the choice between violating the open-closed principle and not getting your job done, you get the job done.

But you also have a fundamental misunderstanding about what “closed” means. Whoever put the macro definition into the pre processor file closed the code to modification and opened it to behaviour changes from the outside. So changing the macro value is exactly what you should do. It is exactly following the open/closed principle.