详细解策略模式追MM,附:追MM有危険,请慎重.
STRATEGY-異なるタイプのMMとデートして、異なる策略を使って、あるものは映画を招待して比較的に良くて、あるものは軽食の効果が悪くて、あるものは海辺に行ってロマンチックで最も適当で、しかし目的はすべてMMの芳心を得るためで、私のMMの錦の袋の中で多くのStrategyがあります.≪ポリシー・モード|Policy Mode|emdw≫:ポリシー・モードは、アルゴリズムのセットに対して、共通のインタフェースを持つ独立したクラスに各アルゴリズムをカプセル化し、互いに置き換えることができます.ポリシー・モードにより、アルゴリズムはクライアントに影響を及ぼさずに変化することができる.ポリシー・モードは、動作と環境を分離します.環境クラスは、特定のポリシークラスで提供される様々なアルゴリズムを維持およびクエリーする動作クラスを担当します.アルゴリズムと環境が独立しているため、アルゴリズムの増減、修正は環境とクライアントに影響しません.以上が転載です.これを見るとやはり、デザインパターンの理解を高めるのに役立ちます.しかし、大まかな話をしています.詳しく説明したいのですが.MMとデートするイベントは、最初は一定の计画が必要です.计画とは一定の目标が必要です.まず、活动の大体の枠组みを明确にして、映画を见ますか?買い物?スキー?よく考えてから私はMMを追う基本的な類を書きます.コードは以下のように設計されています.
ハハ.基本的な计画はあって、具体的にMMAを追うならばと思って、私达は1つの类を书いてそれと継承することができます.
でも問題が発生しました...私のような正直な人にとって、1つで十分で、多くのMMを追いかけたい人にとって、それはとても苦労しました..すべてのMMが映画を見るのが好きではなく、スキーをするのが好きではありません.CheasingGirlsクラスを継承すると現れます親メソッドを上書きする場合MMBを追う
もし私が数十人を追いかけたら.それは全部書き直さなければならない.疲れちゃうよ..だから私は、movieとshoppingの方法をインタフェースで作ることに変えました.
私がMMを追う計画類を変えます
このような設計がもたらしたメリットを見て、私はいくつかの異なる映画を見てショッピング計画を書くことができて、コードに影響しません.再利用できるなんて、便利ですね.....後で組み合わせておけばいいです.またMMを追うために心配しますか?コードは次のとおりです.
もし私たちがMMAに浸かる前に、計画を定義したら、コードは以下の通りです.
しかし、このようにするのは欠点があって、いったんMMが好きでないならば、臨時に計画を変えることができません......MMは難しいですね...デート中に計画を変える方法を考えなければなりません私たちはデートの時に変わりました.私がMMを追う計画類を変えます
MMを追う过程の中で私はこのように书くことができます^^.映画を見る計画は成功した....みんながすべてあなたの心の中のMMになることができることを望みます.
public class CheasingGirls{
public void movie(){
// , MM , .
}
public void shopping(){
// , MM .
}
}
ハハ.基本的な计画はあって、具体的にMMAを追うならばと思って、私达は1つの类を书いてそれと継承することができます.
public class CheasingGirlsA extends CheasingGirls{
// ( )
public void movie(){
// , MM , .
}
// ( )
public void shopping(){
// , MM .
}
}
でも問題が発生しました...私のような正直な人にとって、1つで十分で、多くのMMを追いかけたい人にとって、それはとても苦労しました..すべてのMMが映画を見るのが好きではなく、スキーをするのが好きではありません.CheasingGirlsクラスを継承すると現れます親メソッドを上書きする場合MMBを追う
public class CheasingGirlsB extends CheasingGirls{
// ( )
public void movie(){
//
}
// ( )
public void shopping(){
//
}
}
もし私が数十人を追いかけたら.それは全部書き直さなければならない.疲れちゃうよ..だから私は、movieとshoppingの方法をインタフェースで作ることに変えました.
public interface Movie{
public void doMovie();
}
public interface Shopping{
public void doShopping();
}
私がMMを追う計画類を変えます
public class CheasingGirls{
Movie movie;
Shopping shopping;
public void movie(){
movie.doMovie();
}
public void shopping(){
shopping.doShopping();
}
}
このような設計がもたらしたメリットを見て、私はいくつかの異なる映画を見てショッピング計画を書くことができて、コードに影響しません.再利用できるなんて、便利ですね.....後で組み合わせておけばいいです.またMMを追うために心配しますか?コードは次のとおりです.
// 1
public class movie1 implements Movie{
public void doMovie(){
// .
}
}
もし私たちがMMAに浸かる前に、計画を定義したら、コードは以下の通りです.
public class CheasingGirlsA extends CheasingGirls{
public CheasingGirlsA(){
movie = new movie1();
}
}
しかし、このようにするのは欠点があって、いったんMMが好きでないならば、臨時に計画を変えることができません......MMは難しいですね...デート中に計画を変える方法を考えなければなりません私たちはデートの時に変わりました.私がMMを追う計画類を変えます
public class CheasingGirls{
Movie movie;
Shopping shopping;
public void movie(){
movie.doMovie();
}
public void shopping(){
shopping.doShopping();
}
public void setMovie(Movie movie){
this.movie = movie;
}
}
MMを追う过程の中で私はこのように书くことができます^^.映画を見る計画は成功した....みんながすべてあなたの心の中のMMになることができることを望みます.
CheasingGirls cheasingGirls = new CheasingGirls();
// movie1
cheasingGirls .setMovie(new movie1());
cheasingGirls .doMovie();