return a class in C#

Generally what you are doing is a bad idea and is not object orientated.

To further iterate what Abhinav S has said:

There are three ways you use objects.
1) You don't care what the object type is (return object).
2) You care what the type is to a degree (return a base class).
3) You care about the details of the object (return a specific type).

For example, say you are a handler in a zoo, and your boss says
1) Go and see what we have in cage 19, so you go there and take a picture of the plaque there and give it to your boss. (you return an object and your boss know what to do with it)
2) See if the animal in cage 19 is alive, You call a Animal.isAlive() and check the return is not null.
3) Go and feed the animal in cage 19, so you must know what the animal type is and feed it bananas if it is a monkey, meat if it is a lion etc.

Above answers covers your Question comprehensively. This type of requirements provides an opportunity to Programmer to improve their Object Oriented skills.

Please consider below "Design Principle" whenever you come across "Object Oriented Programming".

"Program to an interface, not an implementation."
- From the wonderful Book - "Head First Design Patterns" - By wonderful writers Eric Freeman and Elisabeth Freeman.

Lets define an Interface IWay.

public interface IWay
{
  string getData();

}

Now define a Class - Road, which inherits the Interface - IWay.

public class ROAD: IWay
{
  public string getData()
  {
    return "Marlton Road";
  }
}

Lets define a Class- PATH, which too inherits the Interface - IWay.

public class PATH:IWay
{
  public string getData()
  {
    return "Tagore Path";
  }
}

It's time to declare and define FETCH Method. It will look like below.

public IWay FETCH(bool flag)
{
  IWay objectToReturn = null;
  if (flag)
  {
    objectToReturn = new ROAD();
  }
  else
  {
    objectToReturn = new PATH();
  }

  return objectToReturn;
}

if you observe return Type of Fetch method is Type of Interface IWay. And method Fetch will instantiate object of Interface IWay by either of your Class based on your condition.

One more Design Principle from "Head First Design Patterns" Book is as below.

"No matter where you work, what you're building, or what language you are programming in, what's the one true constant that will be with you always?"

Answer is - CHANGE

Lets assume in future you get one more Entity called as "STREET".

In that case all you have to do is as below.

public class STREET : IWay
{
  public string getData()
  {
    return "Canal Street";
  }
}

Hope this information helps you. :). Thank you for posting such a good Question.

Updated - Reeason to mention name of Book - "Head First Design Patterns" here is to give a sincere credit to wonderful writers Eric Freeman and Elisabeth Freeman for their wonderful "Design Principles".

Even though I think this question has been thoroughly answered here, I am going to add my code example to the thread, just in case it might be useful, or even just 'entertaining' as an odd 'curiousity' :) ... and also because it demonstrates using another basis for a class factory than 'Interface.

I also will ask a question on the C# forum regarding the implications of the use of this 'factory class' technique compared to using Interface ... which I'm curious about.

Here's my 'abstract class' based factory:

using System;

namespace Paths
{
    public abstract class PathsBase
    {
        // using an enum for future extensibility
        public enum PathTypeID { RoadPathID = 1, TrailPathID = 2 };

        // looking to the future where instances will not
        // have "hard coded" data
        abstract public string PathData { get; set; }

        // note use of non-abstract static 'factory' method 
        public static PathsBase MakeNewPath(PathTypeID typeOfPath, string privateData)
        {
            // using switch with, again, idea of
            // future extensibility
            switch(typeOfPath)
            {
                case PathTypeID.RoadPathID:
                    return new RoadPath(privateData);
                case PathTypeID.TrailPathID:
                    return new TrailPath(privateData);
                default:
                    return null;
            }
        }
    }

    public class RoadPath: PathsBase
    {
        // ctor
        public RoadPath(string privateData) { PathData = privateData; }
        public override string PathData { get; set; }
    }

    public class TrailPath : PathsBase
    {
        // ctor
        public TrailPath(string privateData) { PathData = privateData; }
        public override string PathData { get; set; }
    }
}

So, let's see how this code is used (here invoked from a button Click event handler on a WinForm):

private void button1_Click(object sender, EventArgs e)
{
    PathsBase newRoad = PathsBase.MakeNewPath(PathsBase.PathTypeID.RoadPathID, "Marlton Court");
    PathsBase newTrail = PathsBase.MakeNewPath(PathsBase.PathTypeID.TrailPathID, "Tagore Path");
}

If you compile and test this code, I suggest you set a breakpoint in the Button click handler, and verify, to your own satisfaction, that the objects the factory returns are, indeed, of the 'right type.'

The whole idea is a typical abuse of OOP. You try to introduce the flag which pretend to play a role of something discriminating classes and replacing already existing and robust OOP dispatching mechanism.

We can discuss what to do instead only if you explain the goal of all this activity. Actually, I would advise that you always explain this goal; it can avoid using wrong ideas any of use can be preoccupied with.

—SA

SAKryukov is right. Your way of writing function is violation of OOPS philosophy. But if you still want to do this, Interface is the way.