アカウント名:
パスワード:
ここ何年か、オブジェクト指向分析設計やオブジェクト指向プログラミングなどを推進しているが、プロジェクトの規模が大きくなるとどうしてもうまくいかない、これはいったいなんなんだろうか?と悩んでいる。
アラン・ケイだったか、誰だったかの記事かBlogで、Smalltalkを使うとこんな感じで英語みたいになるんだよ、と書かれているものをみて、ハッ、っと思った。我々日本人ではこの感覚は英語を理解していないとできないし、これが案外オブジェクト指向のギャップではないかと。
英語圏のひとは、UMLでクラス図を描いても、そのままそれがコードになる。我々は、日本語を一旦英語にすることで、一呼吸おく必要がある。
オブジェクト指向の世界では日本語がいろいろ足かせになっていると感じている人、他にいませんか?
>僕がいままで目にしたオブジェクト指向の説明って>似たような機能や、ロジックがあれば抜き出して、別のオブジェクトにするべきだ>みたいな記述がおおかったです。
あーそれってOOPでもなんでもなく、従来(悪い意味も含めて)通りの「関数分割」の考え方ですね。
機能が似てるかどうかじゃなく、どれがその機能のレシーバ(機能の享受者とか)として似合うか?で分け方を決めるほうが、OOP的には座りがいいですね。
関数分割とは見る軸が違うというか直交な感じ、たとえば関数分割が「条」ならばOO分割は「丁目」かな。
関数分割的な視点も必要なときは多いけど、逆にそれを優先しないほうが良い場合も多いんで、バランスのとりかたが色々で色々かな。
>担うべき役割を中心にして>モジュール強度を上げることが目的
それもちょっと違うと思う。役割(責務)というけど実際にはOO分割は責務分割とはまた違う話なような気がする。
#だいたい関数分割だって「責務」分割の一種だと言おうと思えば言えてしまうんだし。
どっちかというと、責務以前の問題として「そのオブジェクト(のクラス)はこうアルベキなんだよ」という酷く身勝手で独りよがりな定義(www)からまず入る感じがする。ただし当然だけどその独りよがりな定義が系の秩序を乱すならばそのクラスは淘汰される…
そして、定義とか責務とか言ってみたけど、それだけでOOか否かの違いは語れないですね。定義とか責務とかを「OOの軸に基づいて」考えることがOO分割である、という酷くトートロジーな説明をする必要が有ると思う。
OOの考え方(特に関数型とかクロージャ型との違い)は、「データに手続きが付く」「データに見合った手続きが付く」「データに見合わないなら手続きのほうを差し替えてしまえ(=多態)」というデータ中心な考え方(こだわりかた)にこそ有るでしょう。(関数型だと逆に「手続きにデータが付く」になる。)
データ中心という言葉をわざと使いましたが、実のところOOと近いのはむしろいわゆるDOA陣営じゃないか?と私は思っています。もっともDOAだとデータは考えるけどデータに見合った処理まで考えるのが(道具が主にRDBなせいか)ちょっと難しいのがOOとの違いであり、かつこの「データに見合った処理をデータのほうが引き寄せる」という考え方は(うまくやれば)実用アプリでも非常に役立つ作戦なので、それが取りにくい所謂DOAはちょっと損をしてるかなという気もします。RDBもトリガーだけじゃなくその多態も(業界標準で)装備してればだいぶマシなんだけどねえ。
#動的言語の多態と状態遷移管理とは凄く相性が良いんじゃないか?と思ってるのでAC
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
オブジェクト指向と英語 (スコア:2)
ここ何年か、オブジェクト指向分析設計やオブジェクト指向プログラミングなどを推進しているが、プロジェクトの規模が大きくなるとどうしてもうまくいかない、これはいったいなんなんだろうか?と悩んでいる。
アラン・ケイだったか、誰だったかの記事かBlogで、Smalltalkを使うとこんな感じで英語みたいになるんだよ、と書かれているものをみて、ハッ、っと思った。
我々日本人ではこの感覚は英語を理解していないとできないし、これが案外オブジェクト指向のギャップではないかと。
英語圏のひとは、UMLでクラス図を描いても、そのままそれがコードになる。我々は、日本語を一旦英語にすることで、一呼吸おく必要がある。
オブジェクト指向の世界では日本語がいろいろ足かせになっていると感じている人、他にいませんか?
Re: (スコア:0)
プログラマとしてグローバルに活動するのなら必須なんでしょうねぇ。
最新の技術文書も英語だし、やっぱ英語は使えるようになりたいです。
オブジェクト指向については、
「うまくいかない」という症状の質にもよるとおもうけど、
実装するべき機能の本質や役割を無視して分割しようとしていませんかね。
英語圏と日本人による、感性の違いというのはあるかもしれませんけど
設計(デザイン)で言語が壁になるとは思えないです。
僕がいままで目にしたオブジェクト指向の説明って
似たような機能や、ロジックがあれば抜き出して、別のオブジェクトにするべきだ
みたい
Re:オブジェクト指向と英語 (スコア:0)
>僕がいままで目にしたオブジェクト指向の説明って
>似たような機能や、ロジックがあれば抜き出して、別のオブジェクトにするべきだ
>みたいな記述がおおかったです。
あーそれってOOPでもなんでもなく、
従来(悪い意味も含めて)通りの「関数分割」の考え方ですね。
機能が似てるかどうかじゃなく、
どれがその機能のレシーバ(機能の享受者とか)として似合うか?で
分け方を決めるほうが、OOP的には座りがいいですね。
関数分割とは見る軸が違うというか直交な感じ、
たとえば関数分割が「条」ならばOO分割は「丁目」かな。
関数分割的な視点も必要なときは多いけど、
逆にそれを優先しないほうが良い場合も多いんで、
バランスのとりかたが色々で色々かな。
>担うべき役割を中心にして
>モジュール強度を上げることが目的
それもちょっと違うと思う。
役割(責務)というけど実際にはOO分割は責務分割とはまた違う話なような気がする。
#だいたい関数分割だって「責務」分割の一種だと言おうと思えば言えてしまうんだし。
どっちかというと、責務以前の問題として
「そのオブジェクト(のクラス)はこうアルベキなんだよ」
という酷く身勝手で独りよがりな定義(www)からまず入る感じがする。
ただし当然だけどその独りよがりな定義が系の秩序を乱すならばそのクラスは淘汰される…
そして、定義とか責務とか言ってみたけど、それだけでOOか否かの違いは語れないですね。
定義とか責務とかを「OOの軸に基づいて」考えることがOO分割である、
という酷くトートロジーな説明をする必要が有ると思う。
OOの考え方(特に関数型とかクロージャ型との違い)は、
「データに手続きが付く」「データに見合った手続きが付く」「データに見合わないなら手続きのほうを差し替えてしまえ(=多態)」
というデータ中心な考え方(こだわりかた)にこそ有るでしょう。
(関数型だと逆に「手続きにデータが付く」になる。)
データ中心という言葉をわざと使いましたが、
実のところOOと近いのはむしろいわゆるDOA陣営じゃないか?と私は思っています。
もっともDOAだとデータは考えるけどデータに見合った処理まで考えるのが(道具が主にRDBなせいか)ちょっと難しいのがOOとの違いであり、
かつこの「データに見合った処理をデータのほうが引き寄せる」という考え方は(うまくやれば)実用アプリでも非常に役立つ作戦なので、それが取りにくい所謂DOAはちょっと損をしてるかなという気もします。RDBもトリガーだけじゃなくその多態も(業界標準で)装備してればだいぶマシなんだけどねえ。
#動的言語の多態と状態遷移管理とは凄く相性が良いんじゃないか?と思ってるのでAC