Class Instantiation when to use/or not

[mprice214]

Hi all, I've been trying to become more familiar with classes and instantiating them and the different times one would need to do so. I came across the following tutorial (http://www.csharp-station.com/Tutorials/Lesson05.aspx[^] and it has the code below. Albeit, this code doesn't do anything useful, but again, just raises a question. The question I have is what would drive instantiating the class versus declaring getChoice() as static? As I'm a ME, please use plain english. :-D

using System;

class Address
{
public string name;
public string address;
}

class MethodParams
{
public static void Main()
{
string myChoice;

    MethodParams mp = new MethodParams();

    do
   {
        // show menu and get input from user
        myChoice = mp.getChoice();

        // Make a decision based on the user's choice
        mp.makeDecision(myChoice);

        // Pause to allow the user to see the results
        Console.Write("press Enter key to continue...");
        Console.ReadLine();
        Console.WriteLine();
    } while (myChoice != "Q" && myChoice != "q"); // Keep going until the user wants to quit
}

// show menu and get user's choice
string getChoice()
{
    string myChoice;

    // Print A Menu
    Console.WriteLine("My Address Book\\n");

    Console.WriteLine("A - Add New Address");
    Console.WriteLine("D - Delete Address");
    Console.WriteLine("M - Modify Address");
    Console.WriteLine("V - View Addresses");
    Console.WriteLine("Q - Quit\\n");

    Console.WriteLine("Choice (A,D,M,V,or Q): ");

    // Retrieve the user's choice
    myChoice = Console.ReadLine();

    return myChoice; 
}

// make decision
void makeDecision(string myChoice)
{
    Address addr = new Address();

    switch(myChoice)
    {
        case "A":
        case "a":
            addr.name = "Joe";
            addr.address = "C# Station";
            this.addAddress(ref addr);
            break;
        case "D":
        case "d":
            addr.name = "Robert";
            this.deleteAddress(addr.name);
            break;
        case "M":
        case "m":

[Lost User]

In the case above there is almost no difference; the tutorial is trying to illustrate a point that we can separate the logic from static code into methods of a class. This is the basis of inheritance whereby we can build on a simple or base class and keep adding functionality to create quite sophisticated objects. If you really have trouble understanding this I would suggest doing some study on OOP and C# classes. [edit]Sorry, I meant C# not C++.[/edit]

It's time for a new signature.

[mprice214]

Richard MacCutchan wrote:

In the case above there is almost no difference; the tutorial is trying to illustrate a point that we can separate the logic from static code into methods of a class.

Yes, I understand that. I was hoping to get a general explanation of when one would want to declare the method as static versus instantiating the class. I would imagine that this has or could be the subject of a dissertation, but was looking for a brief answer as to what would be a reason for not declaring the method as static.

[Luc Pattyn]

When a class represents a real-life object (e.g. a car), or something more abstract but not unique by its very nature (a binary tree), or something with some internal state, then it should be modeled by a non-static class. It is only when there is going to be only one of them ever needed and it has no state, that you should consider a static class, and hence zero rather than one instances. A collection of global constants could be an example; a collection of simple methods could be too (see e.g. the trig functions in the Math class). static classes are often abused; when in doubt, the class should not be static. :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

---

Prolific encyclopedia fixture proof-reader browser patron addict?
We all depend on the beast below.

---

[Lost User]

mprice214 wrote:

I was hoping to get a general explanation

That is what the tutorial is for. As I said in my previous answer if you have difficulty understanding this then you should study some more tutorials and books on the subject.

It's time for a new signature.

[mprice214]

Thank you.

[Luc Pattyn]

you're welcome. :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

---

Prolific encyclopedia fixture proof-reader browser patron addict?
We all depend on the beast below.

---