[RESOLVED] Whats the difference between,.....

Lets say I have a Class as;
1)

Code:

---

Class MyClass
{

//Constructor

Public MyClass()
{
}


}

---

Lets Just say I modify this class to be;
2)

Code:

---

Class MyClass
{

Private MyClass()
{
}

Public Static MyClass Create()
{
MyClass myInstn = new MyClass();
return myInstn
}
}

---

***************************
If I were to instantiate MyClass using 1)

MyClass nwObj = new MyClass();

Using option 2)

MyClass nwObj = MyClass.Create();

****************************

My Question is whats the difference between 2) and 1)?

What advanteges would I get by using option 2) ?

Why would sb prefer to use option 2) over option 1) ?

Thanks!

Pure semantics.

I use a public constructor when you're obviously creating a new item. Let's say you want a new Pen:

Code:

---

Pen p = new Ballpoint();

---

That makes sense, as you've just created a brand new object.

However, in some cases you want to create an object to represent something that already exists. In this case, I would use a static method:

Code:

---

Employee fred = Employee.FromDataRow(...);

---

That's the difference for me. You could mention something about design patterns in there as well, but I prefer to ignore them.

Thanks for your reply Penagate,

I may be repeating what you´ve just explained,...

I am finding it usefull in the following situations:

Lets say I have a class such as;

Code:

---

Class Car
{

        Public Car
        {
        }

private string color = string.empty;

        Public Car(string _color)
        {
                this.Color = _color;
        }

public string Color
{
        get
        {
                return color;
        }

        set
        {
        color = value;
        }
}

}

---

And now I have a Class called Cars.

Code:

---

Class Cars
{

        private Cars()
        {
        }

        Public static Cars CreateCarsObject()
        {
        Cars crs = new Cars();
        return crs;
        }

        List<car> myCarList = new List<car>;

        Public void Car CreateCar(string _color)
        {
        Car cr = new Car(_color);
        myCarList.Add(cr);
        }

       
        Public List<Car> returnCarList
        {
                return myCarList;
        }

}

---

So I could instantiate Car objects inside Cars.

As per;

Code:

---

        Cars.CreateCar(green);
        Cars.CreateCar(blue);

---

Adding them to the List<Car>

Then lets say that for some reason,I would like to access the List<Car> , through the returnCarList property.

Sth like,

Code:

---

List<Car> list = Cars.returnCarList;

---

To be honest I´m not quite sure whether I am over complicating things here, or if this is a common
way to work.

By the way I haven´t tried the code above, it may have a few,... dozen,...errors,...
Its just to get an idea,as I am not sure whether to use this way of coding in future similiar situations,...

You can certainly do that, but I don't make separate Car and Cars classes unless there's a very good reason for it. If there is, then what you've described makes sense.

(Your code won't work as it is, because the list of cars and the Cars.Create method aren't static.)

Yes I thought there would of been some errors, as I typed it up quickly and never tried it out,..

Well the only reason to seperate Car and Cars,would be that Cars would contain a collection of car objects.

Other examples I could think of, just say I have a class called Shapes, and other classes such as triangle,rectangle...
Shapes would include a list of objects of (triangle,rectangle)

Its just to use this methology whenever there are objects contained in other objects,...

Like I say, you can do it, but it almost never occurs. Usually if you want a collection you can just declare a List<Shape> or something inline with your code rather than make a specific class for it.

Thanks for the replies

I wouldn't say that the need for a custom collection class almost never occurs. Any business object that you want to bind a list of to a control is a perfect candidate for custom collection class. In .NET 2.0 you inherit the Collection(Of T) class, where T is the type the collection contain, and that provides all the same functionality as the List(Of T) without adding any extra code. That's preferable to using a List(Of T) when exposing a collection as a property in my opinion. For instance, rather than this:

vb Code:

Public Class Person
 
    '...
 
End Class
 
Public Class Group
 
    Private _people As New List(Of Person)
 
    Public ReadOnly Property People() As List(Of Person)
        Get
            Return Me._people
        End Get
    End Property
 
    '...
 
End Class

I would do this:

vb Code:

Public Class Person
 
    '...
 
End Class
 
Public Class PersonCollection
    Inherits System.Collections.ObjectModel.Collection(Of Person)
 
    '...
 
End Class
 
Public Class Group
 
    Private _people As New PersonCollection
 
    Public ReadOnly Property People() As PersonCollection
        Get
            Return Me._people
        End Get
    End Property
 
    '...
 
End Class

You now have the added advantage that you can change your implementation of PersonCollection without having to change the code where it's currently used. Overriding some of the protected methods of the Collection(Of T) class is a very good way to provide custom behaviour in a collection class, like having the collection handle an event of every item and raise an event of its own in response. That allows user code to handle an event of the collection and thus be notified when the corresponding event of any item is raised. Good stuff.