読者です 読者をやめる 読者になる 読者になる

SE(たぶん)の雑感記

一応SEやっている筆者の思ったことを書き連ねます。会計学もやってたので、両方を生かした記事を書きたいと考えています。

クソコードが生み出す余計な「将来的な費用」について、金額面で考えてみた

会計 雑記 システム開発

最近、クソコードを見るのが楽しくなっています。

クソコード、格好良く言い換えれば技術的負債とも言えますが、これがどういう余計な費用を生み出していくか、思ったことを書いてみます。

なぜ「利益」ではなく「費用」なのか

クソコードが費用となるなら、超美麗なコードは利益を生み出すのか?  

という疑問はあると思います。

これは先に説明が必要ですね。

まず、どれほど綺麗に書かれたソースでも、「それ自体では収益を生み出さない」です。
システムが利益(これは収益の増加、費用の削減両方を含む)を生み出すかどうかは、システムのコンセプトや営業活動、利用促進等に依るところが大きいです。
よって、システムが仕様通りに作られている限り、「プログラム内部がクソコードかどうか」は、一応関係ありません。

クソコードでもいいんじゃね?という状況

いきなり例外(笑)

絶対に自分しか使わないソース

好きなだけ汚してください(笑)
これは、別にきれいに書いてもいいんですが、誰にも迷惑かけないのであれば好きなように書いていいと思いますよ、という意味です。

この場合は、少々クソでも、自分がわかればいいので、特に問題ないと思います。

作ったら、二度とメンテしないシステム

いずれメンテするかもしれないじゃないかというのは、いったん置いといてください。
システム作成時点で、次版を作るつもりがないなら、クソでも問題ないです。

ただし…
仮に当初決定が覆り、機能拡張等が発生した場合、当初のソースは捨てましょう。
機能追加分と「将来の改訂予定」を加味して、再設計したほうが、将来的にコストが安くなります。

あとで書きますが、メンテを考慮していないプログラムを修正するぐらいなら、作り直したほうがいいです。

保守担当が一人(定期改訂あり)

まぁ、別にずっと同じ人がメンテするなら、少々ソースが汚くても…とは思います。
その人が辞めても、死んでも、働かせる気があるならですが。

『プログラミングの心理学』に、プロジェクトの支柱となっている人の例が載っているので、見てみるとよいでしょう。
結局、「その一人がいなくなったら終わり」という状況でうまく行くわけがない、とのことです。
以下、同書の引用。

大規模組織のとりわけ興味深い特徴の1つは、どのメンバーの在籍期間よりも長い期間にわたって存続できることである。
~(中略)~
ところが、多くのマネジャーは自分のプログラミングプロジェクトに同じ理屈をあてはめることができない。

クソコードが費用を発生させる状況

仕様変更

クソコードの特徴として、「書いた人以外が読めない」というものがあります。
(書いた人が読めないこともある!!!)

仕様変更があったとき、ソースが読めないと、変更できないですよねー。

担当者変更

「ギリギリ仕様通り動いているけど、ソースがクソ」の場合、後任は大変ですねー。
この場合は、ソースが綺麗でも、「引継ぎが不十分」とか「後任者の力量不足」の場合でも、大変です。

もしくは、開発委託先を変更した場合も含みます。

凍結予定のシステムの仕様変更

「まさか…次版を作るだと…?」

設計書が無い

どれほどクソコードでも、「何を達成しようとしたのか」記載してある設計書があれば、「何を作ろうとしていたのか」わかります。
しかし、それすらもなければ…どうなるやら。

クソすぎて既に炎上している

お金をドブに捨ててでも、火を消すしかない状況ですね。
「炎上しているプロジェクトのソースは、たいていクソ」と言われます。

クソコードが生み出す、絶賛炎上中のシステムは、当目は「火を消す」しかないです。
なので、「将来的な費用」の考慮対象外とします。

本題:なぜクソコードは「余計な費用」となるのか

管理会計の世界では、「意思決定」という分野が存在します。
これは、かなり単純化して言うと、

