3 Replies - 484 Views - Last Post: 04 March 2013 - 07:07 AM Rate Topic: -----

#1 adn258  Icon User is offline

  • D.I.C Addict

Reputation: 11
  • View blog
  • Posts: 762
  • Joined: 31-August 11

Is It Better To Load Settings Into Variables Or Load Settings Directly

Posted 03 March 2013 - 07:43 PM

So This might sound confusing but let's say for example that you have a program with a bunch of settings to be set. For example MainWindow which has a few properties that can be set one a string for Keyword then another property for WindowColor of the window itself, and Lastly A Boolean Variable For Play Noise.

A user then clicks a settings button which opens up a dialog window where these settings can be changed. There's a few ways to go about doing this.

First you could load the current settings which could be in variables i.e. FIELDS within the first window class and place then in the constructor on opening of the next window. The next window would then load the GUI controls to the constructor values and then upon dialoag result ok you could have properties set things in the original window.

There is a more direct way to do this however and that is the program will use default settings on it's first load and get and read everything for there.

For example the user opens up the setting window those settings set the GUI values to the current settings by just reading the user settings (NO VALUES PASSED IN THE CONSTRUCTOR) and then that window closes it just changes and saves the settings.

Then when the main window receives DiagloagResults of OK it simply reads the settings that were just changed by the settings window without having the need for any other FIELD VARIABLES AT ALL!!

Which method is better and why?

Is This A Good Question/Topic? 0
  • +

Replies To: Is It Better To Load Settings Into Variables Or Load Settings Directly

#2 Skydiver  Icon User is offline

  • Code herder
  • member icon

Reputation: 3576
  • View blog
  • Posts: 11,121
  • Joined: 05-May 12

Re: Is It Better To Load Settings Into Variables Or Load Settings Directly

Posted 03 March 2013 - 09:17 PM

In the early days of my programming career, I thought that your latter approach was the best thing since sliced bread because it seemed like I had to deal with less things. But then at that time I was also coming from a background of procedural programming in BASIC and assembly where globals where de rigueur. As I started teaching myself/learing object oriented programming, as well as when my programs became more and more complex, I realized the folly of going down that path. Since then, I would much rather have an settings object that can be passed around between the main form and the settings form. If I really needed it, I would also setup events fired by the settings object when its state changes.

Why? This seems like so much more work than just going with the global? The reason is because of testability and clean designs. If you were playing with a global object or state, there is no way you could do a unit test and not to lie to yourself and say it's not an integration test, it's really a unit test. You will have to somehow have to involve the filesystem or database depending on where you are persisting your settings.
Was This Post Helpful? 1
  • +
  • -

#3 CodingSup3rnatur@l-360  Icon User is offline

  • D.I.C Addict
  • member icon

Reputation: 991
  • View blog
  • Posts: 971
  • Joined: 30-September 10

Re: Is It Better To Load Settings Into Variables Or Load Settings Directly

Posted 04 March 2013 - 05:04 AM

I completely agree with Skydiver. The approach of passing things in to objects is generally the much better approach. However, note that whilst your first approach is better than your second approach, you are still reaching out to global state in the main window in your first approach, which may not be ideal still (see my real world example below for a possible alternative).

Moving on, there are other issues with reaching out to global state, besides the lack of testability (which is already a good enough reason to avoid it). Three such issues are:

1) Reusing code that reaches out to global state is usually much harder than reusing code that has everything it needs passed in to it.

2) It harms the intuitiveness and clarity of the API you are providing. For example, when you, or a colleague, or (much worse than the aforementioned), an external user of the API, wants to use your form, if everything it needs is passed in via the constructor, it's crystal clear what the user needs to do in order to use the class. However, if your first approach is used, they'll probably end up digging around in the implementation details of the class to find out what they need to do to use this class. When this happens, you've failed as an API designer.

3) The lack of polymorphism and flexibility when trying to unit test code that reaches out to global state, i.e. the code that reaches out to the global settings will be inflexible when requirements change, and extensions are required etc.

Real world Example

In our recently deployed application at work, I use an app.config for storing things like paths to sound files, environment information etc that the application needs. I could have handled this by creating a static class that provides access to all these settings. However, how I have actually handled this is by creating some custom classes (a sound player class, an environment resolver class etc), and on application startup (essentially in Main() before any forms are created) I reach out to the configuration file, get all the setting I need, create instances of my "settings" objects (passing in the appropriate values from the configuration file), and those instances are passed into the application (often via the constructor of the main form's presenter (and the presenter is then passed in the main form's constructor)). The objects can then be passed around if required.


Note on mutable global state

That's just for immutable global state (which is plenty bad enough!). If you are changing those settings (i.e. mutable state) from within your code, things get much worse if you are reaching out to that global state from within your application. I won't go into all the problems that will arise there, but suffice to say you should very strongly aim to avoid it :).

This post has been edited by CodingSup3rnatur@l-360: 04 March 2013 - 08:00 AM
Reason for edit:: Typo and fixed error

Was This Post Helpful? 1
  • +
  • -

#4 tlhIn`toq  Icon User is offline

  • Please show what you have already tried when asking a question.
  • member icon

Reputation: 5529
  • View blog
  • Posts: 11,839
  • Joined: 02-June 10

Re: Is It Better To Load Settings Into Variables Or Load Settings Directly

Posted 04 March 2013 - 07:07 AM

Objects. Especially if you have any plans to more forward to the current approach of WPF, where binding GUI properties to object properties is the way things are done.

For example, I have a program that can run in one of three different modes. Let's say Clerk, Supervisor and Technician modes.

For that there are 3 radiobuttons on the Options panel so you can set which mode to open in at launch time: rbClerk, rbSupervisor, rbTechnician.

That means an enum of:
enum OperatingModes
{
   Clerk,
   Supervisor
   Technician
}


You can then bind the radiobuttons to your OptionsObject.StartupMode property.

Therefore, changing the radiobutton changes the property - or changing the property changes the radiobutton that is checked. At program launch, you seserialize your options.xml file and *bam* everything updates due to the binding. And the program goes to the right mode.

Its a learning curve from WinForm, but it has an elegance to it and it just 'feels' so very OOP and clean.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1