Overloading best practices

Say I have a method that returns a business object:

public static MyObject GetObject()
{
   return Blah.Blah();
}

Now I need another method that does the same thing, but returns MyObject in an XML format:

public static string GetObject(bool returnXml)
{
  return Blah.Blah.Xml();
}

I started with this approach, but soon realized that caller could specify false for returnXml.

Is my only option to rename my method to something like GetObjectAsXml?

Update...thanks all.

My original methods look like this.

public static MyObject GetObject()
{
   return ConvertToMyObject(GetResponseAsXML());
}

I just need a new set of methods that look like this:

public static string GetObject()
{
   return GetResponseAsXML();
}

From the answers it seems like the best way is to have a second set of methods that are named GetObjectAsXML, right? I don't really want to do GetObject().ToXml() because I want to return the original response back.

I'm not sure why you would overload the same method here.

One is returning the object, the other is returning an XML representation/serialization of that object. I'd use two different methods.

What's more interesting is what you do with these objects and XML serializations; the consumer would probably want 2 overloads that take either type as a parameter, but that would be dependent on your needs.

public static MyType GetObject()
{
  return Blah.Blah();
}

public static string GetObjectAsXml()
{
  return Blah.Blah().Xml();
}

There are a couple ways you could do this - some of your decision will depend on your system. However, if I was designing a system where information needed to be returned differently depending on who needs the information, I would not make the object responsible for providing the correct formatting as this violates the principle of maintaining high coehsion (AKA, an aspect of the system only does one thing).

Instead, I would create a subsystem which can take in your business object and has the knowledge of how to convert it to XML, flat file, YAML, whatever you need it to be. And, if you have other business objects that derive from the same "business object base class," that subsystem will work for all those as well, creating a more reusable system.

I'm not sure if you require overloading at all in this situation. You have

public static MyObject GetObject()
{
  return Blah.Blah();
}

to get the object. Getting the XML for the object seems to be an instance function, not a static function, and you could get the XML with this call:

string xmlStuff = GetObject().Xml();

Best practice? How about a better practice, specifically the Single Responsibility Principle?

Your approach combines the duties of getting your object and serializing it. SRP dictates that these are two completely different responsibilities. Besides, who is to say you want it serialized using the XmlSerializer, the XamlSerializer, or even the NetDataContractSerializer?

I'd let the type that must have serialized object do the serializing. I'd designate a type as my serializer, have it injected as part of some Dependency Injection framework, and use that everywhere to do my serializing. Or, if the type needing the object to be serialized was in charge of both serializing and deserializing, I'd let it take care of the responsibility of choosing the serializer itself.