じゅげむじゅげむごこうのすりきれかいじゃりすいぎょすいぎょうまつうんらいまつふうらいまつくうねるところにすむところやあぶらこうじのやぶこうじぱいぽぱいぽぱいぽのしゅーりんがんしゅーりんがんのぐーりんだいぐーりんだいのぽんぽこぴーのぽんぽこなーのちょうきゅうめいのちょうすけ

結構良く見かけます。こういうメソッド。
なんのことかさっぱりわかりません。

適切に分割することにしました。

じゅげむじゅげむ、ごこうのすりきれ、かいじゃりすいぎょ、すいぎょうまつ、うんらいまつ、ふうらいまつ、くうねるところにすむところ、あぶらこうじのやぶこうじ、ぱいぽぱいぽぱいぽのしゅーりんがん、しゅーりんがんのぐーりんがん、しゅーりんがんのぐーりんだい、ぐーりんだいのぽんぽこぴーのぽんぽこなーの、ちょうきゅうめいのちょうすけ

うまく、分割されているので、それぞれをオーバーライドして、もっと分かりやすくできそうです。

寿限無、寿限無、五劫の擦り切れ、海砂利水魚、水行末、雲来末、風来末、食う寝る処に住む処、やぶら小路の藪柑子、パイポパイポ パイポのシューリンガン、シューリンガンのグーリンダイ、グーリンダイのポンポコピーのポンポコナーの、長久命の長助

適切に分割されていれば、意味も分かりやすく、打ち間違いがないかの確認もはるか簡単ですし、その一部のみを再利用することも、置き換えて、より良くすることもできます。

では、うまい具合に「適切」に分割するにはどうすればよいのでしょうか？

私がプログラムの設計・実装でいつも心がけていることが２つあります。

ひとつは、要のモノと要のコトを見つけ出すこと。
ひとつは、仕訳パターンを適用できるか試みること。
の２つです。

要のモノ、要のコトとは、なんでしょうか？

湯を沸かすという仕事があります。

手順としては、水を器に汲んで、沸かしてお湯にします。
水は水道からヤカンに汲むかもしれませんし、雨水をバケツにためるかもしれません。
焚き火で沸かすかもしれませんし、虫眼鏡で日光を集めて沸かすかもしれません。

手段がどうであれ、必ず必要なのは、水を摂氏１００度にすること。
それだけです。要のモノとは水とお湯。要のコトとは、水を摂氏100度にすること。
その他のことは、変わる可能性がいくらでもあるし、場合によっては必要ないかもしれません。

この考えを使って、１つのメソッドには要のコトを一つ盛り込むようにしています。
INPUTである要のモノに、要のコトという処理をして、OUTPUTの要のモノに変換します。それ以外の、変わるかもしれないし、必要ないかもしれないことは、抽象メソッドにでもして、継承先の派生クラスで必要に応じて処理を実装するようにしています。
継承先で何も実装しなければ、何もしません。

ソースであらわすとこんな感じでしょうか。
public abstract class AbstractSomethingDoer{

　　protected abstract Input doBefore(Input input);

　　protected abstract Output doAfter(Output output);

　　public void doSomething(Input input){

　　　input = doBefore(input);

　　　Output output = doKanameThing(input);

　　　output = doAfter(output);

　　　return output;
　　}
}

この湯を沸かすという要のモノとコトの話、偉い人の話を聞きに言った先で、全然別の人がそれぞれに例として出されており、ハハァーと感心すると同時に、果たして元ネタはどこにあるのかと思い探した結果、ここ→にありました。

また、業務系SEにとって大きな武器になる会計の知識で、在庫や掛けのデータ設計をこの仕組みに習うのは不可欠ですが、私はその他にもこの仕組みを取り入れるようにできないかを考えるようにしています。

ある時点の状態を表す貸借対照表と一定期間の状態の変化を表す損益計算書および、その元となる仕訳帳。いかにもパターンにありそうな事象ですよね。アナリシスパターンとか。挑戦したことがないので知りませんが。

たとえば社員と部署のリソースの関係、特定期間ごとのスナップショットをリソースに保持し、イベントの履歴を、借り方に社員の移動先部署、貸し方に移動元部署という形で仕訳しておけば、ある時点の状態に差分の仕訳を加えて、いつ、どの時点の状態でも簡単に取り出せます。

もちろん単純に社員と部署を結びつけた場合よりも、SQLは複雑になりますが、どのデータでも同じ手続きで取り出せることができるようになり、当然これを呼び出すクラス構造も取り出すプロセスも、統一することができます。

駈け出しのころに、DOAのグルの一人が、リソースとリソースは直接結び付けずに必ず間にイベントを挟むというポリシーを説明していたのを聞いて、当時は理由が理解できませんでしたが、業務面に眼を向けるようになり、ようやく意味がわかったような気がします。

会計の本は何冊も挑戦し、幾度と無く敗れてきましたが、ツンがデレになってきたのは→の本を探し当てたときです。

そんな開眼式を経て、私の寿、限り、無し。かといいますと、まあそれがなかなか、悩みのタネは、海の砂、水に住む魚の数ほどに、限りが無い。ようであります。