その投資を行った際の、「支出(キャッシュ・アウト・フロー)」と「収入(キャッシュ・イン・フロー)」から「純額(ネット・キャッシュ・フロー)」を算出し、それがより大きい投資案を採択する

ものです。(割引現在価値とか、いろいろありますが、説明の都合上無視します)

仮定0:すべてがうまくいった場合の金額

※1年で区切ります。また、1年目に当初開発が終了し、毎年改訂を行うものとします。

費目 初年度 1年後 2年後 3年後 4年後 5年後
収入 2,000,000 2,000,000 2,000,000 2,000,000 2,000,000 2,000,000
支出 1,000,000 1,000,000 1,000,000 1,000,000 1,000,000 1,000,000
利益 1,000,000 1,000,000 1,000,000 1,000,000 1,000,000 1,000,000

→合計:6,000,000円

仮定1:クソコードのシステムを改訂する(人海戦術で期間通りに改訂できた)

先ほど書いた通り、

どれほど綺麗に書かれたソースでも、「それ自体では収益を生み出さない」

です。言い換えると

ソースの品質そのものは、収益に関係ない

ものとします。

そうなると、クソコードを改訂するために「余分にかかった費用」の分だけ、利益が減ります。

費目 初年度 1年後 2年後 3年後 4年後 5年後
収入 2,000,000 2,000,000 2,000,000 2,000,000 2,000,000 2,000,000
支出 1,000,000 1,200,000 1,400,000 1,600,000 1,800,000 2,000,000
利益 1,000,000 800,000 600,000 400,000 200,000 0

→合計:3,000,000円

6年後からは損失ですね。南無。
なお、例だから、比例的に増やしましたが、クソコードがあると「加速度的に」費用は増えます。
(改訂内容によるとは思う)

仮定2:クソコードのせいで、予定していた改訂が行えず、収益が得られなかった

これは、単純に収益が減少したケースです。
費用が増えることを、とにかく嫌った場合とかですかね。

費目 初年度 1年後 2年後 3年後 4年後 5年後
収入 2,000,000 1,800,000 1,600,000 1,400,000 1,200,000 1,000,000
支出 1,000,000 1,000,000 1,000,000 1,000,000 1,000,000 1,000,000
利益 1,000,000 800,000 600,000 400,000 200,000 0

→合計:3,000,000円

なお、IT業界の変遷は早いので、改訂速度が遅いシステムなんて、あっという間に淘汰されます。
こんなのんびり、収入が減るなんてことは、現実には無いでしょう。

仮定3:クソコードのせいで、思ったほど利益が上げられなさそうなので、1年後に解消に走った(うまくいった)

誰もが得する(かもしれない)理想パターンです。
なお、「クソコードを修正し、再構築するのに、支出は仮定1の3倍かかる」ものとします。

費目 初年度 1年後 2年後 3年後 4年後 5年後
収入 2,000,000 2,000,000 2,000,000 2,000,000 2,000,000 2,000,000
支出 1,000,000 3,600,000 1,000,000 1,000,000 1,000,000 1,000,000
利益 1,000,000 -1,600,000 1,000,000 1,000,000 1,000,000 1,000,000

→合計:3,400,000円

雑な仮定ですが、「1年後に240万支出を増やすことで、将来の支出を280万抑える」結果となります。

仮定4:クソコードのせいで、思ったほど利益が上げられなさそうなので、3年後に解消に走った(うまくいった)

修正年以外の仮定は、「仮定3」と同じです。

費目 初年度 1年後 2年後 3年後 4年後 5年後
収入 2,000,000 2,000,000 2,000,000 2,000,000 2,000,000 2,000,000
支出 1,000,000 1,200,000 1,400,000 4,800,000 1,000,000 1,000,000
利益 1,000,000 800,000 600,000 -2,400,000 1,000,000 1,000,000

→合計:2,000,000円

