関数を呼び出すこの方法は悪い習慣ですか？

私は次のコードを持っています：

public void moveCameraTo(Location location){
    moveCameraTo(location.getLatitude(), location.getLongitude());
}

public void moveCameraTo(double latitude, double longitude){
    LatLng latLng = new LatLng(latitude, longitude);
    moveCameraTo(latLng);
}

public void moveCameraTo(LatLng latLng){
    GoogleMap googleMap =  getGoogleMap();
    cameraUpdate = CameraUpdateFactory.newLatLngZoom(latLng, INITIAL_MAP_ZOOM_LEVEL);
    googleMap.moveCamera(cameraUpdate);
}

このようにすると、LatLngたとえば、別のクラスの内容を知る責任がなくなると思います。

また、関数を呼び出す前にデータを準備する必要はありません。

どう思いますか？

このアプローチには名前がありますか？それは本当に悪い習慣ですか？

言語のメソッドオーバーロード機能を使用して、位置情報に対するメソッドの依存関係を解決する別の方法を呼び出し元に提供しています。次に、カメラを更新する残りの作業を解決するために別の方法に委任します。

ここでのコードのにおいは、メソッドを呼び出すメソッドのチェーンを単に拡張し続ける場合です。Location取得メソッドは、latLng取得メソッドを呼び出すdouble取得メソッドを呼び出し、最終的にカメラの更新方法を知っているものを呼び出します。

長いチェーンは、最も弱いリンクと同じくらい強いだけです。チェーンの各拡張により、機能する必要のあるコードのフットプリントが増加します。

各方法が、提示された問題を解決するための最短の経路をとる場合は、はるかに優れた設計です。それは、それぞれがカメラを更新する方法を知っている必要があるという意味ではありません。それぞれが、位置パラメータタイプを1つの均一なタイプに変換する必要があります。これは、この1つのタイプが提示されたときにカメラを更新する方法を知っている何かに渡すことができます。

そうすれば、他のすべての半分を壊すことなく1つを削除できます。

検討してください：

public void moveCameraTo(Location location){
    moveCameraTo( new LatLng(location) );
}

これにより、緯度と経度LatLngの問題に対処できます。コストはLatLng周りの知識を広めることです。これは高価に思えるかもしれませんが、私の経験では、原始的な強迫観念に代わる好ましい方法です。これは、パラメーターオブジェクトの確立を回避することで、行き詰まってしまうからです。

Locationがリファクタリング可能であるが、そうLatLngでない場合は、ファクトリをに追加してこれを解決することを検討してLocationください。

moveCameraTo( location.ToLatLng() );

これはまた、原始的な執着をうまく回避します。

ソリューションには特に問題はありません。

しかし、私の個人的な好みは、それらの方法はそれほど有用ではないということでしょう。そして、それらが離れているオブジェクトのインターフェースを複雑にします。

void moveCameraTo(double latitude, double longitude)私は何の問題は、単に呼び出すなかっ見るように実際に、コードを簡素化していないmoveCameraTo(new LatLng(latitude, longitude));ことの場所に。この方法も原始的な執着のにおいがします。

は、メソッドをvoid moveCameraTo(Location location)証明してLocation.ToLatLng()を呼び出すことでより適切に解決できますmoveCameraTo(location.ToLatLng())。

これがC＃であり、そのようなメソッドが本当に必要な場合は、インスタンスメソッドではなく拡張メソッドとしてそれらを使用します。このメソッドを抽象化して単体テストを行うと、拡張メソッドの使用法が明らかになります。単純な変換で複数のオーバーロードを作成するのではなく、1つのメソッドを偽造する方がはるかに簡単だからです。

このようにすると、たとえば、別のクラスのLatLngを知る責任がなくなると思います。

これが問題になる理由はわかりません。コードがを含むクラスを参照している限り、void moveCameraTo(LatLng latLng)間接的にに依存していLatLngます。そのクラスが直接インスタンス化されることはありません。

また、関数を呼び出す前にデータを準備する必要はありません。

どういう意味かわかりません。新しいインスタンスを作成したり、クラスを別のクラスに変換したりすることを意味する場合は、問題ありません。

考えてみれば、.NET自体のAPI設計にも支えられていると感じています。歴史的に、多くの.NETクラスは、さまざまなパラメーターを持つ多数のオーバーロードを持ち、内部で単純な変換を行うというアプローチに従っていました。しかし、それは拡張メソッドが存在する前でした。最新の.NETクラスは、独自のAPIでより軽量であり、パラメーターオーバーロードを持つメソッドがある場合、それらは拡張メソッドとして提供されます。古い例はNLog ILoggerで、ログに書き込むための数十のオーバーロードがあります。これを、合計で3つのメソッド（ロギング自体をカウントする場合は1つのみ）を持つ新しいMicrosoft.Extensions.Logging.ILoggerと比較してください。しかし、拡張メソッドとして多くのヘルパーとさまざまなパラメータ化があります。

この答えは、いくつかの言語がこのようなデザインをより良くするためのツールを持っていることを示していると思います。私はJavaをあまり知らないので、同等のものがあるかどうかはわかりません。ただし、単純な静的メソッドを使用することもできます。

これの適切な名前がある場合、それが何であるかはわかりませんが、それは良い習慣です。複数のオーバーロードを公開し、呼び出しクラスが使用するパラメーターセットを決定できるようにします。あなたが言うように、別のクラスはLatLngオブジェクトが何であるかを知らないかもしれませんが、そのオブジェクトを知っているかもしれませんLocation。

これらのメソッド間でコードを複製したくないので、一方のメソッドが他方を呼び出すことも重要です。完了したら、1つのメソッドを選択して作業を実行し、他のメソッドにそれを（直接または間接的に）呼び出します。

ある種のメソッドを使用することを気にしているのであれば、それは単なるメソッドオーバーロード機能であり、優れています。

しかし、LatLngが何であるかを知る責任がなくなるわけではありません。初期化中LatLng latLng = new LatLng(latitude, longitude)です。これは完全にへの依存LatLngです。（初期化が依存関係の問題である理由を理解するには、依存関係の注入を確認できます）オーバーロードされたメソッドの作成は、気にしないクライアントに役立ちますLatLng。もしそうなら、それもいいのですが、アプローチだとは思いません。それはクライアントのための多くのサービス方法です。

したがって、アーキテクチャを設計するには2つのオプションがあります。

1. 多くのオーバーロードメソッドを作成し、クライアントに提供します。
2. インターフェイスまたは具象クラスとしてパラメータを必要とするオーバーロードメソッドをいくつか作成します。

パラメータとしてプリミティブ型を必要とするメソッドを作成することからできるだけ逃げます（オプション1）。ビジネスが何度も変更され、メソッドパラメータを再生する必要がある場合、すべての呼び出し元関数を変更して実装することは本当に難しいためです。

これの代わりに、interfaces（Dependency Injection）を使用します。コストがかかり、時間がかかると思われる場合は、クラスを使用して、それらのマッパー拡張メソッドを提供します（オプション2）。