Smalltalkにはif文がない
「Smalltalkにはif文がない」記事を読んで、なるほどと腑に落ちた。
SmalltalkではTrue・Falseクラスがあるのは知らなかった。
IF文もWhile文も全てメソッド、ブロックで実現できてしまうのか。
「プログラミングの基本はIF文を極力排除する」記事と同じく、オブジェクト指向の良さは、ポリモルフィズム、イテレータにあると思うが、それらは結局、IF文、While文を除去する方向へ進化している。
| 固定リンク
「日記・コラム・つぶやき」カテゴリの記事
- TwitterやFacebookは人力キュレーションツールとして使う(2022.10.02)
- 「現代病「集中できない」を知力に変える 読む力 最新スキル大全」の感想(2022.08.28)
- 人類は海辺から生まれた～水生類人猿説が面白い(2022.08.09)
- 戦前の日本人の気質はまだ成熟していない青年期と同じだった(2022.06.14)
- 物理学を攻略するためのマップ(2022.04.18)
「プログラミング」カテゴリの記事
- Javaのモジュールシステムの考え方をまとめてみた(2022.10.21)
- Javaのモジュールシステムは複雑性をより増している(2022.09.10)
- Javaはなぜ関数型言語になろうとしているのか(2022.09.02)
- Javaのラムダ式の考え方(2022.08.10)
- Javaはオブジェクト指向言語ではなく関数型言語だった～「[増補改訂]関数プログラミング実践入門」はお勧めの本だ(2022.08.06)
コメント
お久しぶりでっす。
>進化している。
銀の弾丸（必殺技）の無い世界で戦っている以上は、３歩進んで２歩下がるのは仕方無い。だから私の考えるトレードオフを書いてみます。
・（静的な）ソースコードで処理フローを追いにくい。
#ランタイムデバッガの無い環境での開発が大変。
・ポリモルフィズムの網羅テストが大変。
#テストケースが漏れやすい。
・(IFを排除すると）メソッド名の命名が難しい。
#意味を明確に表現出来ない命名の場合、チャンク化されず理解に無駄な記憶スタックを消費してしまう。
私の最近の興味は万人向けの基礎技術なんで、いろいろ悩ましい問題があります。
何が言いたいのか解らないまま、ドロン。
投稿: ふくもと | 2005/05/06 09:24
ふくもとさん、お久しぶりです。
うーん、突っ込まれ所満載で反省です(-_-)
福本さんが興味を持っている「万人向けの基礎技術」って何でしょう？
投稿: あきぴー | 2005/05/07 11:49
>「万人向けの基礎技術」
あひゃひゃ、突っ込まれるとちょっと困っちゃうんですけどね。
OOPは設計が非常に難しいと言う問題の裏側には、「使いこなせる奴が限定される」と言うのが存在します。
しかも昨今のソフトウェア開発での新しい理屈のほぼ全てがOO技術の前提条件無しには理解出来ないモノになってしまっています。
そんな一部のスーパープログラマー向けのマニアックな技術じゃ無くて、言葉は悪いですがド新人であっても、ベテランであっても安全に高品質なシステム構築が出来るような基礎技術をまずは体系化したい。
具体的には
・機能の複雑さの判定基準
・各人の生産性の判定基準
・各作業工程毎でのチェックポイント
・かたいコードの書き方
この辺りが私が漠然と書いた「万人向けの基礎技術」って奴ですね。
継承でやろうがデリゲーションでやろうが、実行時バインディングだろうが、どうだって言いんです。ある程度の範囲で誰にでも理解出来て使いこなせるのなら。ＤＯＡもＯＯＡも本質的にはほとんど差が無いと思っています。（関西某ＭＬに初めの頃に書きましたけど、守備範囲の問題もありますけどね）
いわゆる上流工程は誰にでも出来るけど、それを実際のプログラミング言語に落とす時点でとたんに(品質が)ダメになる。
銀の弾丸じゃ無くて良いけど、行き当たりばったりのいい加減な業界スタンダードはもうコリゴリって感じですね。
#自然言語で無くて良いから仕様書から完全にソースコードに変換してくれるアプリがあったら良いのに
投稿: ふくもと | 2005/05/09 09:38
ふくもとさん、コメントありがとうございます(^^)
「OOPは設計が非常に難しいと言う問題」についてはパターン勉強会ではストリームラインで攻める発想でやってますね。
異論はあるでしょうが、1年以上勉強してみて僕自身は現在の数ある手法の中でBetterな気がしています。
「万人向けの基礎技術」の要点は身近な経験として痛切に共感します。
ふくもとさんなら「万人向けの基礎技術」について本一冊書けるのでは？(^^)
同人誌でも買います(^^)
投稿: あきぴー | 2005/05/10 23:51
この手の話は結構悲観的にとらえてるんで、そのつもりで読んでください。（私が何故COBOL万歳なのかもうっすら感じると思います）
ストリームラインでいける程の人材が揃ってるなら素晴らしいと思います。私の中では、その時点で万人向けでは無いのです。
ノイマン型のコンピュータでOOPやるって時点で脱落する人間（プログラマー）が少なく見積もっても3割程度は存在する気がします。あ、ここで言うOOPはOOPじゃ無くてイベントドリブン型のプログラムかも知れません。
縦のモノを横にor横のモノを縦に出来ないんで、クラスがメソッドの名前空間（カテゴリー分類記述子）にしかならない。
つまりグローバルでフラットな名前空間だったのが
クラス名.foo()
に変化するだけで結局は似非OOPなんですよ。
ユースケースでもCRCでも良いんですけど、ＸＸＸＸする機能ってシナリオから名詞を拾ってクラスを取り出しても、それにどういう責務を持たせて、どう組み合わせるのが正しいのか。または、そのインスタンスの生存スコープはどうが正しいのか。機能のエントリポイント（main / イベントハンドラ）からどう呼び出したら良いのか。
まともな設計が出来る人間はほんとに限られています。
業務アプリケーションに関して言えばOOPするメリットが殆ど無いように大多数の人間が感じるところが普及しない最大の理由なんじゃないかなと思っています。メリットがあると思えないなら協調パターンまでたどり着かないですよね
受注クラス、請求クラス、入金クラス、在庫引当クラス、出荷クラスだけで済むなら誰でも出来るんですけどね。（これらをくっつけるビジネスメソッドのクラス、ＹＹＹコントローラーとかＺＺＺマネージャーとかが絶対に出来てこない）
私は自分が書くコードは基本的にOOPしてるし、メリットも相当享受しています。しかし社内標準にするには教育コストも含めて現実解にはなりえないんで、社内向けに独自のアプリケーションフレームワークを構築するしか無いかなーって思ってて、それが去年と今年（と多分来年）の私の仕事です。
BASIC から C に移行する時にかなりのプログラマーが脱落しました。だから MS は GUI に特化した OO-BASIC である Visual Basic を作りました。
C から C++ (VB6 から VB.NET/C#でも良い)に移行する時にもっと多くのプログラマーが脱落しました(脱落するでしょう)。現時点でそれを補完する選択肢はありません。(UMLもパターンもAOPもDIも)だから現時点で真のOOPは"全く"普及していませんし、見込みもありません。
#上位者がOOP出来ないから下位者に教えられない
結局業務アプリケーションレベルであるならCOBOLでも十分なのに、無理にOOPするのがダメなんだってのが私の結論です。（やる事とソースコードの分量増やしてコーディング作業量を増やしてるだけ、ゆえに生産性が落ちるのは当然で、その分のしわ寄せは教育コストに跳ね返ってくる）
あ、私かなりのOO不要論者みたいになってますね。(^^;)
>同人誌でも買います(^^)
うひゃひゃ、買いかぶりすぎです。
万が一体系が完成したら公開なんかしないで社内だけで普及して、会社としての利益を追求しますよ。
投稿: ふくもと | 2005/05/11 09:34