直すのが手遅れ、な感じです。
直さないほうがましかもしれませんが、6年目以後を視野に入れるなら、クソコードを解消するしかないでしょう。

仮定を見て(総括)

今回は、仮定3が最も良い結果となるようにしました。
でも、エンジニアの方々なら、仮定1の「加速度的に費用が増える」や、仮定2の「のんびり収入が減ることはない」というのには、同意していただけるように思います。

クソコードと戦うには

発注者が、クソコードのメンテを依頼してきた場合、我々はどうしたらよいのでしょう?
最も大変なのは、「相手がソースなんて理解していない」場合だと思います。

このソースはクソだから、余計に費用がかかるんです!と言っても信じてもらえず、「前はこれだけなんだから、同じ金額で受けてもらわないと困る!」みたいに圧力かけられたりとか…(妄想です)

そういうときに、金額的な根拠も示せると、もしかしたら不合理と戦える交渉でも有利になれるかもしれない、と思います。(妄想ですが)

もし、費用面で相手が納得したら、今度はクソコードを解消できるだけの設計技術が必要となり…という感じですね。
SEの勉強は、こうしてまだまだ続きます…

といった感じでおしまい。

「転職」という選択肢を持つこと

雑記

ちょっと自分語りみたいになるけど、話します。
4月から新入社員の方々が職に就く、というタイミングで書く内容ではない気がしますが…


IT業界は、転職に対しては寛容だと思います。
業界に限らず、世の中的にも、「辛いなら辞めたほうが良い」という空気があるように感じます。

もちろん、今の仕事に全く不満がない、という方もいらっしゃると思います。

それでも、今の仕事に固執せず、「転職」という選択肢を持つことは、様々なメリットがあると思います。

転職を意識するメリットについて

視野が広がる

これは、転職サイト等を見て、という話にはなるのですが。
新卒採用と、中途採用では、採用の内容がまるで違います。
(当たり前ですが)

職種であったり、求められるスキルであったり、様々です。
「今はこの業種の求人が多いのか」と、業界の状態を見ることも、できなくはないです。

とりあえず、転職サイトに登録だけしておけ!という記述をたまに見かけるのは、そういう効果を狙ってると思います。

どのようにスキルを伸ばせばよいかの参考になる

中途採用では、新卒採用に比べ、求められるスキルが具体的になります。
例えば、ある経験を何年以上、みたいなものです。

それにより、「こういうスキルや経験を積めばいいんだな」という参考になります。
経験は難しくても、スキルを積むのは、働きながらでも可能です。

仕事のとらえ方が変わる

プロジェクトマネジメントでは、無理な仕事は受けるなという鉄則みたいなものがあります。*1
「無理な」と言っているのは、プロジェクトの人員的な内容もありますが、相手先が無茶を言っているという要素が多分に含まれます。

とある本に書かれていたのですが、そのプロジェクトに失敗したからと言って、自分や誰かが死ぬわけじゃないのだから、逃げたって良い、とのこと。
他の、ちゃんとした仕事を受ければ良いのです。
(相手が辛そうだから格安で受ける、なんてやって苦労するのは、プロジェクトメンバー)

これと、転職がどう関係あるかというと…

要は、目の前の仕事が全てではないということです。
ギスギスした職場、ありえない環境、人間関係、厳しい納期、デスマーチ
いろいろ、会社に入って辛いことはあります。
でも、辛くて嫌になったら、別の道に行けばいいんです。

戦略的に逃げるのは、何も間違っていません。
仕事はそういうものだと思います。

注意点

「いつか辞めるしー」みたいなのを周りに吹聴する

転職意志が実在するかどうかは関係ないです。
正直、印象悪いです。
よほど、今の会社がクソでない限り、公言はしないほうが良いと思います。
もしも、上司の耳に入ったりしたら…という感じです。

実力磨きを怠らない

働いている間は、学べることは学んだほうが、自分のためだと思います。
働くのは、私が思うには「お金もらえる上に勉強にもなる」ことです。

…まあ、勉強する暇がないほど忙しいと、どうしようもないですが。(その時は転職だ!)

