I started to write my response before there were other solutions posted here, but I see that what I did is different from the other responses: I maintain your nested Classes, and do not use an Abstract Class.
Hopefully, in the range of implementations here, you'll find useful ideas to adapt to your own work.
Consider this:
using System;
namespace WeatherLink
{
public class DataDownLoader
{
public DataDownLoader()
{
}
private string ClassName;
public void WriteToConsole()
{
if (this is MetOffice)
{
Console.WriteLine("This is a MetOffice instance");
}
else if (this is EuMetSat)
{
Console.WriteLine("This is a EuMetSat instance");
}
else
{
throw new ArgumentException("Error in argument to WriteToConsole");
}
}
public class MetOffice : DataDownLoader
{
public MetOffice()
{
ClassName = "MetOffice";
}
}
public class EuMetSat : DataDownLoader
{
public EuMetSat()
{
ClassName = "EuMetSat";
}
}
}
}
In this case, the outer Class is simply serving as a
binder for the inner Classes, providing common functionality.
Here you would create new instances of the inner Classes, each of which inherits from the outer Class, like this:
WeatherLink.DataDownLoader newMetOffice = new WeatherLink.DataDownLoader.MetOffice();
WeatherLink.DataDownLoader newEuMetSat = new WeatherLink.DataDownLoader.EuMetSat();
In OOP terms we can say that each instance of MetOffice, and EuMetSat,
is-a instance of 'DataDownLoader.
Each instance of MetOffice, or EuMetSat, can call the public method 'WriteToConsole provided by the DataDownLoader Class: in that method the keyword 'this is used to get the Type of the current "flavor" of DataDownLoader:
newMetOffice.WriteToConsole();
newEuMetSat.WriteToConsole();
If I may suggest, I think it's very important to try and get a basic grounding in OOP concepts in .NET from the beginning, and understanding inheritance, and use of abstract and virtual Classes, and Interfaces, are very important. A good book, or two, and study, and posing design problems to yourself, will equip to handle many scenarios in the future (end of sermon).
Finally, there are many ways you could implement the functionality you have specified here (if I understood it !); I don't claim the way I presented here is the "ultimate."