There is nothing particularly wrong with your solution.

But my personal preference would be that those methods are not that useful. And just complicate the interface of whatever object they are part off.

The void moveCameraTo(double latitude, double longitude) doesn't really simplify the code, as I see no problem simply calling moveCameraTo(new LatLng(latitude, longitude)); in it's place. This method also smells of primitive obsession.

The void moveCameraTo(Location location) could be better solved by proving Location.ToLatLng() method and calling moveCameraTo(location.ToLatLng()).

If such a methods were truly necessary, I would prefer them as extension methods instead of instance methods. Usage of extension methods would become really obvious if you tried abstract away and unit-test this instance. As it would be much easier to just fake out single method instead of multiple overloads with simple conversions.

I think that with this way I eliminate the responsibility of knowing what is a LatLng in another class, for example.

I see no reason why this would be a problem. As long as your code references class that contains void moveCameraTo(LatLng latLng), it still indirectly depends on LatLng. Even if that class is never directly instantiated.

And you do not need to prepare the data before calling the function.

I don't understand what you mean. If it means creating new instance or transforming classes from one into another, I see no problem with that.

Thinking about it, I feel that what I'm saying is also supported by API design of .NET itself. Historically, lots of .NET classes followed your approach of having lots of overloads with different parameters, and simple conversions inside. But that was before extension methods existed. More modern .NET classes are more light-weight in their own APIs and if there are any methods with parameter overloads, they are provided as extension methods. Older example is NLog ILogger that has dozens of overloads for writing to log. Compare that to newer Microsoft.Extensions.Logging.ILogger that has total of 3 methods (and only 1 if you count logging itself). But there are lots of helpers and various parametrizations as extension methods.

There is nothing particularly wrong with your solution.

But my personal preference would be that those methods are not that useful. And just complicate the interface of whatever object they are part off.

The void moveCameraTo(double latitude, double longitude) doesn't really simplify the code, as I see no problem simply calling moveCameraTo(new LatLng(latitude, longitude)); in it's place. This method also smells of primitive obsession.

The void moveCameraTo(Location location) could be better solved by proving Location.ToLatLng() method and calling moveCameraTo(location.ToLatLng()).

if this was C# and if such a methods were truly necessary, I would prefer them as extension methods instead of instance methods. Usage of extension methods would become really obvious if you tried abstract away and unit-test this instance. As it would be much easier to just fake out single method instead of multiple overloads with simple conversions.

I think that with this way I eliminate the responsibility of knowing what is a LatLng in another class, for example.

I see no reason why this would be a problem. As long as your code references class that contains void moveCameraTo(LatLng latLng), it still indirectly depends on LatLng. Even if that class is never directly instantiated.

And you do not need to prepare the data before calling the function.

I don't understand what you mean. If it means creating new instance or transforming classes from one into another, I see no problem with that.

Thinking about it, I feel that what I'm saying is also supported by API design of .NET itself. Historically, lots of .NET classes followed your approach of having lots of overloads with different parameters, and simple conversions inside. But that was before extension methods existed. More modern .NET classes are more light-weight in their own APIs and if there are any methods with parameter overloads, they are provided as extension methods. Older example is NLog ILogger that has dozens of overloads for writing to log. Compare that to newer Microsoft.Extensions.Logging.ILogger that has total of 3 methods (and only 1 if you count logging itself). But there are lots of helpers and various parametrizations as extension methods.

I think this answer shows that some languages would have tools to make design like this nicer. I don't know much Java, so I'm not sure if there would be any equivalent. But even using plain static methods might be an option.

There is nothing particularly wrong with your solution.

But my personal preference would be that those methods are not that useful. And just complicate the interface of whatever object they are part off.

The void moveCameraTo(double latitude, double longitude) doesn't really simplify the code, as I see no problem simply calling moveCameraTo(new LatLng(latitude, longitude)); in it's place. This method also smells of primitive obsession.

The void moveCameraTo(Location location) could be better solved by proving Location.ToLatLng() method and calling moveCameraTo(location.ToLatLng()).

If such a methods were truly necessary, I would prefer them as extension methods instead of instance methods. Usage of extension methods would become really obvious if you tried abstract away and unit-test this instance. As it would be much easier to just fake out single method instead of multiple overloads with simple conversions.

I think that with this way I eliminate the responsibility of knowing what is a LatLng in another class, for example.

I see no reason why this would be a problem. As long as your code references class that contains void moveCameraTo(LatLng latLng), it still indirectly depends on LatLng. Even if that class is never directly instantiated.

And you do not need to prepare the data before calling the function.

I don't understand what you mean. If it means creating new instance or transforming classes from one into another, I see no problem with that.

There is nothing particularly wrong with your solution.

But my personal preference would be that those methods are not that useful. And just complicate the interface of whatever object they are part off.

The void moveCameraTo(double latitude, double longitude) doesn't really simplify the code, as I see no problem simply calling moveCameraTo(new LatLng(latitude, longitude)); in it's place. This method also smells of primitive obsession.

The void moveCameraTo(Location location) could be better solved by proving Location.ToLatLng() method and calling moveCameraTo(location.ToLatLng()).

If such a methods were truly necessary, I would prefer them as extension methods instead of instance methods. Usage of extension methods would become really obvious if you tried abstract away and unit-test this instance. As it would be much easier to just fake out single method instead of multiple overloads with simple conversions.

I think that with this way I eliminate the responsibility of knowing what is a LatLng in another class, for example.

I see no reason why this would be a problem. As long as your code references class that contains void moveCameraTo(LatLng latLng), it still indirectly depends on LatLng. Even if that class is never directly instantiated.

And you do not need to prepare the data before calling the function.

I don't understand what you mean. If it means creating new instance or transforming classes from one into another, I see no problem with that.

Thinking about it, I feel that what I'm saying is also supported by API design of .NET itself. Historically, lots of .NET classes followed your approach of having lots of overloads with different parameters, and simple conversions inside. But that was before extension methods existed. More modern .NET classes are more light-weight in their own APIs and if there are any methods with parameter overloads, they are provided as extension methods. Older example is NLog ILogger that has dozens of overloads for writing to log. Compare that to newer Microsoft.Extensions.Logging.ILogger that has total of 3 methods (and only 1 if you count logging itself). But there are lots of helpers and various parametrizations as extension methods.