Timelord

Okay. It seems you already made some design decisions and I try to shape the following answer while keeping those in mind. I want to emphasis that the described way is not the only way and that I still believe that there are multiple equally good, but different approaches. The following just describes how I would decide, if I had to implement it. I strongly like object orientation, so I always "configure" my instances at the earliest point possible. If you store your settings globally at one single point then this implies that you either have to "pull"/"ask"/"fetch" your individual criteria for parsing each time or that you will end up duplicating your concrete setting inside by storing it inside your instance. For example: There is one parser function traversing a log file. There will be several if conditions inside the code repeatedly checking the global setting. Opposed to that approach you also can "push" your settings implicitly into the structure of your program at the time of creation. For example: If there are multiple possible ways of formatting a line inside a log, there will be multiple (maybe configurable) classes; each implementing one of the possible formats. I guess you currently use the first described approach. This is totally legit. It works, so why not. There are two different general approaches to access this "global" data, though: Either there is a "global" variable and you use this everywhere. Since your program only uses this one configuration in one run this is totally legit. If your program is very small and clear with less settings I just would implement it this way. I tend to avoid it if there are many settings, because there will sometimes be the problem of depending on "unneeded settings": Having one global settings record implies that there will be all information in one place. If every object has access to that variable, it can potentially read all items of the record, which violates the privacy principle of some definition of object orientation: you only want to make the needed parts visible, but nothing more. The solution: Pass the settings through the constructors at the time of creation or use setters after the time of creation. This divides the information and puts it directly where its needed. Since your application uses constants (constant setting) during one run, this is easy. Therefore your idea to load the settings at the start of the program looks legit to me in this case. There are several so called software patterns, for example MVC (model, view, and controller): It's good to separate and organize the structure of your program. Storing the data separate from the UI is seen as a good idea from many developers. As mentioned above this is only my opinion and there are several legit ones, so do not take my proposal as law. 😉 Please wait what others have to contribute. Oh; and CLI stands for "command line interface". It's just a term I am more used to... (I understood "cmd", though) If you have some questions on some of the above, just ask 🙂 Kind regards, Timelord

Hey Mike! I have some questions about your approach: Are you generating two binaries (one with the UI included and one to be used from CLI only)? Or do you compile one binary to be used as a hybrid? If I read between the lines I guess your UI currently is used to hold state/settings of your application. So, if you derive two executable binaries, as described above: Do you want to use some or all of your logic code in both binaries (shared code usually implies easy maintenance)? What does your CLI look like? Is it an interactive program? Does it use CLI dialogs, mimicking a fully graphical UI or is it text mode only? Does the user repeatedly interact with several settings? You asked for the "right approach". Imho there is no "right" approach here. There are several usable approaches, each with its pros and cons. I propose to take a step back and answer one question first: What needs your tool? For example: Is your tool launched several times concurrently and will there be the chance of conflicting settings (race conditions, "syncing problem" between instances)? Are settings changed often? Does your program run for long time periods? What could be damaged, if your program crashes before it had the chance to save the settings to registry? Are you accessing settings often during the program livetime? Do you need all settings to be present in the CLI version of your program (maybe there are some settings only affecting "visual" behaviour?)? Try to classify and sort your program's demands by importance. Then optimize against the top priority properties first. If a "lower" prior demand conflicts against something you already optimized before, ignore it. Maybe your tool does nothing system critical at all and it sometimes does not matter at all HOW you solve it, but only HOW QUICKLY and CLEAR/READABLE/UNDERSTANDABLE you solve the problem itself to proceed to more important matters? Maybe this helps you and others to answer your original question/problem better... Timelord