  |
はてなキーワード: オブジェクト指向設計とは
自称優秀な人物はたくさんいるが、本当に優秀な人物は限定される。これは、自称金持ちはいるけど本当の金持ちは少ないのと同じだ。
たとえば優秀なプログラマーを見抜くには、条件を追加していけばよい。
以下はただの例 (状況に合わせて任意に条件が変わると考えてほしい)
面接の場合は知識を偽装できてしまうが、技術試験筆記試験の場合は偽装ができない。偽装できない方法で基礎があるかテストすれば大体はふるい落とせる。
コンピュータやプログラミングが好きで、その技術で以て社会に貢献したいと考えている人へ告ぐ。
日本のSIerなどに就職しても、給料以外に得るものなどない。だから、就職するな。
もし、コンピュータの技術で人の役に立ちたいと思うなら、オープンソースのプロジェクトに参加したり、本などを書いたりした方が良い（後者は一発当てると生活に不自由しない程度には稼げる）。
まず、世のSIerやPGに就職したところで、実質的に価値のあるソフトウェアを作ることは、まず無いと思っていい。
案件の大半は、コンピュータリテラシーの低い老人向けのクソ下らない業務システムなどだ。信じられないかも知れないが、「FAXと連動する」みたいなソフトウェアは、今も日本中で生産され続けている。
おまけに客自身が、そのシステムで実現したいことを本質的に理解してないから、従来紙の上でやっていたことを、そのままパソコンで行うだけのシステムを作ることになる。
ついでに言うと、SEやプログラマの仕事が設計やコーディング等の知的業務だと思ったら大間違いで、「客の送ってくるエクセルやパワポ資料の体裁を保ちながら、丸番号つきのスクリーンショットを追加する」みたいな下らない仕事が開発と同じくらいある。
あと、「IE9で動かない」とか「Firefoxで見たときだけテーブルの枠線が薄くなる」みたいな、本当にどうでもいい理由で既存のライブラリを利用せずに、フルスクラッチで書こうとする勢力が多数。
あと、日本の職業エンジニアのレベルは本当に低い。趣味でプログラミングを学んだその辺の学生の方がずっとレベルが高い。
まず、職業エンジニアのほとんどは、アルゴリズムとかオブジェクト指向設計とか、プログラムの性能や保守性に関わる知識を全然知らない。ハードウェア、データベース、ネットワーク、セキュリティ等のシステム運用に必要な情報技術の基礎知識を一通り知ってるエンジニアなんて、全体の1%もいない。
そもそも、業務で使っているプログラミング言語すらまともに勉強していない。「Effective ○○」みたいな本に書いてあるようなベストプラクティスをことごとく無視してクソコードを量産する。クソコードはそのプロダクトが死に絶えるまで残り続けて、改修のコストを指数関数的に増加させる。
下請けのゴミにもなると、ググって出てきたコードを意味もわからずコピペして「動かないんですけど」とか言ってくる。それでも仕事はある。
あと、ソースコードをバージョン管理していない会社すらわりと存在する。（「GitではなくSVNを使っている」とかいう意味ではない。文字通りバージョン管理していないのである）
こんなことは別にIT業界に限らないんだろうが、要はレベルの低い人ほど偉そうで、全体の足を引っ張っているわけである。
ここで言うレベルっていうのは、別にJavaやC++などを使いこなせることを意味してるわけじゃない。仕事の内容や目的をきちんと理解して、自立して仕事ができるかどうかだ。
お前んとこの独自フォーマットのエクセル出勤簿をシステムに取り込む機能が本当に必要なのか、よく考えて欲しい。あと、パソコンの使い方レベルの問い合わせを、開発者までたらい回しにしないで欲しい。本当に無駄でしかない。
もし、諸君が「コンピュータの技術を活用して、世の中を便利にしたい」という願望を抱いているなら、絶対に日本のIT企業に就職してはいけない。
日本の企業では諸君の想像するようなわくわくするような開発体験は決して得られない。
諸君が、コンピュータの技術を真摯に学ぶ気があり、最新の技術とハイレベルな開発者から刺激を受けたいのであれば、オープンソースのプロジェクト等に貢献すべきだ。
以下、なぜ日本のIT企業に就職するべきではないのか、理由を述べる。
特にBtoB（法人向けサービス）の開発に顕著だが、日本で就職する限り、作るのはコンピュータリテラシーの低い老人向けのクソ下らない業務システムがほとんどである。
信じられないかも知れないが、「手書きの文書を読み取って、FAXで送信する」みたいな無駄なシステムは、今なお日本中で生産され続けている。
そもそも顧客自身が、そのシステムで本質的に何を実現したいのか理解していないため、従来のやり方をそのままシステム化することになる。
こうして、コンピュータを用いる利点が全くない「アナログ業務をパソコンの上で行うだけ」のクソシステムが出来上がる。
はっきり言って日本の平均的なエンジニアのレベルは、その辺の学生未満である。
アルゴリズム、オブジェクト指向設計、メモリ管理、セキュリティ等のプログラミングの必須事項を十分に理解しているプログラマは、全体の1%もいない。
下請けのカスにもなると、ググって出てきたコードを内容も読まずコピペして、「動いた」だの「動かない」だのとやっているのが大半である。
自動テストやCI等はおろかソースコードをバージョン管理すらしておらず、本番環境へのデプロイは手動で行っており、数万行を超えるコードがmain関数にベタ書きされている等という例は珍しくない。
諸君がいくら最新技術を学ぼうが、仕事で任されるのはほとんど、そういう連中が生み出したプロダクトやツール群のメンテナンスである。
こうしたクソプログラムは、一度作られたら最後、メインプロダクトが完全に死に絶えるまで、死神の様に付き纏う。
日本で職業エンジニアになっても、何の役に立つのか分からんクソシステムしか作らないし、無能の書いたクソコードのメンテナンスで精神病むからやめろ、ってこと。
オブジェクト指向設計 getter, setterを使うなとはどういうことか
そのプログラミングでは、よく複数のデバイスを連携させて動かすよね。
（タイヤ、アーム、センサやカメラユニット、隣にあるロボット等々）
あるデバイスから別のデバイスの中身の状態を見ることは出来ないから、情報のやりとりのために互いにメッセージを送りあうことになる。
これは隠蔽された要素同士のメッセージパッシングに相当するから、まさにオブジェクト指向によるデバイス協調動作設計。
と思ってるんだけど、みんな全然違う設計の仕方してるのかなあ。
もしくは、データも入出力も単一デバイスに集まるシンプルな構成だから一つの神様ユニットが全体を制御できちゃうしオブジェクト指向設計するまでもない、っていうことで、はてなユーザだとそっち系の開発が多いのかね。
ビデオは17時間もあるし、オンライン講座や研修は講師を拘束するわけだからこのくらいの値段になるのはわかる。
でも、内容は「変数とは」「ifとは」みたいな本当に基礎的なことから始まって、最後にアプリを一本仕上げて終了とか、二日間で変数の説明からオブジェクト指向設計まで一気に駆け抜けるような感じ。
たぶん本屋で入門書を2, 3冊も買えば自分で学習できる内容。
身近に自分でネットや本で調べることがいっさいできない人がいるし、以前も増田でこういう講座って自分で勉強できるよなって書いたら「俺はお前みたいに安くないから時間が重要なんだよ。ちんたら時間をかけて本なんか読めるか」みたいに煽ってきた来た人がいたから、やっぱり自分で独学みたいなことが一切できない人っているんだろうなぁ。
俺も、英語が読めなくて金出して日本語の情報を読んでるから、英語で情報収集してる人から見たら「英語読めないやつって・・・」みたいな感じなんだろうけど。
今ふと思ったが、バルーンファイトってオブジェクト指向なゲームだったんだな。
昔から他のゲームとはちょっと違うって思ってたけど、オブジェクト指向だからだったんだ。
参考：2003/03/14(金)21時51分19秒
› › 今ふと思ったが、バルーンファイトってオブジェクト指向なゲームだったんだな。
いや実装段階の話じゃないよ。
そもそもゲームをやっただけじゃどう実装してるかなんて分からないし。
設計の話。
参考：2003/03/14(金)21時57分23秒
› いや実装段階の話じゃないよ。
› そもそもゲームをやっただけじゃどう実装してるかなんて分からないし。
› 設計の話。
教えてあげましょう、オブジェクト指向というのは
参考：2003/03/14(金)21時59分35秒
› いや実装段階の話じゃないよ。
› そもそもゲームをやっただけじゃどう実装してるかなんて分からないし。
› 設計の話。
アホか(;´Д`)
んなこと言ったら先の投稿の「バルーンファイト」を殆どのゲーム名に
置き換え可能じゃないか
参考：2003/03/14(金)21時59分35秒
› さっきから話しているのはオブジェクト指向設計についてだから、こっちについて説明すると‥‥‥
› 例えばRPG。
› あるキャラが走ってきて主人公にぶつかり、「ごめんなさ～い」というメッセージが出る。
› その後、その知り合いのキャラが現れて「ごめんなさいね。この娘ったらいつもこうなの」というメッセージが出る。
› 2人が去った後、主人公の「ちょっと困ったけど、けっこうかわいいかも(゜ー゜*)」というメッセージが出る。
› ‥‥‥でもこれって、イベントNo.112とかいう呼び方で定義されているイベントなわけで、
どうやらRPGツクールの要領で考えているようだな。
エンジン部分とスクリプトで書かれたレベル部分が明確に分かれている。
› どうやらRPGツクールの要領で考えているようだな。
内部の話は良いんだ。
それを言ったら、なんでもかんでもオブジェクト指向にできるし。
参考：2003/03/14(金)23時32分05秒
› › どうやらRPGツクールの要領で考えているようだな。
› › エンジン部分とスクリプトで書かれたレベル部分が明確に分かれている。
› 内部の話は良いんだ。
› それを言ったら、なんでもかんでもオブジェクト指向にできるし。
成果も出せない人間が意味不明なこと言ってるだけにしか見えないよ？
› さっきから話しているのはオブジェクト指向設計についてだから、こっちについて説明すると‥‥‥
› 例えばRPG。
› あるキャラが走ってきて主人公にぶつかり、「ごめんなさ～い」というメッセージが出る。
› その後、その知り合いのキャラが現れて「ごめんなさいね。この娘ったらいつもこうなの」というメッセージが出る。
› 2人が去った後、主人公の「ちょっと困ったけど、けっこうかわいいかも(ﾟーﾟ*)」というメッセージが出る。
› ‥‥‥でもこれって、イベントNo.112とかいう呼び方で定義されているイベントなわけで、
主人公オブジェクトが街オブジェクト.メンバーに入るのを感知した
あるキャラオブジェクトが主人公オブジェクトにぶつかるメソッドを実行し、
その後知り合いオブジェクトが主人公オブジェクトと会話メソッドを実行する際、
「ごめんなさいね。この娘ったらいつもこうなの」というメッセージを
主人公に送る。
衝突フラグと知り合いがいつもうこうなのと言ったフラグがたつと
主人公.考えるメソッド「ちょっと困ったけど、けっこうかわいいかも(ﾟーﾟ*)」が実行される
まぁそうなんだけど、遊んでいるだけで他との違いが見えてくることもあるのさ。
じゃあ、当初の「バルーンファイトはオブジェクト指向的」という話について説明するよ。
このゲームは風船をつけたプレイヤーキャラ2人が、敵キャラの風船をﾊﾞﾝﾊﾞﾝ割っては海の中に叩き落していくゲームだが、
風船が無くなったからといって、やられるわけじゃない。一定以下の位置まで落ちたらやられたことになる。
落ちている間にもう1人のプレイヤーが敵をやっつければ次のステージに進めるし、
落ちている間に敵キャラが魚に食われてステージクリアということもある。
それに低い位置からだったら落ちても復活できる。これは敵キャラに限るけど。
つまり、風船が割れること、落ちることはゲームのルールとは独立しているってわけ。
ちなみに、風船を復活させようとしている間の敵キャラに限って、蹴られたと同時にやられたことになるけどな。
あの魚は水面下に落ちたキャラクターに襲い掛かる。
水面下に落ちてもミスにはならず、ただ魚が襲い掛かる条件になっているだけ。
魚の振る舞いや、水面下に落ちることもゲームのルールとは独立してるってわけ。
あと、ゲームオーバーになっても画面のキャラクターたちが動きつづけることも、オブジェクト指向らしさを感じさせるな。
参考：2003/03/14(金)23時45分19秒
------------------------------------------------------------------------ ＞ 投稿者：ハッカ飴 投稿日：2001/07/01(日)06時54分58秒 › つまるところバルーンファイトが一番面白いゲームだけどな そう！ あれ面白いよ。よくできてる。 海に落ちても助かるかも、魚から逃げられれば助かるっていうのが うまい。 シンプルな効果音も、単純な動き方のルールでもテクニックってもんが 生まれちゃうのがまたいい。 アクションゲームの面白いところってそこじゃない？ レベルアップしたから攻撃力が増えるとかじゃなくて、 プレイヤーのうまさがキャラの強さになるってところが。 あと、風船2個なら天井をクッションにして、とか自分で技を開発できるのがいい。 挌ゲーが面白いのもコンボを開発できるからってのがあるだろ？ 考えなくても進めるゲームはつまらないんだよ。 参考：2001/07/01(日)06時25分50秒 ------------------------------------------------------------------------
ここの所は、今回の例ではいまいち見えづらい気がする。今回の例で複雑になっているのはモデルだけである。ビューがやる事は、「納刀する」「変色した血が飛び散る」イベントをlistenして画面に描画するだけのはず。MVCのイベント機構は、モデル→ビューとコントロール→モデルのメッセージ通知を行うためのもので、モデル同士の通信についてはノータッチ。モデル内での相互作用に、単なるメソッド呼び出しを超えたあれこれが必要なら、DSLを作るなり自前でイベント機構を作るなり好きにして下さい、というスタンスかなあと思われ。
といってもQtのsignal/slotなんかはモデル同士の通信にも使えるわけで、そういう意味で最近のGUIエンジンはMVCの範囲を超えつつある。具体的に「Controllerからの入力もModelの自発的な状態遷移も、同じイベント機構で扱いましょう」というのはMOVEの考え方に非常に近い。
http://blog.neo.jp/dnblog/index.php?module=Blog&action=Entry&blog=pg&entry=3442&rand=9193a
MOVEの考え方からいえば、モデルの責務が吸い出されて単なるデータになってしまうのは、むしろコンセプト通りであるとも言える。
なお、単純な例を超えてRPGの実装を自分が考えるなら、オブジェクト指向設計としては攻撃方法型や特殊作用型（毒とか呪いとか）同士の相互作用を主眼に置いた感じになって、モンスターや勇者は単なるデータに近付いていくだろうなあ、と予想してみる。組んでみないと分からない事もあるだろうけれども。
基金訓練、今は求職者支援制度に名前が変わったみたいですけど、そこの講師をやめたというか、会社ごとやめて転職しました。
何の講師をやっていたかというと、今をときめく(?)Androidの講師です。
転職先にも少しなれてきて、今までのことを振り返って書き留めてみたのですが、せっかくなので発表することにしました。もともと僕だけが読むメモのつもりで書いたので、読みやすい文書ではないですがご容赦のほど。
Androidの講師になるまでは、Javaのサーバーサイドのエンジニアをやっていました。
お客様のところに常駐し、システムの一部ではあるけど、自社メンバーだけで上流行程から担当し、僕はそのチームリーダーでした。
プロパーの方でも仕事がないような状況で、それでも僕らのチームは半年ほどは細々とメンテなどの作業をやっていたのですが、最終的には契約終了になってしまいました。
自社に戻って、何をするのだろうと思っていたら、Androidの講師をやれ、といわれました。
Androidは、暇だった時期に少し動かしてみて、簡単なアプリなら組めるようになっていたのですが、人に教えるほどの技術はありません。しかも準備期間は1週間ほどしかありませんでした。
ビデオ教材と教科書が用意されていて、それに従っていれば最低限の講義はできるのと、最初のうちは純粋なJavaの講義だったので、前半をやっている間に講師はAndroidの勉強をしよう、という、何とも乱暴な計画を立てたのでした。
ほぼ定員いっぱい近い受講者の方が集まったのですが、スキルが全くバラバラです。
JavaやC#,C,C++の経験者がいるかと思えば、人差し指だけでキーボードを打っている方もいます。
講義の最初のうちはコマンドプロンプトを使うのですが、教材には説明がなく、最近の人は知らないだろうと思って説明書を作っていたのですが、まさかコピーペーストのやり方から説明することになるとは思っていませんでした。
それでもやる気のある方はまだましで、どうみても給付金目当てとしか思えない、やる気のない方が何人もいます。
こちらも準備不足の中、生まれて初めて「先生」と呼ばれる仕事を始めることになりました。
基金訓練を始める前は「きちんと技術を教えられるかな」ということばかり気にしていたのですが、講義の運営の方が問題続出でした。
いかにもやる気のない方々は講義中もトイレだ電話だといって抜けてしまう、講義中に当てても「わかりません」しかいわない、かといって質問もしない。当然課題も期限までに出さないので0点しか付けようがません。
そういう方でも、こちらから無理にやめさせたりすることはできないので、何とか講義だけはでてもらっていました。
けど、それがよくなかったようです。
まじめに受講されている方々から「金をもらって受講しているのにあの態度は何だ」「入校条件（キーボード入力）すら満たしていないのではないか」「講義のペースが遅すぎて時間が余る」などの苦情があがり、まじめな方から「就職が決まった」などの理由で辞めていってしまいました。
後に残った、やる気のない方々と、講義を続けていくしかありませんでした。
１度目の皆さんが修了し、2回目の講義を行うに当たって、前回の反省点を改善すべく、いろんな手を打ちました。
最後の手は、会社に怒られるのではないかと正直不安でした。実際辞めていく方が増えたのですが、こういう方は「家業が忙しくなったので手伝う」「体調が悪くなったので療養する」といったもっともらしい（？）理由で辞めていったので会社から怒られるようなことはありませんでした。
むしろ受講生の方の中から、積極的に他の方にアドバイスする方が増えたため、スキルの低い方からも「質問をしにいける人が(講師以外にも)大勢いたのでよかった」といってもらえるようになりました。
今回は、終了後の受講生の方どおしの打ち上げ会に呼んでいただきました。おおむね好評だったのだろうと思います。
未経験だけど、求職者支援制度を利用してプログラマになりたい方向けに、こういう人がプログラマに向いている、こうした方がいい、という条件を挙げてみます。
プログラムの勉強ははっきり言って辛いです。やりたいことが明確になっていないと、なかなか続かないです。
僕は「写経」と呼んでいるのですが、サンプルプログラムを実際に打ち込んでみて、エラーがあれば自分で修正する
という「訓練」をやらないと基礎が身に付かないです。そもそもキーを打つのが苦手、という人はきっぱりあきらめましょう。エラーの原因を自分でぐぐって調べられないような人も、この業界には向いていないです。
いき当たりばったりではなく、最初に手順・段取りを考えてから作業を始める方が向いています。
講義でも、課題作成に何日もかかる課題があるので、何も考えずに適当にやっていると期限までに終わりません。
「きりん、うさぎ、あひる、かば、4つの動物で仲間外れは？」みたいな問題が苦手な人は、向いていないと思います。
単に「読める」ではなく、課題を理解し、既知の技術で解けるものと未知のものに分けたり、繰り返し処理や、複数の似たような処理を一つにまとめるといった作業ができるかどうかです。
さっきの抽象的な考えもそうですが、今までそういうことを意識してやっていない、という方が多いと思います。そういう人は、しんどい思いをすると思います。
「ＡとＢという方法がありますが、ここではＡについて説明します」と講師がいったら、Ｂは自分で調べましょう。習ったプログラムを少し変えてみてどうなるか試してみましょう。それがうまくいかなかったとしても、経験というプラスが残ります。
講師の言うことが理解できたと思ったら、自分で応用問題を考えて、プログラムを書いてみましょう。もしそれが期待した結果にならなければ、どこかで理解が間違っている可能性が高いです。
先ほどの「試してみる」もそうですが、BLOGで実施すると、それをみた方からコメントやアドバイスをもらえることもあります。
いきなり何十行もプログラムを書いて動かなかったとしても初心者はまず動かせるようになりません。少し書いて、動かして動作を確認し、また動かして、を繰り返す方が結局早く完成します。
ちゃんと動く「プログラムの断片」を増やすことは、後で同じようなプログラムを書くときに、「断片」をそのままコピーして使えるようになると言うことです。
一度プログラムを書き始めたら、まずやることはプログラムを完成させて動かしてみることです。プログラムを書いている途中で、同じような処理があるからforで書きたいとか、メソッド化したいとか、思うかもしれませんが、プログラムの初心者はまず動くプログラムを書いて、それができてからきれいに書き直しをした方がいいです。
すぐに解けない課題は、書いて残しておきましょう。書いて整理することで、解けることがあります。今は解けなくても、後で見返して解けることがあります。
特に図に書く、という作業は意識的にやった方がいいです。講師に質問するときも、口で説明するより、図に書いた方がずっと通じやすいことがあります。
自分ができたことで他の人が詰まっていれば、アドバイスしてあげましょう。助けてあげると言うだけでなく、他人に説明すると言う作業は、自分自身の理解をより深める作業でもあります。
もちろん自力で最後まで解くことが重要な課題もありますが、そういうときは講師がそれとなく言ってくれるはずです。
とりあえずアプリを書いたら、同じ講義を受けている人や講師に見せて感想をもらいましょう。
アイコンを書くのが苦手なら、イラストが上手そうな人を見つけて、書いてもらったり、書き方を教わったりしましょう。
訓練を受けているのは同じような環境の方ばかりなので、相手だって同じことを考えているはずです。
紙のノートに講義内容を書いたり、テキストの余白にメモしている人がいますが、それは講義の内容を聞いて即理解できる人が、聞いたことを忘れないためのやり方です。
わからない人は、わかるようになるまで、何回でもノートを書き直した方がいいです。わかったことを継ぎ足して、表現を見直して、時には冗長な表現を削って、自分だけのオリジナルのテキストを作るつもりで書きましょう。当然書くのは紙のノートではなくパソコンをつかいます。
プログラミング以外の世界でもプロや、プロ顔負けの技術を持つセミプロ、ハイアマチュアといった方は自分の作品を世に出すときに恥ずかしがったりしません。不安はあっても、それを上回る意欲を持って、どんどんアプリを書いて、マーケットに載せましょう。
ひょっとすると業界の習慣よりあなたの意見の方が正しいこともあるかもしれませんが、未経験の人が言っても周囲はたぶん聞いてくれません。「私はずっとこのやり方でやってきたしこれからもやる」という意見はひとまずおいておいて、まずは周囲に認めてもらうようにしましょう。
余りに差がありすぎて自信をなくすと逆効果ですが、技術を身につけたければ自分より優れた人から学ぶのが一番です。コミュニティーや勉強会にも積極的に参加しましょう。
GalaxyTabに続いてSⅡ買ってみた。
昔はマトモな動作も危ぶんだKIESだが、バージョンアップでドコまでよくなったか久々に弄ってみた。
UI は劇的に扱いやすく改善されている、、、、というかiTunesのパクりもいい所だ。ついこの前Appleにアイコンパクって訴えられたばかりだというのに、訴訟のネタは尽きない。
参考までに昔のUIは、一種のOSのような外観をしていた。カッコいいが、WindowsのUIガイドラインを無視した設計で、ユーザビリティは皆無。アプリの中でアプリを動かすようなIFをしていて頭を切り替える作業が必要だった。
できればドラッグ＆ドロップで同期出来ればなおよしだが、、、、。
ファイルが転送できている様子か？当時は、重いし止まるし、ファイルの転送もマトモにできないシロモノだった。転送中に止まってたのがなくなったのは数少ない改善点のひとつ。
相変わらずファイル名は化ける。
気になるところいくつか。
などなど、、、、。
で、複数操作のマルチスレッドでどっか競合して落ちていそうな気がする。
オブジェクト指向設計でできてないんじゃなかろうか？
