.NET (Core and Framework)

public class Data
{
    private List<int> a;

    public Data()
    {
      a = new List<int>();
    }

    public Data(int[] nums)
    {
       a = new List<int>();
       // add to a
    }

    public static Data Parse(string nums)
    {
       // say nums = "1,2,3
       string[] _nums = nums.Split(",".ToCharArray());
       List<int> iList = new List<int>();
       foreach(string s in nums)
          iList.Add(int32.Parse(s));
       return new Data(iList.ToArray());
    }
}

public BitmapImage TheImage
{
  get
  {
    return LoadImageFromSource();
  }
}

private BitmapImage LoadImageFromSource()
{
  BitmapImage image = new BitmapImage();

  try
  {
    image.BeginInit();
    image.CacheOption = BitmapCacheOption.OnLoad;
    image.CreateOptions = BitmapCreateOptions.IgnoreImageCache;
    image.UriSource = new Uri( FullPath, UriKind.Absolute );
    image.EndInit();
  }
  catch{
    return DependencyProperty.UnsetValue;
  }
  return image;
}

Naerling wrote:

I don't really think my six months of experience have anything to do with it

Naerling wrote:

So I'm just asking what are you wrapping and why

Naerling wrote:

Or people that wrap some exotic .NET functionality in a new easy to use class.

Naerling wrote:

I can't help to think that some classes/components were made to have an extra shell around them.

Naerling wrote:

It seems to me that constantly creating all those objects, configuring them etc. seems like a lot of work. So it would seem to me that it is easier to create a class that requires some parameters in its constructor, has some methods and functions that manage all the just mentioned classes and simply gives a resultset using something like DBClass.Execute.

Naerling wrote:

At this point, is anyone really disagreeing with me?
Or do you really agree and know some other stuff that just calls to be put away in a programmer friendly class? Smile

I are Troll

Naerling wrote:

And the question remains if it is even a con that you lose functionality if you weren't using the functionality in the first place.

Naerling wrote:

Let's say your company ONLY uses the command object to execute stored procedures (some weird company policy)

Naerling wrote:

would it really be that bad if you would build a class that does not support the CommandType.TableDirect or Text anymore?

I are Troll

Naerling wrote:

Perhaps you don't want that kind of flexibility or you prefer simple and quick access over flexibility.