アカウント名:
パスワード:
当時オブジェクト指向を擬人化のようなもので理解したので今でもあるインスタンスのメソッドを呼ぶのを「〇〇くんに××してもらって……」と言っちゃう
(当時は擬人化理解の弊害について述べた頁もあったはずだけど、最近検索したら見つからないなー)
選択肢の中でデータ構造重視の物ってことでオブジェクト指向に投票しました。「アルゴリズム+データ構造=プログラム」は名著。
これと「ソフトウェア作法」と「プログラム書法」を合わせた三冊が、私のプログラミングのバイブルです。いや、バイブルなんだけど、さすがに40年以上前の本だし、今、人に薦められる本じゃないんだよなぁ。FORTRANな作法・書法に比べれば、Pascalなア+デ=プの方は読みやすいだろうけど。
ソフトウェアから入った人はオブジェクト指向が新鮮に見えたんだろうけどハードウェアとか電子回路を知ってる人はオブジェクト指向のほうが自然な発想だといいます。
素子(オブジェクト)っていう独立して動作するモジュールがたくさんがあってそのオブジェクト達が信号線(メッセージ)で情報交換して回路全体が動くんだからオブジェクト指向なんて言われなくても、そんなの普通じゃね?何がありがたいの?と思うそうです。
某社では、エンジニアの中途採用面接(引き抜き)で、オブジェクト指向をどの程度ありがたがってるかを必ず質問するそうです。その意図は、ソフトウェアしかできない奴か、ハードウェアとかそれ以上のことができる奴か、その力量を見極める為だそうです。
H/Wで継承や合成をやるんですか?
私もこれ。何をどのように表現するかを意識してます。まあそれはつまり、表現したものをどのように取り扱かいたいかということを含むので、オブジェクト指向が一番近い。
確かにプログラムの構造がどうのと色々と考えると言うのは、データ構造を考えるのと一緒の感覚かもしれませんね。
最近のMVC「モデル、ビュー、コントロール」でも、結局はモデルが一番肝な部分だと思っているのですが蔑ろにされがちな気がします。
FORTRANな作法・書法に比べれば、Pascalなア+デ=プの方は読みやすいだろうけど。
では、「Software Tools in Pascal」にしましょう。邦訳は無かったんだっけ?
オブジェクト指向という言葉が流行った時代は持論をぶつ人が沢山いてめんどくさかったな。
# 保守しやすければだいたいなんでも可
objection思考
異議をぐっと飲み込むデスマ御用達なやつですね
Elon思考、Hanlon思考
バカボンのパパ的思考ですね。
# 賛成の反対なのだ
obsession 志向
納期に遅れると爆発して死ぬという強迫観念から火事場の馬鹿力を生み出すやりかた。大抵は30代半ばを前に燃え尽きて転職する。だめなときは頭を下げればよいのさ〜
なにかを勘違いして理解しているようですが、オブジェクト指向って概念ですよ?つまり「持論をぶつ人が沢山いた」のではなくて、皆さん各々が理解に至るまでの道程が違いるのですからそれは必然です。概念を理解するのですからね。画一的な理解になることはないし、もし誰かに説明しようとすれば方向性としては同じであるものの皆が少しずつずれた説明になるのも、その対象が概念なのですから当然そうなります。
逆にい
># オブジェクト指向の問題点は暗黙的にすべてを持ち歩く ry ># ry バナナが欲 ry 、手に入れたのはバナナとジャングル全体を抱えたゴリラ > # -- Joseph Leslie Armstrong
さて ,,, その ,,, 通例としてはそうですがそれをマルチスレッドに例えますと暗黙的に別スレッドの変数へ干渉といったお話になりましょうか
そういった問題を避ける事は可能であれど並大抵のお話ではないという所がご主旨ではあるでしょうが
# 余談的に聞こえるでしょうが# Ruby の所謂 end 地●の発現は ( 上記問題への緩和策としても )# 言語 ( プログラミング言語 ) 仕様レベルで仕組まれていればこその発現でしょう
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
会社に入って最初にやったのがオブジェクト指向だった (スコア:0)
当時オブジェクト指向を擬人化のようなもので理解したので
今でもあるインスタンスのメソッドを呼ぶのを「〇〇くんに××してもらって……」と言っちゃう
(当時は擬人化理解の弊害について述べた頁もあったはずだけど、最近検索したら見つからないなー)
アルゴリズム+データ構造=プログラム (スコア:1)
選択肢の中でデータ構造重視の物ってことでオブジェクト指向に投票しました。「アルゴリズム+データ構造=プログラム」は名著。
これと「ソフトウェア作法」と「プログラム書法」を合わせた三冊が、私のプログラミングのバイブルです。
いや、バイブルなんだけど、さすがに40年以上前の本だし、今、人に薦められる本じゃないんだよなぁ。
FORTRANな作法・書法に比べれば、Pascalなア+デ=プの方は読みやすいだろうけど。
Re: (スコア:0)
ソフトウェアから入った人はオブジェクト指向が新鮮に見えたんだろうけど
ハードウェアとか電子回路を知ってる人はオブジェクト指向のほうが自然な発想だといいます。
素子(オブジェクト)っていう独立して動作するモジュールがたくさんがあって
そのオブジェクト達が信号線(メッセージ)で情報交換して回路全体が動くんだから
オブジェクト指向なんて言われなくても、そんなの普通じゃね?何がありがたいの?と思うそうです。
某社では、エンジニアの中途採用面接(引き抜き)で、オブジェクト指向をどの程度ありがたがってるかを必ず質問するそうです。
その意図は、ソフトウェアしかできない奴か、ハードウェアとかそれ以上のことができる奴か、その力量を見極める為だそうです。
Re: (スコア:0)
H/Wで継承や合成をやるんですか?
Re: (スコア:0)
私もこれ。何をどのように表現するかを意識してます。
まあそれはつまり、表現したものをどのように取り扱かいたいかということを含むので、オブジェクト指向が一番近い。
Re: (スコア:0)
確かにプログラムの構造がどうのと色々と考えると言うのは、データ構造を考えるのと一緒の感覚かもしれませんね。
最近のMVC「モデル、ビュー、コントロール」でも、結局はモデルが一番肝な部分だと思っているのですが蔑ろにされがちな気がします。
Re: (スコア:0)
FORTRANな作法・書法に比べれば、Pascalなア+デ=プの方は読みやすいだろうけど。
では、「Software Tools in Pascal」にしましょう。
邦訳は無かったんだっけ?
Re: (スコア:0)
オブジェクト指向という言葉が流行った時代は持論をぶつ人が沢山いてめんどくさかったな。
# 保守しやすければだいたいなんでも可
Re:会社に入って最初にやったのがオブジェクト指向だった (スコア:1)
Re: (スコア:0)
objection思考
異議をぐっと飲み込むデスマ御用達なやつですね
Re: (スコア:0)
Elon思考、Hanlon思考
Re: (スコア:0)
バカボンのパパ的思考ですね。
# 賛成の反対なのだ
Re: (スコア:0)
obsession 志向
納期に遅れると爆発して死ぬという強迫観念から火事場の馬鹿力を生み出すやりかた。大抵は30代半ばを前に燃え尽きて転職する。
だめなときは頭を下げればよいのさ〜
Re: (スコア:0)
なにかを勘違いして理解しているようですが、オブジェクト指向って概念ですよ?
つまり「持論をぶつ人が沢山いた」のではなくて、皆さん各々が理解に至るまでの道程が違いるのですからそれは必然です。概念を理解するのですからね。
画一的な理解になることはないし、もし誰かに説明しようとすれば方向性としては同じであるものの皆が少しずつずれた説明になるのも、その対象が概念なのですから当然そうなります。
逆にい
Re:会社に入って最初にやったのがオブジェクト指向だった (スコア:2)
># オブジェクト指向の問題点は暗黙的にすべてを持ち歩く ry
># ry バナナが欲 ry 、手に入れたのはバナナとジャングル全体を抱えたゴリラ
> # -- Joseph Leslie Armstrong
さて ,,, その ,,, 通例としてはそうですが
それをマルチスレッドに例えますと
暗黙的に別スレッドの変数へ干渉といったお話になりましょうか
そういった問題を避ける事は可能であれど並大抵のお話ではない
という所がご主旨ではあるでしょうが
# 余談的に聞こえるでしょうが
# Ruby の所謂 end 地●の発現は ( 上記問題への緩和策としても )
# 言語 ( プログラミング言語 ) 仕様レベルで仕組まれていればこその発現でしょう
謝々々々 台湾宮廷料理海味館 名●屋市熊の前二丁目 ( MiniStop 対面 )
Re: (スコア:0)