「クソコード動画「共通化の罠」」

https://twitter.com/MinoDriven/status/1127539251761909760
ホットエントリ経由.


初心者が良くやる落とし穴.こうなると地獄.

うん,このくらいなら動画で作るのもありかな.

オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方 オブジェクト指向における再利用のためのデザインパターン APIデザインの極意 Java/NetBeansアーキテクト探究ノート

「じゃあどうすればいいのか」については,デザパタやMets本なんかを読んで勉強しろとしか.ソフトウエア再利用はは古くて新しい問題.
https://tech.nikkeibp.co.jp/it/free/ITPro/OPINION/20030918/1/

http://b.hatena.ne.jp/entry/s/twitter.com/MinoDriven/status/1127539251761909760

  • id:mizoguche 通化はシステムにおける共通部分の意味をよく考えないと保守で死ぬのでむしろコピペのがマシなこともあるみたいな話よくある
  • id:el-condor 処理が似てるから安易に共通化するとこうなるという話。それが本当に抽象として同じなのか考えてみないとダメだよね。あとその分岐本当に必要か、というのも。
  • id:akanehara 似ているだけの別のものかもしれないと立ち止まらず拙速に共通化してDRY!DRY!と喜んでるの、カモノハシを鳥に分類するみたいなアホさを感じる。

オブジェクト指向プログラミング入門

  • id:dot コンテキストを無視して同じ処理だからという理由だけで共通化すると失敗するのよく見る。
  • id:rti7743 コピーしてバージョンをつけようとすると、MSが陥ったDLL地獄の再来。
  • id:Lagenaria 同じコードが3回出てきたら通化を検討すべしってどこかの記事で読んだな。

ソフトウェア再利用の神話―ソフトウェア再利用の制度化に向けて (Professional Computing Series)

ソフトウェア再利用の神話―ソフトウェア再利用の制度化に向けて (Professional Computing Series)

 「ソフトウェア再利用の神話」(ウィル・トレイツ著,ピアソン・エデュケーション)という本に,再利用に関する「3」の法則が出てくる。すなわち,「再利用可能なソフトを開発するには,3回は作り直す必要がある」,「再利用の恩恵にあずかるには,少なくとも3回は再利用する必要がある」というものだ。

https://tech.nikkeibp.co.jp/it/free/ITPro/OPINION/20030918/1/


  • id:ghostbass 動かないコードは悪(というか評価に値しないが)だが、動くコードにも良し悪しはある
  • id:Kuichi CSSで割とこんな状態になっていたりで辛い…。


  • id:kawaxbiz通化のために親クラス作って継承してると大抵死ぬ。最近やっとどの言語でも継承はよくないと広まってきた

最近?すくなくとも1995年には.
Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional Computing Series) オブジェクト指向における再利用のためのデザインパターン

それ以前から継承爆発とダイヤモンド継承の問題は指摘されていて,継承の危険性は広く知られていた.

「安易な共通化の罠」とか「共通化の落とし穴」とかかな?

オブジェクト指向開発の落とし穴

オブジェクト指向開発の落とし穴

  • 作者: B.F.ウェブスター,Bruce F. Webster,細井拓史
  • 出版社/メーカー: プレンティスホール出版
  • 発売日: 1995/11
  • メディア: 単行本
  • クリック: 1回
  • この商品を含むブログを見る
こっちに載ってたかは忘れた.

時代的には載ってても不思議ではないけれど.

落とし穴 7.1 is-a関係,has-a関係、is-implemented-using関係の3つを混同する
落とし穴 7.2 インターフェースの継承を実装の継承と混同する
落とし穴 7.3 不適当な継承の使い方をする
落とし穴 7.4 基底クラスの機能が多すぎたり少なすぎたりする

あたりかな.

  • id:akfmi Aの特別処理を共通モジュールに入れた時点で破綻しているのでは・・?

そこは「終わりの始まり」で,ヤバイ匂いは最初から.ベテランなら,早ければ開始1秒で気づくというのはウソではない.

「Cプログラミング診断室」

http://www.pro.or.jp/~fuji/mybooks/cdiag/cdiag.11.3.html

改訂新版 Cプログラミング診断室

改訂新版 Cプログラミング診断室

「第11章 奇っ怪な条件」 


名前は、上下左右(up,down,left,right)の部分が違うだけです。
関数の中身の方も、実はほとんど 同じです。違いのある行は、
  1             関数名 mac_up_event
  25〜27        mac_yの設定(減少)
  52            関数名 mac_down_event
  76〜82        mac_yの設定(増加)
  107           関数名 mac_left_event
  131〜133      mac_xの設定(減少)
  158           関数名 mac_right_event
  182〜189      mac_xの設定(減少)
に過ぎません。ということは、9割までが同じということです。
ほとんど同じものは1つで済ませようという「横着心」が働いてきませんか。

*1:それって「密結合」だ.

*2:この時点で,いっそAだけバージョン戻した方がマシかもしれない.

*3:時にはその何百倍も,何万倍ものコストがかかる.