I'm working on a command line interface text based game. I'm writing it in C but there are various ways in which I could refactor the code by using Objective-C:  using NSDictionary to allow me to store data in Plists (easier to read/write because of the Foundation framework but much larger in size) instead of plain texthaving classes with methods (not a big thing but increases code readability)eliminating the need of converting between an object's char* name and its int/enum equivalent (using and enum to represent things reduces memory usage and complexity when using plain non-OO C, otherwise I would have to use strncmp everywhere)What I want to know is whether or not there are disadvantages to mixing OO- and non-OOP. It's still command line, which means most of it will be written in pure non-OO C.Are there any reasons for which I shouldn't mix these?
Mixing OOP and Non-OOP
object oriented;c;objective c
Object Orientation is not primarily a language feature. It is a programming paradigm/method/style. That is, you can write perfectly object oriented code in pure C, and you can just as well write perfectly non-object oriented code in Java.Object Orientation is not a virtue in itself. It is helpful most of the time, and thus rightly encouraged heavily, but there are use cases where a non-object oriented solution works just as well or better.There is no problem with mixing object oriented and non-object oriented code in the same project. Object oriented code can call non-object oriented code and vice-versa.The only problem that may come up is mixing code written in different languages. But, as Doc Brown rightly notes in the comments, Objective-C is a strict superset of C, which means that you can just compile any C code as Objective-C. This is very different from trying to compile C code as C++ code, which will force changes in many places. But that is not your problem, you can easily switch from a .c suffix to a .m suffix wherever you need it without breaking the code in the file.That said, your main focus when refactoring your game should be to simplify your code. If you know object orientation well, simplifying your code will likely mean making it heavily object oriented. If you don't know how to use object orientation well yet, try to find at least two different object oriented solutions for each problem, and try to choose the better one in each case. But don't try to keep object oriented and non-object oriented code separate.Concerning your enum/char* problem: I would suggest that you read up on string interning and try to implement it in your game. Because, once you have interned strings, you can simply compare your strings by comparing their pointer. That should allow you to reduce the enum usage in a flexible and performant way.