もし、実際に転職するときに、自分の強みも何もないと、苦しい戦いになります。きっと。

自分のこと

前職を辞めようと思ったきっかけ

自分のスキルを伸ばしたいとか、いろいろ経験を積みたいとか、もっとSEとして成長したいとか、そういうのはありました。 だから辞めよう、とはすぐにはならなかったです。
前の会社が嫌になった一番の要因は、「強烈なトップダウン」に気付いたからです。
基本、下々の者が上に何か言っても、無視です。

システム開発の話ですが、
「ここの作りがまずいので、リファクタリングしませんか?」とか、「入力したものそのまま出力するなら、処理まとめたほうがよくないですか?」という話を上司や先輩にしても相手にされないのですが…
偉い人が、会議とかで同じことを言うと、「よしやるぞ!」みたいな感じでした。

他にも、「このシステムの、この改善要望を実現したいから分析して」と言われ、

「この要望は実現できなくはないですが、苦労するわりに限られたユーザーしか恩恵無いから、先を見据えて、根本解決する方針で再分析したほうが良いと思います!」

と言ったら、分析から外されたり。

あと、そもそも全体的にことなかれ主義で、現状を変えたらがない状況も嫌でした。
社員に向上心が無く、本当に腐っていたと、いまだに思います。
そこそこ大きい会社だったので、過去の偉人が作った資産(遺産?)を食いつぶして、生きながらえているように思っています。

結局言いたいこと

今の仕事が全てではないということです。
環境に問題があるときは、自分の考え方を変えるとか、泣き寝入りせず上司に働きかけるとか、様々な方法を試したほうが良いと思いますが、どうにもならないときは本当にどうにもなりません。

法律上、「仕事を辞めさせない」ことは、事業者にはできないので、何も気にする必要はありません。
無理な時は、もっといい会社を探しましょう。

というお話。

*1:だから、プロジェクトマネージャは、様々な指標や経験を利用して、実施可能性を計測する必要がある

.NETのソースがMSDNの記事から開ける件

C#

現在、衝撃に打ちのめされています。

何気なく、IEnumerable<T>のヘルプでも開いてみるか、と思い、ブラウザで検索していて…

f:id:hiroronn:20170316202314p:plain

相変わらず日本語訳めちゃくちゃだな
お、Reference Sourceってなんだ?

って思い、

f:id:hiroronn:20170316202310p:plain

クリックすると…

f:id:hiroronn:20170316202317p:plain





はあ!?( ゚Д゚)


なんでしょうね。
.NETのソースコードを公開した、というのはどこかで聞いていたのですが、まさかMSDNからリンクしているとは…

Githubとかに上がってるのかと思っていましたが、そんなこともなく。
とにかく衝撃です。

ILSpyの役割はどうなるのか

C#でデザインパターン 頓挫した

C# 雑記

C#デザインパターンについて書こうと思っていましたが、頓挫しました。

元記事:C#でデザインパターン ネタ作り中 - SE(たぶん)の雑感記

理由

いくら書いても、インターフェイスの説明にしかなりませんでした。
もちろん、それでもまとめることに意義はあるのですが…

今後の方針

C#Interfaceについて書こうと考えています。

拡張メソッドやLinq、Observer等、C#はInterfaceを利用して、進化を遂げました。

