-1

私は、クラスまたはインスタンスメソッドを分割し、それを独自のクラスに移動することに非常に執着しています。多くの場合、単純な「helloworld」メソッドは多くのクラスに分割されます。

たとえば、

class MainProgram
  def hello_world
    puts "hello world"
  end
end

に分割されます

class SayHello
  def initialize
    @hello = "hello"
  end

  def hello
    @hello
  end
end

class SayWorld
  def initialize
    @world = "world"
  end

  def world
    @world
  end
end

class SayHelloWorld
  def initialize
    @hello = SayHello.new.hello
    @world = SayWorld.new.world
    @hello_world = "#{@hello} #{@world}"
  end

  def hello_world
    @hello_world
  end
end

class MainProgram
  def hello_world
    @hello_world = SayHelloWorld.new.hello_world
    @hello_world
  end
end

そして時々それは不必要に感じます。このようにして、何か良いことはありますか？

コードのリファクタリングを停止するのはいつですか？リファクタリングされたコードのようなものはありますか？

4

3 に答える 3

4

「リファクタリング モード」は、コードの重複が非常に複雑な (またはビジネス ロジックを含む) ため、後でメンテナンス/更新を行うために問題を引き起こす可能性がある場合にのみ有効にする必要があります。機能が同一であることを意味するすべてのコードの場所を更新するのを忘れる可能性があるシナリオを作成するため、コードパスに応じて機能の一貫性のない動作が発生します。

一般的なルールの 1 つは、重要なコードの重複が 3 つ見つかったら、それをリファクタリングする必要があるというものです。

リファクタリングは再利用を可能にしますが、再利用可能なソフトウェア コンポーネントを作成することとまったく同じではありません (それがあなたの動機だと思います)。

あなたがしていることは、ソフトウェアを過度に設計することであり、基本的に、プログラミング言語の強力で簡潔な構文を、より単純で脆弱で表現力の低いものに減らしています。これは、あまりにも多くの抽象化レイヤーを作成し、基本的な式をクラスにカプセル化しているためです。

自問すべき有用な質問の 1 つは、「この一連の式をクラスに変換することで得られるメリットは何ですか?」ということです。たとえば、「状態を追跡する必要がありますか?」、「複数のインスタンスは意味がありますか?」、および「表現力は得られるか、失われますか? 柔軟性は? 利便性は?」などです。

別の見方をすれば、リファクタリングはDRY (Dont Repeat Yourself) によって動機付けられることが多いということです。DRY は、再利用可能なソフトウェア コンポーネントを作成することとまったく同じではないことに注意してください。ただし、YAGNI (You Aint Gonna Need It) もあります。特定の機能がすぐに必要でない限り、おそらく今すぐ実装する必要はありません。機能する最も基本的なバージョンに固執してください (少なくとも最初は）。

「すべてのオプションを後で使用できるようにしておきたい。そうすることにした場合はどうするか、そうAすることにした場合はどうするかB、はい、はい、この単純なことをクラスに変換しますf、 、 、gそしてh、後で必要だと判断した場合に備えて... !」.

したがって、これの多くは、関連するコードの記述を開始する前に、ソフトウェア要件と範囲をかなり安定した最終レベルに設定することに関連しています。道路がどこで止まるかを知ることは、必要な燃料の量を推定し、適切にペースを調整し、リソースを最も必要とする場所に比例して適用するのに役立ちます。

また、プログラミングや言語の学習に慣れていない場合は、プログラム内のすべての言語機能を必要としない場合でも、押​​し込む必要があると感じる可能性が高くなります。より複雑な現実世界のプログラム (hello world をはるかに超えたもの) を書き始めると、いつ何を使用すればよいかがわかります。

ソフトウェアのアンチパターンを認識することは、このプロセスをスピードアップする最良の方法の 1 つです。あなたは現在、「カーゴ カルト プログラミング」を行っています。

于 2012-09-18T09:44:29.170 に答える
1

それはすべて、何が不変のままで、何が変化するかにかかっています。常に同じ文字列を出力する必要がある場合"Hello World"、すべての複雑さは必要ありません。文字列を時々変更したいが、実行するたびに変更したくない場合は、文字列を定数として保持し、その定数を参照することをお勧めします。、、 などの形式"Hello world"でユーザー入力に応じて出力を変化させたい場合は、パーツを配線して、変化するパーツのユーザー入力用のルーチンを用意できます。等"Hello Mars""Hello Moon""Hello"

于 2012-09-18T10:07:03.020 に答える
1

直感的に、誰もが「Hello world」プログラムの書き方を知っています。

puts "Hello world!"

では、なぜ OOP を気にする必要があるのでしょうか。答えは、将来のためです。通常の場合のように、今すぐこんにちは世界と言いたいだけで、プログラミングのキャリアで二度とそれをやりたくない場合は、ワンライナーを書いてください。リファクタリングをいつ停止するかは、現在のプログラミング作業を将来どのように使用するかによって異なります。たとえば、将来多言語化が予定されている Web サイトをプログラミングしている場合、次のようにします。

class Greeter
  GREETINGS = {
    en: "hello",
    ru: "привет",
    cn: "你好"
  }

  TARGET = {
    en: "world",
    ru: "мир",
    cn: "天地"
  }

  def do_your_grim_business( language )
    puts [ GREETINGS[ language ], TARGET[ language ] ].join( ", " ) + "!"
  end
  alias :act :do_your_grim_business
end

timothy = Greeter.new
timothy.act( :en )

それがあなたの心を成長させ、明るい未来へと広げていくでしょう。しかし、無理をしないでください。なぜなら、間違いを犯した人が言うように、Ruby は Play-Doh だからです。

于 2012-09-18T10:22:24.203 に答える