アカウント名:
パスワード:
ここ何年か、オブジェクト指向分析設計やオブジェクト指向プログラミングなどを推進しているが、プロジェクトの規模が大きくなるとどうしてもうまくいかない、これはいったいなんなんだろうか?と悩んでいる。
アラン・ケイだったか、誰だったかの記事かBlogで、Smalltalkを使うとこんな感じで英語みたいになるんだよ、と書かれているものをみて、ハッ、っと思った。我々日本人ではこの感覚は英語を理解していないとできないし、これが案外オブジェクト指向のギャップではないかと。
英語圏のひとは、UMLでクラス図を描いても、そのままそれがコードになる。我々は、日本語を一旦英語にすることで、一呼吸おく必要がある。
オブジェクト指向の世界では日本語がいろいろ足かせになっていると感じている人、他にいませんか?
>オブジェクト指向の世界では日本語がいろいろ足かせになっていると感じている人、他にいませんか?これはない.(思考そのものは)日本語でおけ.
「ロシア語で考えるんだ」 「英語で考えるんだ」みたいな縛りは、オブジェクト指向にはないと思う。
オブジェクト指向の「もの」→「手順」という順序でのものの考え方はむしろ日本語のほうが向いていますが。
>オブジェクト指向の世界では日本語がいろいろ足かせになっていると感じている人、他にいませんか?
逆の例なら読んだことがあるのですが…。
Life is beautiful: 日本語とオブジェクト指向http://satoshi.blogs.com/life/2004/09/post.html [blogs.com]
例が悪いですが「アサヒる」みたいにすぐに単語化(関数化?)する感はありますね。『「○○手続きの実行」をする』みたいな。
>僕がいままで目にしたオブジェクト指向の説明って>似たような機能や、ロジックがあれば抜き出して、別のオブジェクトにするべきだ>みたいな記述がおおかったです。
あーそれってOOPでもなんでもなく、従来(悪い意味も含めて)通りの「関数分割」の考え方ですね。
機能が似てるかどうかじゃなく、どれがその機能のレシーバ(機能の享受者とか)として似合うか?で分け方を決めるほうが、OOP的には座りがいいですね。
関数分割とは見る軸が違うというか直交な感じ、たとえば関数分割が「条」ならばOO分割は「丁目」かな。
関数分割的な視点も必要なときは多いけど、逆にそれを優先しないほうが良い場合
オブジェクト指向はよくわかりませんが、「もしかして英語ネイティブの人って、幼稚園児が話すように話す/書くとそれがプログラムになってたりするんじゃなかろうか」と思ったことはあります。英語から、時制と助動詞取っ払ったものがコンピュータ言語だったりするんじゃないかと。
あと、日本語だと「名詞+する」となって動きの表現があいまいになりがちなところが、動詞の数が多くて、うまく他人と共有できるんじゃないかと勝手に思ってます。 (あるいはそういう仔細な動詞をほとんどの日本人は知らない)
まったく関係ないですが、個人的にはコメント・文章をエセ大阪弁(あるいは口語)で書くと「動き」がうまく表現できるように思います。# 受け手にちゃんと伝わっているかはわかりません。
「それで、この辺をばばーんとでかくしてな、こうぐっぐと押して入れるようにしてや」「あとあっちの方はずいずいっと潜り込ませて、あとだだだーっと流すてのはどうや」こんな感じですね、判ります。
まさにそういうオノパトペ多用を「聞こえる化」という言い方で薦めていた人がどっかのBLOGに居たと思います。
たとえばBTSのチケットとして「画面をもっとがちゃがちゃしないようにする」などといった書き方を許す、というものらしいです。
書類として残すのだったらこれじゃ話になりませんが、アジャイルのように要求の責任を持つ人(オンサイト顧客)が開発現場にも居るという状況ならば、「このがちゃがちゃって何?」とすぐに聞くことも出来るし、すぐに答えることも出来る(身振り手振り満載で)ので、それでOKだ、ということのようです。
また、責任者がそこに居るのならば、その彼に修正物を見せてOKをもらえれば終り、ダメならまた直す、というフィードバックも容易だろうと。
むしろUIの雰囲気などのように「数値化」しにくい面についての改善を求めるとき、へんに数値化を必須とするルールだとチケットの書きようが無くなる、という事態が生じるのを避けたいのだそうです。
分析設計は日本語で十分できるよ。俺の場合は、別名を日本語として常に英語と日本語の両方を同時に考えて進めることもよくある。(別名が設定できて、別名表示ができるツールを使う)
問題は、英語にする能力がないことだよ。英英辞書や、類語辞書は必携。
で、それ以前の問題として、どの言語だろうとネーミングセンスみたいなものがある。名は体を表す。命名は非常に大事。これができない奴は、分析設計に向いてない。
>命名は非常に大事。これができない奴は、分析設計に向いてない。
でも、そういうセンスの無い奴や、そういうセンスの有る人間をむしろ「けむたがる」奴は、実装現場のみならず上流分析屋においても、凄く多いのがわが国の実情だ。
言葉の微妙な違いを「言葉遊びでしかない」と平気で切り捨てて、それで結果的に開発を混乱に陥れる、しかもそんな連中のほうが「人間らしい」と評価されたりするわけだ。
しかも評価する側も言葉の大事さなんて考えてないから、言葉の違いを無視するという重大な(しかも得てしてその奴がいつも繰り返しがちの)ミスをミスだときちんと判定できないのだな。
英語関係ないと思うなあ。「もの」という概念が日本と欧米とで違うわけでもないはずなのだし。「擬人化」だってどちらの文化圏にも大昔からある考えかただし。
せいぜい違いといえば語順だろうと思います。で、それはOOPかどうかじゃなく、プログラム言語の文法の問題でしかない。SVOかSOVかの違い。
たとえばLispの亜種として手続き名をリストの最初じゃなく最後に書くというルールにした実装が有ったが、要はその程度の差でしょう。
単語や語順がより日本人(日本語)に近いような「文法」の言語を作れば済むことであって、その言語がOOP言語か否かで特段の違いが出ると
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
オブジェクト指向と英語 (スコア:2)
ここ何年か、オブジェクト指向分析設計やオブジェクト指向プログラミングなどを推進しているが、プロジェクトの規模が大きくなるとどうしてもうまくいかない、これはいったいなんなんだろうか?と悩んでいる。
アラン・ケイだったか、誰だったかの記事かBlogで、Smalltalkを使うとこんな感じで英語みたいになるんだよ、と書かれているものをみて、ハッ、っと思った。
我々日本人ではこの感覚は英語を理解していないとできないし、これが案外オブジェクト指向のギャップではないかと。
英語圏のひとは、UMLでクラス図を描いても、そのままそれがコードになる。我々は、日本語を一旦英語にすることで、一呼吸おく必要がある。
オブジェクト指向の世界では日本語がいろいろ足かせになっていると感じている人、他にいませんか?
Re:オブジェクト指向と英語 (スコア:1)
>オブジェクト指向の世界では日本語がいろいろ足かせになっていると感じている人、他にいませんか?
これはない.(思考そのものは)日本語でおけ.
「ロシア語で考えるんだ」「英語で考えるんだ」みたいな縛りは、オブジェクト指向にはないと思う。Re:オブジェクト指向と英語 (スコア:1, すばらしい洞察)
オブジェクト指向の「もの」→「手順」という順序でのものの考え方はむしろ日本語のほうが向いていますが。
Re: (スコア:0)
>オブジェクト指向の世界では日本語がいろいろ足かせになっていると感じている人、他にいませんか?
逆の例なら読んだことがあるのですが…。
Life is beautiful: 日本語とオブジェクト指向
http://satoshi.blogs.com/life/2004/09/post.html [blogs.com]
Re: (スコア:0)
例が悪いですが「アサヒる」みたいにすぐに単語化(関数化?)する感はありますね。『「○○手続きの実行」をする』みたいな。
Re: (スコア:0)
Re: (スコア:0)
プログラマとしてグローバルに活動するのなら必須なんでしょうねぇ。
最新の技術文書も英語だし、やっぱ英語は使えるようになりたいです。
オブジェクト指向については、
「うまくいかない」という症状の質にもよるとおもうけど、
実装するべき機能の本質や役割を無視して分割しようとしていませんかね。
英語圏と日本人による、感性の違いというのはあるかもしれませんけど
設計(デザイン)で言語が壁になるとは思えないです。
僕がいままで目にしたオブジェクト指向の説明って
似たような機能や、ロジックがあれば抜き出して、別のオブジェクトにするべきだ
みたい
Re: (スコア:0)
>僕がいままで目にしたオブジェクト指向の説明って
>似たような機能や、ロジックがあれば抜き出して、別のオブジェクトにするべきだ
>みたいな記述がおおかったです。
あーそれってOOPでもなんでもなく、
従来(悪い意味も含めて)通りの「関数分割」の考え方ですね。
機能が似てるかどうかじゃなく、
どれがその機能のレシーバ(機能の享受者とか)として似合うか?で
分け方を決めるほうが、OOP的には座りがいいですね。
関数分割とは見る軸が違うというか直交な感じ、
たとえば関数分割が「条」ならばOO分割は「丁目」かな。
関数分割的な視点も必要なときは多いけど、
逆にそれを優先しないほうが良い場合
Re: (スコア:0)
最近、/.J はいいスルー力を持っているようだ。
#de facto が何語なのかは知らないのでAC
Re: (スコア:0)
オブジェクト指向はよくわかりませんが、
「もしかして英語ネイティブの人って、幼稚園児が話すように
話す/書くとそれがプログラムになってたりするんじゃなかろうか」
と思ったことはあります。
英語から、時制と助動詞取っ払ったものが
コンピュータ言語だったりするんじゃないかと。
あと、日本語だと「名詞+する」となって動きの表現が
あいまいになりがちなところが、動詞の数が多くて、
うまく他人と共有できるんじゃないかと勝手に思ってます。
(あるいはそういう仔細な動詞をほとんどの日本人は知らない)
まったく関係ないですが、個人的にはコメント・文章を
エセ大阪弁(あるいは口語)で書くと「動き」が
うまく表現できるように思います。
# 受け手にちゃんと伝わっているかはわかりません。
Re: (スコア:0)
「それで、この辺をばばーんとでかくしてな、こうぐっぐと押して入れるようにしてや」
「あとあっちの方はずいずいっと潜り込ませて、あとだだだーっと流すてのはどうや」
こんな感じですね、判ります。
Re: (スコア:0)
まさにそういうオノパトペ多用を
「聞こえる化」という言い方で薦めていた人が
どっかのBLOGに居たと思います。
たとえばBTSのチケットとして「画面をもっとがちゃがちゃしないようにする」などといった書き方を許す、というものらしいです。
書類として残すのだったらこれじゃ話になりませんが、
アジャイルのように要求の責任を持つ人(オンサイト顧客)が開発現場にも居るという状況ならば、
「このがちゃがちゃって何?」とすぐに聞くことも出来るし、すぐに答えることも出来る(身振り手振り満載で)ので、
それでOKだ、ということのようです。
また、責任者がそこに居るのならば、その彼に修正物を見せてOKをもらえれば終り、ダメならまた直す、というフィードバックも容易だろうと。
むしろUIの雰囲気などのように「数値化」しにくい面についての改善を求めるとき、
へんに数値化を必須とするルールだとチケットの書きようが無くなる、
という事態が生じるのを避けたいのだそうです。
Re: (スコア:0)
Re: (スコア:0)
分析設計は日本語で十分できるよ。
俺の場合は、別名を日本語として常に英語と日本語の両方を同時に考えて進めることもよくある。
(別名が設定できて、別名表示ができるツールを使う)
問題は、英語にする能力がないことだよ。英英辞書や、類語辞書は必携。
で、それ以前の問題として、どの言語だろうとネーミングセンスみたいなものがある。
名は体を表す。命名は非常に大事。これができない奴は、分析設計に向いてない。
Re: (スコア:0)
>命名は非常に大事。これができない奴は、分析設計に向いてない。
でも、そういうセンスの無い奴や、
そういうセンスの有る人間をむしろ「けむたがる」奴は、
実装現場のみならず上流分析屋においても、凄く多いのがわが国の実情だ。
言葉の微妙な違いを「言葉遊びでしかない」と平気で切り捨てて、
それで結果的に開発を混乱に陥れる、
しかもそんな連中のほうが「人間らしい」と評価されたりするわけだ。
しかも評価する側も言葉の大事さなんて考えてないから、
言葉の違いを無視するという重大な(しかも得てしてその奴がいつも繰り返しがちの)ミスを
ミスだときちんと判定できないのだな。
Re: (スコア:0)
英語関係ないと思うなあ。
「もの」という概念が日本と欧米とで違うわけでもないはずなのだし。
「擬人化」だってどちらの文化圏にも大昔からある考えかただし。
せいぜい違いといえば語順だろうと思います。
で、それはOOPかどうかじゃなく、プログラム言語の文法の問題でしかない。SVOかSOVかの違い。
たとえばLispの亜種として手続き名をリストの最初じゃなく最後に書くというルールにした実装が有ったが、要はその程度の差でしょう。
単語や語順がより日本人(日本語)に近いような「文法」の言語を作れば済むことであって、その言語がOOP言語か否かで特段の違いが出ると