  |
はてなキーワード: oopとは
JavaScript って生き物っぽいって思ったのがきっかけだった。
なんか菌？に遺伝子いれてたんぱく質を生産させるやつ？ Function は菌の細胞膜で prototype は遺伝子で、だから prototype に全然関係ない違う生物の遺伝子を生きてる菌に入れちゃったり。そうすると全然ちがうたんぱく質が生産されたり。prototype にべべーっとコピーして追加するのなんてまさしくそれっぽい。
だってプロトタイプベースって、生き物しかいない世界じゃない？基本的に。インスタンスってのは生き物じゃない設計図があってそれにしたがって出来た生き物がインスタンスってイメージあんだけど。プロトタイプベースの世界にはそんな設計図も生き物じゃないものもないよね？なのにわざわざインスタンスっていうのに何か違和感？ご都合主義的なもの感じる。クラスは型で、インスタンスを実体だとかなんとかって氾濫してるせいかな。多分この辺の用語が JavaScript をわかりにくくさせてる気がする。
僕の感覚では、オブジェクトってのは生き物で、クラスベースってのは神が設計図に基づいて生き物を生産してる世界で、インスタンスベースってのは生き物が生き物を複製してる世界のイメージだ。多分、原始の生物はインスタンスベースみたいな世界で、海の中にうようよしてたんだろうな、とか。
オブジェクトじゃないものは、生き物じゃない死んでるたんぱく質や RNA の破片みたいな。それだけじゃなにもできないみたいな。それだけじゃ命がないから、生き物の殻に詰めるってのが JavaScript のコンストラクタのイメージ。
Perl の bless したらこれはもう命入ったよ生き物だからねっあとは勝手にしてねってのも、Python の名前空間さえあればなんとかなるよねってのも、JavaScript のハッシュさえあれば世界作れるよねってのも、みんなどこか似ている。ちゃんと OOP を理解できてるかは別としてもこの三つはわりとすぐやりたいことができた。昔 Java の本を買ってきて挫折したのにくらべたら、なぜかずっとわかりやすかった。（bless という命名はすごく洒落てる）
全然関係ないけど、Django の日本語リファレンスは何か萌える。ラクダ本の日本語訳はむかつくのに。
プログラミングを始めたばっかりの時は、なんだか難しい用語の意味を理解しないと OOP がわからないと思ってた。それは僕らの住んでる世界とは全然関係のないプログラミングの技術ってやつだと思ってた。
でも多分違う。
世界が動く仕組みさえあれば、あとは作り手に世界の成り立ちを抽象化する表現力さえあれば、世界は勝手に表現されていくし、動き出してく。たまたま僕らの世界はオブジェクトなもので溢れていて、プログラミング言語が進化すれば世界に似るのも当然だろう。いや逆か。プログラミング言語が世界に似てきたから、オブジェクトなんていう世界に似た概念が出てきたってことか。なんだか難しい用語ってのは、その表現の一部分の技術に名前をつけてるだけなんだな、と。例えば何とか歌唱法や何々画法とか何とかレトリックとかパースの取り方みたいなのと同じ。それは表現を理解する手助けにはなるけど、その意味を知る事がイコール表現力をあげることにはならないんだよね。これに気づくのに遠回りしすぎたなあ。
（知識を得るだけで、100% 還元される人もいるかもしれないけど、そんなのは一部の天才だけだと思う。殆どの凡人はそうはいかない。とはいえ、元の錬度が低ければ、コツをいくつか教わるだけでいきなりうまくいくこともある。ただ、それをまるまんま実力だと思うのは、どんな分野でも危険だ。恋愛テクニックやらを必死に読んでる連中が男女間の深い人間関係を上手くやれてるとはちょっと想像できない！）
プログラミングで表現力を上げるにはどうすればいいんだろう。きっと他と同じだろうな。いい表現を沢山味わって、世界をよく観察して、どう成り立ってるかどう動いてるか、私達はそれをどう認知しているのか、考えることかもしれない。漫画家を志す人が美術解剖学を学んだり、優れた画家が絵筆で世界を生々しく描写するように、優れたプログラマは世界のなりたちをプログラムに写し取ったり、世界の仕組みを作る事が出来るのだと思う。
http://anond.hatelabo.jp/20110316202255
デザインパターン編を書いてたら99ブクマだと…。なんだかすみません。
あと増田で書くの初めてで記法がちとわかっていなくて見づらくて申し訳ないです。
＞おもしろい。でもJavaとJSとRubyじゃ同じオブジェクト指向でもまったく違った設計と思想になるのでまとめて説明は難しいかも
言語＝世界として、どんな世界がいいか考えましょうという話に持って行きたかったけど難しかったですね。
＞ASしらないけど classが使えるJSっぽいところみるとASなんですかねこれ
＞@shinout 面白い！けどいろいろ間違ってる！！コード動かしてみいや
それっぽい言語なので動きません。JavaとかASとかそのへんですねー。
その割に一部ちゃんと書いてるのが誤解しそうですね。
＞ OOPを習得したPGとそうでないPGとの生産性の差がドラゴンボールで言うところの戦闘力の差という比喩でたとえるとよい。初心者PGが何人集まってもかなわないところがある。
＞17号と18号が逆
＞セルはis-aはなくhas-aで実装した方がいいような気がする。
セルってチート臭いですよね。くらった技を覚えるブウの設計と、遺伝子を持っているから技が使えるセルの設計をどうするかは議論になりそうです。
＞なんか、むしろ分かり辛くなってると思うけど、心意気やよし！
＞かりやすいんだかわかりにくいんだか
無理がありました。
＞連載はextendされたけど、主人公の継承には失敗したよね
素晴らしいコメント。設計ミスで主役になれなかったのは運用でカバー出来ましたね。
＞セルはクラスの承継よりもオブジェクトのコンポジションの方がいいのか分からない。
http://anond.hatelabo.jp/20110316215156
で突っ込まれてる内容の方がいいかもしれませんね。
でも悟空やベジータは吸収じゃなくて細胞を合成してる？とかなので17号、18号とは別にする必要があったりします。
申し訳ありません…。
http://anond.hatelabo.jp/20100725025127
"どうすればいいか"を教わって、プログラミングが身につく人は多くありません。"なにをやりたいのか"を自分で生み出せないと、詰まってしまうし、なにより楽しくありません。
やりたいことがあれば手段は後からついてきます。これは物作り全般に言えることです。特に学び始めにおいてモチベーションを維持し勢いをつけるのに大事なのは"やりたいことがあるか"、もっと具体的に言うなら"作りたいものは何か"です。これがないと始まりません。それがどうしてもないなら、そういう状況に自分を追い込むのも有効です。仕事でどうしてもやり遂げなければならない状況に追い込まれれば人間 0 からでも身につきます。実際自分がそうでした。
とかく、プログラミングというのは手段さえ知れば、あとはだれがやっても同じ結果が出る生産業だと誤解されがちです。そういう認識で学ぼうとしても楽しくありませんし、本質を掴みにくいので応用が利かなく上達しにくいです。
本質は絵や音楽と同じです。言語を覚えるということは道具の使い方を覚えることでしかありません。音楽の理論や絵筆の使い方を知っているだけで、すぐに素晴らしい音楽や絵ができるでしょうか。殆どの人がそうは思わないはずです。プログラミングもそれと同じです。作りたいものがある人が圧倒的に強いのです。
んー、ここまで読んでも｢やりたいことはないけどとりあえず勉強したい｣というなら、すぐに動くものをつくりやすい言語がお勧めかなあ。
Google App Engine で Python をやるとか。 Python のいいところは、明快で作法にあまり迷わなくていいところです。自分がまったく言語やったことない知り合いにすすめるとしたらこれ。
レガシーではないちゃんとした JavaScript (http://www.crockford.com/javascript/ この辺にあるような) もいいです。ブラウザですぐ動きますし、 Firefox 環境なら本格的なデバッガまであります。 JavaScript は非常に誤解の多い言語ですが、悪いものではありません。 お手軽にグラフィカルなものを扱える、結果がわかりやすいので初心者向けです。それでいて、拡張性が高く、プログラミングに必要な概念、ロジックの殆ど再現できる底力も秘めています。
Perl はレガシーな作法がいまだに見受けられる (Perl って CGI のことでしょ的な解説が未だにある) のですが、初めから strict に慣れて、 CPAN にあるようなスタイルを参考にして、初めから OOP に突っ走るなら今からやってもいい言語です。 CPAN 等のリソースの豊富さとコミュニティの広さが強いです。ただ、懐の広さ、できることの多さゆえに初心者向きではないところもあります。
PHP はお勧めしません。理由は適当に検索してください。 PHP5 でかなり良くなりましたが、逆に言えば 4 と 5 では別言語と言っても良いほどです。古い考え方と新しいスタイルがごったになりすぎていて、かつて同じような状況にあった Perl に比べても、洗練されたスタイルを学びにくいと思います。また、ロジックの面白さに感動するような部分が PHP にはちょっと足りないです。
MMORPG やそのエミュレーターの中には、 Lua を使って AI やマクロやイベントスクリプトなどを組めるものがあります。すぐに結果が出て自分の役に立つものが作れるので、既にその手のゲームが趣味ならお勧めです。こうした用途では、自分の望む世界を構築するために嫌でも物事をモデル化して考えるので、自然と OOP 的な考え方やデザインパターンが身につきます。
VB は簡単に GUI アプリケーションが作れるのでやる人が多いですが、癖が強いし応用がききにくいのでお勧めしません。また、公開されているソースコードが少ないことも学ぶには不便です。
Ruby はそれほどやりこんでないのでコメントはしないでおきますが、悪くはないと思います。
C++ は何をすればいいのか？を聞いてる人にはすすめにくいです。作りたいものが明確にあり、ロジックを見つけることで応用が利く人ならほっといても覚えるでしょう。自分は、必要に迫られて身につきましたが・・・
個人的には、作りたいものがあってそれにマッチしてるなら、関数型言語を最初にやったっていいと思います。一度ロジックを掴み取る能力がついてしまえば、第二第三の言語は猛スピードで身につくので。
作ったものを公開して、人に見せたり使わせたりして、レスポンスを得るというのはモチベーションの維持や上達に非常に有効です。むしろ、早く上達したいなら必須と言ってもよいです。プログラミングの場合はこれがおざなりにされがちです。
絵を上達したいなら、 pixiv を薦められますよね。今下手かどうかは関係ない。上手くなりたい人が沢山投稿してる。歌が上手くなりたいなら、人前で歌う事は避けられない。ニコニコ動画などで公開してる人がいるよね。人の作品をみると刺激をうける。これはすごいパワーだってのはわかると思う。
プログラミングだって全く同じです。なのに、プログラミングは引きこもって一人で勉強する人が多すぎる。絵や歌は公開しても人に害を与えないけど、プログラミングはバグやセキュリティホールがあったら人に害をあたえるかもしれない、といった印象が強いのかもしれません。
それでも、もっとコミュニティに参加したり、作ったものを公開することが学び始めのうちから重視されていいのは事実。そういった面から考えると、バグやセキュリティホールが出来にくく、安全で、危険な動作がしようもない実行環境があり、加えて Web に公開しやすい言語が学びはじめに向いています。
こちらも参考にしてみて下さい
http://d.hatena.ne.jp/Hamachiya2/20090721
http://d.hatena.ne.jp/Hamachiya2/20080131
学校に行けば一人で学ぶよりは後押しや出会いがあるかもしれませんが、”やりたいこと””必用なこと””作りたいもの”が無い限り、殆どの人は身につきません。
また、残念なことに講師にも大変当たり外れが多いです。自分は専門学校にいったことはありませんが、講師の知り合いがいるのでよく学生さんの話を聞きます。結局の所、しっかり身につく人は、家に帰っても色々作りたいものを作って公開したり、著名なプログラマ達のブログを読みまくったり、フォーラムに出入りしたり、ML に入ってたり、 twitter で刺激的な知り合いをつくるとかしていて、そういうところでめっちゃ差がつきます。
学校に行くなとまでは言いませんが、学校いかないで身に付ける人は本当に多いし、学校いって身につかない人も本当に多いということは考えて下さい。
元増田さんがどの言語をやれば・・という方だったので仕方なくこのような書き方になってしまいましたが、作りたいものが既にある人はあまり”どの言語をやるか”には拘らなくてよいと思います。
そんなことよりも、今必用で/気軽に/すぐ結果がわかることをやるのが、始めてのプログラミングには大事。だから本当は、どの言語をやるかよりも何を作りたいのかを先に見つけてほしい。
目の前の意外なところにプログラミングは生かせます。できるだけ身近な、すぐ効果がわかるところからとりかかった方がプログラミングの楽しさにはやく気付けるはず。
みたいな導入口でもいいんだ。
例えば C++ でのプログラミングを初心者が 0 からやるのは難しいだろうけど、既存のアプリケーションのプラグインなら開発のためのテンプレートや目的に近い作例があってコードも短いからそれを改造するところから始められる。需要があるから楽しいよ。
class FizzBuzzProgram{ public static void main(String args[]){ for (int i = 0; i++ < 100; ) { System.out.println(new Number(i).checkMod3().checkMod5()); } } } interface Mod3Mod5Unchecked extends Mod5Unchecked { public Mod5Unchecked checkMod3(); } interface Mod5Unchecked { public Object checkMod5(); } class Number implements Mod3Mod5Unchecked{ private int no; public Number (int no) { this.no = no; } public Mod5Unchecked checkMod3() { return no % 3 == 0 ? new Fizz(no) : this; } public Object checkMod5() { return no % 5 == 0 ? new Buzz() : this; } public String toString() { return Integer.toString(no); } } class Fizz implements Mod5Unchecked{ private int no; public Fizz (int no) { this.no = no; } public Object checkMod5() { return no % 5 == 0 ? new FizzBuzz() : this; } public String toString() { return "Fizz"; } } class Buzz { public String toString() { return "Buzz"; } } class FizzBuzz { public String toString() { return "FizzBuzz"; } }
これマジ？
俺、未経験（もちろん非情報系専攻）で業界に入ってプログラミングやることになって1年くらい経つ。
その間の学習の軌跡はだいたいこんなもん。
実際にはコード書く以外の仕事してる期間も結構ある（半分くらい）。設計考えたりとかアルゴリズム考えたりとか。
でも俺、ギークとかなんとかみたいな変態的プログラマの人たちには全く追いつける気がしないし、わかんないことだらけで俺センスねーなーと思うことしきり。本当に。
「珠玉のプログラミング」っていう本があるけど、あれみたいにビットレベルでコンピュータの原理を最大限活用してパフォーマンスの高いコードを書く、みたいな考え方がさっぱり身につかない。
でもこのエントリ見ると、俺もちょっとは自身もっていいんじゃね？って気がしたわけだ。
でもやっぱりそんなことは無いのかな。
ちなみにデザパタ関連およびOOP関連では『デザインパターンとともに学ぶオブジェクト指向のこころ』っていう本がマジオススメ。感動的にわかりやすい。
巷のPerl Mongerな人たちの間で話題の『モダンPerl入門』を読み始めた。
第1章はオブジェクト指向のトレンドの話で、とても興味深く読んだのだが、同時に「なんでこれPerlで実装せなあかんの？」と疑問に思った。ていうかオブジェクト指向やりたいならJavaやC#でいいじゃん。
継承という基本的な概念もないし、コンストラクタなんかも用意されていない。ゆえに、MooseとかのCPANモジュールを使って実装しなければいけないのだけれど、その分敷居が高くなって初心者には判りづらい。初心者でも現場に投入できるような、強力なオブジェクト指向機構が用意されているJavaやC#といった言語、StrutsやASP.NETといったフレームワークなんかとは全然違う。
私はメインがPHPとASP.NET(C#)という人間で、Perlはバッチプログラムとかクローラの実装とか雑用処理なんかに使っている。PHPは小規模プロジェクトでアジャイルな開発がしたい時、ASP.NETは大規模プロジェクトに呼ばれた時用の懐刀という感じで使い分けている。PerlでWebサービスを作ることももちろん出来るけれども、どちらかというとスピードが優先される開発に用いるものだと思うし、OOPを用いた大規模なプロジェクトにPerlを使おうとする理由がよく判らない。無駄に難しいし、そもそも本書を読めるレベルでPerlを理解している人の頭数がかなり少ないだろうから、実装しても保守コストがやたらかかる。Livedoorやmixiやはてなのような大規模サイトはPerlで動いているようだが。。。
『モダンPerl入門』は内容も書き方も素晴らしい良書だけれど、その辺りが引っかかった。「PerlでOOPを使う理由（APS.NETやStruts+Javaを採用しない理由）」は何なのだろうか？ 私のプログラマーとしてのスキルが低いだけだと思うが、よく判らないので誰か教えてくだしあ。教えてダンコーガイ！
コード書き始めて1ヶ月強ですが、なかなかC++の仕様が把握できません。
今日はポリモーフィッククラスの扱いがよくわからなくてハマッったりしました。
書いたコードは2,3000行くらい。図形処理のアルゴリズムが難しくて相当苦しみました(まだ未完成)。
テストケースをあまりきちんと洗い出してないからこれから困ると思います。
OOP的に正しい設計とか未だによくわからないし…(設計始めたのはさらに1ヶ月前くらい)。
ギークとまではいかないにしても、何とかして「そっち側」に行きたいのです。
スキルを身につけるという意味では、実際どのくらいのタイムスパンを見込むべきでしょうか。
とか、終わってもいないのに増田に書いちゃう集中力のなさも問題です。
高専の化学っぽいところ出て、大学の化学っぽいところに編入して、
東京来て、初めての仕事でPHPで、誰に頼ればいいかもわからず、
使ってた言語？VB4とHSP2でしたが何か。
初めての仕事で学んだこと
その後もいろんな会社で
とか、けっこう酷いことをして、たくさんの人に迷惑をかけましたが、
今ではそれなりにIT土方をやっている。
…という俺から見ると、PHP初心者罵倒は、見るたびに、なんだか恥ずかしさを思い出す。
ああ、明日も仕事だし、勉強するね。うん。みんなごめんなさい。それは全部俺がやった事です。
あれです。
ごめんなさい。
http://anond.hatelabo.jp/20070824010205
確かに。
大規模プログラムならOOPを使った方が大抵は美しくコーディングできるけど、
すごくちっちゃい小物プログラムで、ちょっと小さいことをやらせるだけで大袈裟なクラスを作って処理させたりとかはすごく大袈裟だし、
まあ、道具は選ぶべきだってこった。
将来はOOPでさえも古臭い技術になって、もっと効率的にシステム構築できる時代が来るかも知れないし。
あるいは人間がプログラミングから解放されて、画面の中の小人さんか押しかけメイドさんか増田猫に頼み事をすればやってくれる……時代はまだ先でしょうけど。
しかし、OOPは各オブジェクトの構造や関連に注目した記述となるため、自然言語との親和性が手続き型よりも低い。オブジェクト指向は視覚的なアプローチなのに対し、手続き型言語は言葉による理解。一昔前の言葉で言えば、ランダムアクセスとシーケンシャルアクセス並の違いがある。
OOPが人間界、、、人間の世界観に沿っているのは同意するが、人間の言葉に合わせているのではない。
また、「xxx.doThat()」を羅列しただけのようなプログラムはOOPではない。それは手続き型だ。
ちなみに俺はOOPの利点は、メソッド・変数群の名前空間の整理(大規模プログラムを書いても名前が混乱しにくい)、データのカプセル化(複数の違うフォーマットのデータを同じもののように扱える。多態性)であると思っている。分析との親和性についてはオブジェクトもデータフローもペトリネットも大して差がない。
いや、なんていうか覚え立ての言葉をいろいろ使ってみたかっただけだ、すまん。
OOPが別に間違ってるとかそういうところで抗うつもりも無いんだけどさ、いまさらOOPいわれても正論すぎて面白くね？
とくにプログラマがなんとか指向を前提にプログラムをごにょごにょして声だかにこれが正しいんだ！とする流れは拒否したいな。
何をつくるかが第一プライオリティであって、どうやって実装するかなんて別にどうでもよくね？
何をしていいかわからないうちは型に嵌るのは重要なことだけど、型の優美さを競うほど成熟したジャンルでもないとおもうわけだ。
今のソフトの発展のスピードは石器時代から近代までを３０年ぐらいで一気に駆け上がるぐらいの速度だよね。
ほんの１７、８年前までプログラマーという仕事は厚紙の穴ぼこを手で弄ったりしながらプログラミングしてたんだぜ？
そんな速度のところで、スタイルの美しさを追い求めても意味がないと思うんだ。
近代兵器が出てきたあとも、剣舞とかそういう美はあるよね。
でも、実戦において剣技の美をもって近代兵器に立ち向かおうとするのはあまり実のある話しとは思えない。
手法に固執するほど成熟してないんじゃないの、と、そういう事がいいたい。
そういう点で「絶対」とか、「したほうがいい」とか、総論で言われるとどうなんだろうと異論をなげかけたくなる。
そんなのは現場のコードレビューやコーディング規約レベルで現場レベルでルールとして落とし込めば十分な話しだとおもっちゃうのだ。
てかてかてか、俺しゅみぐらまーだからそんなんで生産性かわらないし。
オブジェクト指向が人間らしい書き方かには疑問の余地があるが、C言語とかでプログラミングしてると必然的に行き着く考え方だとは思う。
オブジェクト指向ではない世界で、自分で設計しながらプログラミングした経験があるとオブジェクト指向の理解って早いんだよな。最初からオブジェクト指向ありきの書き方を教えちゃうと、その必然性が理解できないから、ついていけない人が発生する。
趣味でプログラミングをやっていた人間と、そうでない人間の差はここに生まれる。必要に迫られたプログラミングしか経験していない人は最短距離しか進まないから、試行錯誤の末に先人の叡智と同じ結論に自分で達した人とは、理解の深さが違ってくる。
http://anond.hatelabo.jp/20070615171101
俺は大学四年まで全くきちんとしたプログラミングをやったことが無くて(大学の講義でJavaの超簡単なのを教わったぐらい)で、卒論でプログラミングをしなくちゃならなくて、そのとき初めて Ruby を触った。
Ruby は OOP ですげーんだぜ、とか一部で云われていた時代で、有名なアプリケーションは tDiary ぐらいしかなかった。はじめはクラスとかも解らずに何が何だか。そのとき tDiary のプラグインはクラス使ってないから簡単に書けるよ、というどこかのチュートリアルをみて見よう見まねで。GD という画像ライブラリを使ったら、サンプルをちょっと弄るだけで画像が作れて面白かったんだ。で、それを日記で公開してみた。今見返すとものすごくしょぼいソース。
そのときたまたま Ruby ハカーの方がそのプラグインをリファクタリングしてくれて、クラスを使って抽象化してくれて、初めて OOP をほんの少しだけ理解して、こうやってクラスって使うんだなぁというのを知った。本当に運が良かった。
その後就職して仕事で php ハカーのすごい先輩にいろいろ教えてもらって php を使って基本的な OOP は理解した(PHP を DIS る人が多いけど、プログラミング初心者には良い言語だと今でも思ってる)。これまた運が良かった。
その後またまた Ruby を使い始めたら今までよくわからなかった部分もするする頭に入ってきてホント面白ろくて没頭して。今では一通りのことは Ruby でできるようになった。
プログラミングが解るなら、Rails のソース(トリッキーなことやりまくってるのでつらいかも。ActiveRecord や ActiveSupport はその中でも解りやすい)を読んで、解らなかったら rubygems で興味のありそうなライブラリのコード読んで、あたりが OOP と Ruby 覚えるには手っ取り早いかも。
今なら Rubyレシピブック 268の技 と Rubyクックブック ―エキスパートのための応用レシピ集 あたり読んでおけば良いんじゃないなぁ。
あと今はてダで Ruby を含む日記を書くともれなく ruby-dev な人たちがキーワードからたどって読んでくれるので、解らないことをつぶやいたりすると結構答えてくれるみたい。のではてダ使って勉強日記とか書くのも良いと思うよ。
とあんまり参考にならないと思うけど書いてみた。なんか目的見つけられて、楽しく覚えていけたら勝ちなんじゃないかな。たぶん。
