Factory Design and Static Methods 1

[CrashDome]

So I've been writing a new piece of software for my company and I am diving into the use of generics for the first time (Just got VS2005 not too long ago).

So I've been building my classes based on code I've found throughout the net and found some very good articles to base my work/learning off of.

However, everyone has simplified their code to get their point across and I have been left with working my design into their code structure. I am wondering if I did this right.. or atleast "smart".

I have a few derived classes from a main DataObject class which is ultimately the object part of my data-object seperation.

class MyObject : MasterDataObject, ISomething, INotifyblahblah
{
   //constructor
   private MyObject()
   {
   }

   protected StrongDataRow dataRow;

   //Primary key of data in database
   private int objectID;
   public int ObjectID
   {
      get {} private set {}
   }

   private int someFieldData;
   public int SomeFieldData
   {
      get {} set {}
   }

   //All methods below are from an Interface or derived class
   private override void PopulateData()
   {
      //use this.dataRow to fill appropriate fields
   }

   public override bool Update()
   {
      //assign changed fields to this.dataRow and then..
      MyObject.dataAdapter.Update(this.dataRow);
   }
   public override void Revert() {...}


   //Static Methods (from an Interface)
   protected static StrongDataAdapter dataAdapter;
   protected static StrongDataTable dataTable;

   public static GetAllInstances()
   {
      //use static adapter and table to get data
      //and tag datarow to objects for later updating
      //if needed i.e.:
      MyObject.table = dataAdapter.GetData(); // returns strong DataTable
   }
   public static GetnstancesFromID(int ID)
   {  
      //use static adapter and table to get data
      //and tag datarow to single object for later updating
      //if needed
   }   

   public static CreateNewInstance()
   {
      //use static adapter and table to create new datarow
      //and tag datarow to objects for later updating
      //if needed
   }
}

The above is a rough copy of what I am doing, but is enough to ask the question:

I have no Factory class but I am using static methods like a factory design. I didn't realize this until I got about half-way through and decided I would continue to see what I came up with. Now that I am finished, I can see no problems but I really want a more expert opinion on this design.

Should I seperate my factory methods and forget about static methods? Another thing is the use of a static datatable field... Is it going to be overwritten by another call to a Create() method and thus all my previous objects dataRow will be lost?

Is this somehow ingeniously unique? or am I just barking up the wrong tree completely?

 

[CrashDome]

An interesting thing (to me) about the static dataAdapter and dataTable... it will change everytime I generate an instance, but it doesn't affect the reference for the dataRow object in the instance itself.

For example:
I created one instance of all data in my database and I get a dataTable with four rows and four instances of MyObject each with the appropriate dataRow.

I then create one instance from an ID and get a new table with one row and one dataRow for this instance of MyObject.

If I peek into one of the previous four MyObjects, the dataRow object still references the table with the four dataRows even though the static object "MyObject.dataTable" now references the table with the single dataRow from my second creation.

I suppose this is OK if I never use "MyObject.dataTable" to do updates or manipulate the data directly and use it only as a temporary storage (so-to-speak).


All of this most of you already could have told me, but it's all pretty new to me so I still ask the question:

Should I even be doing this???

 

[JurkMonkey]

Wha?

The idea of the Factory is to return an instance of the correct class.

so you would say

public static BaseClassType GetInstance(someparameters)
{
switch(someparameters)
{
case something:
{
return new SomeClass1();
}
default:
{
return new SomeClass2();
}
}
}

 

[CrashDome]

Yes, I should have said it this way:

I went into it with the idea of using a factory design pattern and as a result of the code I used off the Internet (to generate a generic collection class) I ended up with the above instead (static GetInstance() methods).

I am torn between leaving it as is or stripping out the static methods and creating another class like you mentioned above to generate ALL my MasterDataObject subclasses.

 

[chrissie1]

I see no reason why you would want to those methods static. I would make myobject a singleton and then caal the instance via getinstance . I see you already did this by making the constructor private but I see no getinstance for the class. if you make it a singleton then the methods don't need to be static. And you will be sure that you always refernce the same instance.

BTW I think sun/java have a nice DAO model they like to present and with a few tweaks you can make it a nice .net datalayer.

http://java.sun.com/blueprints/patterns/DAO.html

and

http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

Christiaan Baes
Belgium

"My new site" - Me

 

[CrashDome]

Hmmm... I appreciate the comments but I am a little unclear on your recommendation.

I can't make MyObject a singleton because I need multiple instances (and there are GetInstance methods in there... they are the static ones at the bottom - just named differently depending - i.e. GetAllInstances(), GetInstanceFromID(), etc..).

Also, my DataLayer I believe to be is fine. I will look at that link most certainly, but my trouble is really about keeping the instance methods static in the subclass or creating a factory object as JurkMonkey pointed to.

I did learn quite a bit so far... basically that my code is confusing to everyone and that is a #1 sign of "don't go that way".

So unless I hear otherwise I am going to completely rework this in a seperate file and, if it looks better, trash this one.

Thank you.

 

[phinoppix]

IMHO, nothing wrong with using an instantiable class as a factory class. About the static field, creating the class will not overwrite the field's value, unless you explicitly do so on the constructor. Statics will be static. .NET only wants to keep its semantics consistent so it required us to put static fields/methods in a class.

It all now falls to which class do I put these static fields/methods (conventions(?)). MSDN has tips on this, but I haven't got the time to browse. sorry

A good example you might want to look at is System.String.

I hope this helps.

 

[CrashDome]

Yes, it does! Thank you