拡張メソッド:拡張メソッド (C# プログラミング ガイド)
LinqLINQ クエリ式 (C# プログラミング ガイド)

これらや、DI等の新しいデザインパターンを加えて、Interfaceについて説明したいと思います。

作ったメモ

さらします。

github.com

メモ用にGitHubリポジトリ切りました。

すごく雑な作りです。
誤りはたっぷりあると思いますが、どうか生暖かい目で見てください。


英語も勉強したい今日この頃…
ではまた。

「そうなるはず」が「そうならない」

雑記

ふと思ったので。

ツールでもシステムでも、「こう操作したらこうなるはず」というものがあります。

でも、そうならないときがあります。
午前中、それで躓いて四苦八苦していました。

結局、あまり関係なさそうな箇所を試しに修正したら、全てのテストにパスしました。
どういうときに困ってしまうか、思いつくままに書いてみます。



章立て



「そうならない(思った通りにならない)」ときの対処

対処法を調べるとしたら、だいたいこんな感じでしょう。

  • 自分の入力操作を見直す
  • マニュアルを見る
  • ほかにうまくいってそうな場所を見る
  • ググる
  • 諦めて質問する

調べるときに困っちゃうシステム

こういうの困ります。

マニュアルやヘルプに、システムから飛べない

知りたいことを知るために、マニュアルの場所を調べるという、よくわからない状態になります。

マニュアル、ヘルプがよくわからない

「知りたいのはそれじゃない」とか、「それはわかってる」とか。
基本的な操作方法じゃなくて、「この機能を使うとこうなります」みたいなのが欲しい。

そもそも、システム単体で操作方法わからないって、相当UX悪い。

後戻りできない

undoとかない、そういうシステム。
苦労して大量に入力したデータを消さないと検証できないとか、最悪ですね。

利用者が少ないシステム

当たり前ですが、利用者が多いほど、Web上に情報があります。
利用者が少ないのが悪い、とは言っていません。

サポートの対応が悪い

サポートを受けられる契約である場合、不明点はサポートデスク等に聞くと思います。
そこの対応が悪い(すぐに返事がない、たらいまわしとか)と、解決せずに困ります。

「そうならない(思った通りにならない)」システムを作っちゃったらどうなるか

完全に妄想ですが、書いてみます。
なお、昔は良いシステムだったけど…というものも含みます。

サポートにかかる時間が増える

ユーザーに小さな躓きが発生すると、その分サポートへの問い合わせが増えると懸念されます。

全ての機能を使ってもらえなくなる

思った通りにならない以上、ユーザーは「思った通りになる範囲」でしか、システムを利用しなくなります。
よって、「利用されない機能」を拡充しても、ユーザーに価値がもたらされない可能性があります。

(そもそも)使われなくなる

競合の良いものが出たら、乗り換えられてしまうかも…

そういうシステムにならないために

そういうシステムを生み出さないようにするには…(これも妄想)

デザイナを雇う

開発者(と設計者)だけでは、システムやその領域に詳しくなりすぎて、問題が見えなくなります。
そういう時は専門家に任せましょう。

先にマニュアルを作る

これは、『デッドライン』に書かれていた手法です。

honto.jp

マニュアルは、システム的には正解なので、ありかな、とは思います。
(が、大抵マニュアルは後回し、というのが現実…)

やり直しできるシステムにする

これは、デザイン等を操作するシステムには必須だと思います。
undoが良いですが、せめて保存するかどうかぐらいは聞くべきです。

よくあるやつ:保存されるかどうか聞かずに消すな!保存するな!

改訂に強いシステムにする

要するに、「設計をしっかり」というやつです。
正直、提供した時点で完璧なシステムは存在しません。
ユーザーの声を受けて、徐々に良くなっていくシステムのほうが、圧倒的に多いです。
だから、「改訂は起こる」ことを前提に、わかりやすい設計やコーディングを心掛けたいものです。


おわりに

結局何が言いたかったのか…

SEをやっていると、わからないことは徹底的に調べる癖(性癖?)みたいなものが生まれます。
特に、プログラミングやっていると、

  • ヘルプを読む
  • サンプル作る
  • 他のソースを読む(Web含む)
  • 人に聞く

等、とにかくあらゆる手段を用いて調べます。
(ヘルプがクソ、Webに情報がない、サポートに聞くと「バグです」と言われるようなプログラミング言語もありますが)

でも、システムのユーザーはそうではないよね、とふと思い、こんな記事を書きました。
使えなかったらユーザーは去る。それを肝に銘じないと、と思います。



p.s.

正直、いいシステムを作るには、デザイナ雇ったり、マニュアル作ったり、いい設計者雇ったりと、お金がかかるばっかりです。
逆に言えば、ケチったらロクなものはできない、という。
システムの状態を正直に言って、そういう人が必要なんです、と言われたら、どうかお金出してあげてください。

「減価償却の自己金融効果」についてまとめてみた

会計

会計学の書籍ではよく、 減価償却には自己金融効果があるよ! と説明されます。
頭には入っていたのですが、よくわかっていませんでした。

最近、『新・現代会計入門 第2版』を読んでいて、やっと腑に落ちたので、メモとして書いておきます。
なお、個人の見解を多分に含むことをご了承ください。

減価償却の自己金融効果」とは

一言で言うと、「減価償却した金額は、企業に内部留保される」効果のことをいう。

なに…?

上だけでは、全く説明にならないので、必要な知識を挙げていきます。
(固定資産って何?簿記って何?みたいなのは省きます)

減価償却

取得時に資産として計上された固定資産を、毎期規則的に費用化していく手続きのこと。

固定資産を導入したら、それを使っている間は「収益を生み出す」恩恵を受けられます。 そこで、取得価額を分割して、収益を生み出している期間の費用として認識していいですよ、という感じです。 (期間対応とかいろいろあるけど、割愛)

内部留保

企業(株式会社を想定。以下同様)が稼得した利益のうち、企業内部に蓄えられる金額のこと。

分配可能額

企業が、株主へ配当できる限度額。
ここでは便宜上、乱暴ではあるが、税金等は無視して「利益は半分配当する」ものとします。
(※配当規制はルールがあるので、そこは調べてもらえると…)

繰越利益剰余金

利益をためている勘定科目。

減価償却が無い場合

収益 - 費用 = 利益
→120 - 90 = 30

よって、

となります。

減価償却がある場合

減価償却が「20」発生したとします。 収益 - 費用 = 利益
→120 - (90 + 20) = 10

よって、

となります。

現金(キャッシュフロー)に着目する

上を見て、「内部留保増えてないじゃん!」となるかもしれませんが、その通りです。
ただ、現金の流れを見ると違いがあります。
なお、減価償却は「現金支出を伴わない費用」です。

減価償却が無い場合

収入 - 支出 = 現金収支
→売上 - (仕入 + 配当) = 現金収支
120 - (90 + 15) = 15

減価償却がある場合

収入 - 支出 = 現金収支
→売上 - (仕入 + 配当) = 現金収支
120 - (90 + 5) = 25

なんと、「内部留保 + 減価償却費」の額が、現金収支となります。
あくまで、会計上、内部留保として計算される額は、「5」ですが、現金収支は「25」です。

結果

収益費用等の科目に着目した場合、減価償却があると、利益が減っています。結果として、配当も内部留保も減ります。
しかし、現金収支上は、企業が自由にできる金額が増えることとなります。
「計算上の内部留保より、自由にできる現金が増えている」ことから、「自己金融効果」と言っているようです。

なんかおかしくない?

内部留保と帳簿に書いてある額と、企業が実際に内部に持っている金額が違います。
おかしくない?と思う人もいると思います。

貸借対照表や損益計算書はそういうもの、と言うしかありません。

ただ、そもそも会計自体「発生主義」を採用していますから、現金収支を伴わない収益や費用なんて、いくらでもあります。
逆に、現金収支はあるけど、収益や費用にしないものもあります。(固定資産購入もそうだし)

現金収支を知るには

上記のように、貸借対照表と損益計算書では、現金収支を知ることはできません。
これは昔から問題になっていたようで、そのために「キャッシュフロー計算書」というものができました。

「キャッシュ(現金)フロー(流れ)」という名前のように、この計算書は「現金の流れ」を明確にするためのものです。

上記の、減価償却費の有無の例を使うと、キャッシュフロー計算書上、「営業活動によるキャッシュフロー」は「30」となります。

結局、何だったのか

減価償却の自己金融効果」は、「現金支出を伴わない費用が発生するとどうなるか」を示すための例、と私は思います。
見かけ上利益があっても現金が無かったり、反対に損失があっても現金があったりと、そういうことがあるのは、こういうものの積み重ねです。
(いわゆる「資金繰り」)

猛烈に話が脱線しましたが、私なりのまとめということで。

C#でデザインパターン ネタ作り中

C#

前の記事で、「EDINET見る」とか言っていましたが、それより
デザインパターンの復習したかったんだよなー」という思いが強かったので、急に方針転換しました。
勝手ながら、言語はC#です。

構想

手順として、

  1. GoFの各パターンの整理
    ここでは、パターン説明だけでなく、新規作成やリファクタリングについても言及する
  2. サンプルソースの作成
  3. 各パターン間の関連
  4. 新たな情報との関連付け(書籍等紹介しながら)

といった感じで考えていました。
情報源は、とりあえずWikipediaだけでいいや、と考えていましたが…

元ネタ:デザインパターン (ソフトウェア) - Wikipedia

ぶち当たった問題点

陳腐化

GoFデザインパターンだけ考えていると、

これ古いだろ…

というものや、

例示が意味分からん…
(例が陳腐化した、と考えてもらえると)
というものがありました。
Wikipediaには、「サンプルコードは、実装例に過ぎない。」と書いてあるものの…あまりにも。

利用例を示そうとすると、「そもそも使わない」という、本末転倒な結論に至ってしまったり…

サンプルの作成

そもそも、デザインパターンは、特定の問題を解決するために、良いと考えられているパターンのことです。

しかし、単独でパターンを適用する、ということはあまりありません。
普通は、複数を組み合わせます。

そうなると、単独のパターンで記述したソースは役に立ちません。
実際、Abstract Factoryパターンのソースを書きましたが…意図が伝わらないだろうと、悲しくなりました。

例えば、こんな感じになりました。

using Practice.Patterns.AbstractFactory.Parts;

namespace Practice.Patterns.AbstractFactory {
    /// <summary>
    /// 車の各部品の生成機能を返します。
    /// </summary>
    public interface ICarFactory {

        /// <summary>
        /// 車体を作成します。
        /// </summary>
        /// <returns></returns>
        CarBody CreateBody();

        /// <summary>
        /// エンジンを作成します。
        /// </summary>
        /// <returns></returns>
        CarEngine CreateEngine();

        /// <summary>
        /// タイヤを作成します。
        /// </summary>
        /// <returns></returns>
        CarTire CreateTire();
    }
}

これで、「実装したファクトリによって、返す部品とかが違うんだよ!」と書いても…
→「誰が組み立てるんだよ!」という疑問(Abstract Factoryにその責務は追わせないほうが良い)
→それをやるのが、Builderだとすっきりする
→要求されて部品作らんだろう
→じゃあ、返すのは部品じゃなくてRepositoryじゃね?(部品なかったら、発注か作成指図)
→それ、GoFデザインパターンに入ってない…

という具合に、作ってもしょうがない状態に陥りました。

継承は良くない、という考え

あまり様々なプログラミング言語に精通していませんが、オブジェクト指向言語においては、

ソース共有を目的とした継承は極力避けるべき

という風潮があると思います。
私もそれには賛成です。
ただ、デザインパターンの多くの例は、継承に触れており、それをインターフェイスに置き換えると、

「それって元のやつと違うじゃん!」

と考えられても仕方ないと思いました。

展望

利用例すら思い浮かばないものは、説明だけ行う、というのもありかと思います。
そして、単独パターンにこだわらず、複数のパターンを適用したソースを公開すべきでは、と今は考えています。

あと、継承はやはり避ける方向でいきます。
C#なら、インターフェイスはとても使いやすいので、問題ないかな…と考えています。
(前職でDelphiやってたけど、いろいろ絶望した記憶がある)

下のようなメモ書きながらネタ作りしています。
まとまったら公開したい…!

f:id:hiroronn:20170228214315p:plain