Thank you for any assistance available to the new guy!
A "code sample" of what I'm trying to do is provided below.
1. While running in the Main method in the MyApplication class, I can instantiate and reference members in a second InitConfig class. I'll name this instantiated class object myInitConfigBuilder.
myInitConfigBuilder has a number of properties/methods that provide useful configuration information that could be used throughout my overall application. When I access MyInitConfigbuilder from Main I'm still under the control of the original MyApplication class. Works like a champ.
2. The Main method in the MyApplication class then instantiates a DoingOtherStuff class as an object named myOtherStuff. Main then runs the DoSomeWork method in myOtherStuff.
3. However, once in myOtherStuff.DoSomeWork the reference to the previously created object myInitConfigBuilder is gone. It is not available in the current context. Sure, I can instantiate *another* MyInitConfigBuilder class object, but this seems (on the surface) somewhat wasteful.
Bummer.
I'm pretty sure this is no surprise. Where I'm having trouble is trying to figure out how to orchestrate all of the above into the right combination of classes, call orders, objects and physical files.
I figured that several smaller classes would be helpful as they are smaller programming units, but I can't seem to access previously instantiated objects unless they originated in the current class. Do I need one really big "master class" ... it just doesn't feel right.
As a procedural programmer, I'm finding the object approach makes a lot of sense, except I'm having trouble getting to the objects! 
I'm sure there's a right way to reframe my thinking above. Any suggestions
I realize this is a pretty open ended question. Thanks so much,
DB
// File: MyApplication.cs
// References: MyUtilityClassLibrary
class MyApplication
{
static void Main(string[] args)
{
String myConnString;
InitConfig myInitConfigBuilder = new InitConfig();
// Get the Connection String from the initial configuration object.
// Works like a champ:
myConnString = myInitConfigBuilder.MyConnString;
// Then I run ...
DoingOtherStuff myOtherStuff = new DoingOtherStuff();
myOtherStuff.DoSomeWork();
} // Main
} // Class MyApplication
MyUtilityClassLibrary
// File: InitConfig.cs
class InitConfig
{
// When myInitConfigBuilder is instantiated in Main
// all this works like a champ:
private String myConnString;
public InitConfig()
{
myInitConfig = new AppSettingsReader();
myConnString =
(string)myInitConfig.GetValue("myConnString", typeof(string));
} // Constructor
public String MyInitConnString
{
get
{
lock (myConnString)
{
return myConnString;
} // lock
} // get
} // Property GetMyInitConnString
} // Class InitConfig
// File: DoingOtherStuff.cs
public class DoingOtherStuff
{
public void DoSomeWork()
{
String myConnString;
// In an attempt to reference the object
// myInitConfigBuilder originally instantiated
// in Main I get "The name 'myInitConfigBuilder'
// does not exist in the current context"
myConnString = myInitConfigBuilder.MyConnString;
} // Method DoSomeWork
} // Class DoingOtherStuff
I Lost My Object's Reference In The Current Context
Travis White
Otherwise pass in byref or byval the InitConfig object to the Constructor of the second class viz.
public class DoingOtherStuff
{
private InitConfig _Config;
public DoingOtherStuff(InitConfig oConfig)
{
_Config = oConfig;
}
public void DoSomeWork()
{
String myConnString;
// In an attempt to reference the object
// myInitConfigBuilder originally instantiated
// in Main I get "The name 'myInitConfigBuilder'
// does not exist in the current context"
myConnString = _Config.MyConnString;
} // Method DoSomeWork}
Shaun Miller MS
The approach I take for this problem is to use a static class. Declare the properties and methods in your class as static, then you can access them from anywhere without having to instantiate an InitConfig object.
This is a case of the singleton design pattern: you can find an example of this here: http://www.dofactory.com/Patterns/PatternSingleton.aspx#csharp.
Stuart Campbell
The main landmine with static members is that they are not thread safe. So if you have multiple threads accessing a static member at the same time then you need to use some kind of synchronisation strategy. Multiple reads are generally OK, but multiple writes, or multiple reads with single writes, all need to be synchronised. The simplest way to do this is using the C# lock statement.
This problem does not occur when you instantiate the InitConfig object in each thread, as each thread has its own copy of the object.
Cristian Lefter
Hi ShellShock ... thank you again for answering one of my questions!
I did do a lot of research on using a static class, and I was thinking this might be a solution. I read up on the singleton stuff in another reference ... and I think this started me down a rat hole, into thinking that you still had to instantiate the class object. I guess the whole point w/ a static object is *not* to instantiate an object, but just to use the functionality in the class itself. Something like:
Console.WriteLine ("Welcome To The Rat Hole");
So, for my "all purpose utility" requirements, it sounds like setting up a static class for this is a good solution. Most of what I need to access will be reference information. Are there any landmines waiting for me that I should know about
Laird ... thank you too for taking the time to answer my question!
This just goes to show how much of a dolt I am at this object stuff. The idea never occurred to me that I could create an object and actually pass it around byref or byval as a parameter to another object. Doah!
I guess it could be just like any other "variable". I suppose this includes a collection of objects could be moved around as well if necessary. This whole concept opens a number of doors.
Is this a typical approach It seems to simple and obvious....
Thank you again for taking the time to assist me.
DB
natetrost
Hi again!
I was thinking about trying the instantiate one initConfig object in Main and then pass it around as an object parameter to other classes as above. I tested this and it seemed to work pretty well.
1. Do I have to make sure this object is thread safe, assuming the other objects are only going to read from it I was going to use the lock statement on various property gets.
2. Would I be better off just having each thread/object instantiate its own initConfig The idea is that this is all read only data ... would that be a better OOP approach than setting up a Singleton
Thank you again!
DB
AndyTomlin106
It looks as though you have had alot of helpful replies. I would just like to offer a suggestion: a static member (method or property) can only call other static members. Keeping this in mind, it is usually best to use static methods and properties only for those objects for which it is absolutely necessary.
There are other methods of protecting the integrity of methods and values, including the proper use of inheritance, the private and protected keywords, and the use of abstract classes.
One last thing - in OOP, it is often suggested to put as little as possible in the main method. A better idea is to create separate classes to provide the functionality, and call them from the constructor of the class in which the main method is located. That way, you are not constrained to create the necessary methods as static ones.
I hope this is helpful - I'm still learing too, so hang in there!