I am writing a program in Python, which basically manipulates strings, and I was wondering whether I should do it using OOP principles or not. The client did tell me he doesn't care about the code, he just want the thing done.I know that object-oriented code is not by definition cleaner, and conversely non-OO code is not by definition crappy. The question I'm asking might be more or less opinion-based but there might be some rules that I'm not aware of.Some more info about what's to be done:parse a .csv file and process the data based on a config file (the columns may be different - like in the number of columns or the data they hold)use the above processed data to create a new custom formatted data (or multiple files based on some of the above values)use the last formatted data to create an XML file.split the XML file in multiple XMLs based on their contentthe application should be CLI-basedthere are of course other things like: logging some events, parse CLI arguments, and so on.Now, this isn't at all a big / hard application, and it's also almost finished but during the whole development process I was keep asking myself if this should be done using OOP or not.So, my question would be: how do you guys, know/decide when to use OOP in an application?
When do we actually use object-oriented programming?
object oriented
Python is a multi-paradigm language which means you can choose the paradigm most appropriate for the task. Some languages like Java are single-paradigm OO which means you will get headaches if you try to use any other paradigm. Posters saying always use OO are probably coming from a background in such a language. But fortunately you have a choice!I note your program is a CLI app which reads some input (csv and config files) and produces some output (xml files), but is not interactive and hence does not have a stateful GUI or API. Such a program is naturally expressed as a function from input to output, which delegate to other functions for subtasks.OO on the other hand is about encapsulating mutable state and is therefore more appropriate for interactive applications, GUI's, and API's exposing mutable state. It is no coincidence that OO was developed in parallel with the first GUI's.OO has another advantage in that polymorphism allows you a more loosely coupled architecture, where different implementations of the same interface can be easily substituted. Combined with dependency injection this can allow configuration-based loading of dependencies and other cool stuff. This is mostly appropriate for very large applications though. For a program the size of what you describe, it would be far to much overhead with no apparent benefit.Apart from the functions actually reading and writing the files, the bulk of your logic can be written as side-effect free functions which takes some input and return some other output. This is eminently easy to test, much simpler than testing OO units where you need to mock dependencies and whatnot.Bottom line: I suggest a bunch of functions split into modules for organization, but no objects. 