あえてnewを使ってインスタンスを生成するようにしましょう。そして飲み会の場で好みの男がいたら話しかけ、わざとらしくパソコンを出してインスタンス生成してみましょう。そして「あ～ん！　この言語本当にマジでチョームカつくんですけどぉぉお～！」と言って、男に「どうしたの？」と言わせましょう。言わせたらもう大成功。「プログラミングとか詳しくなくてぇ～！ずっとこのオブジェクト指向言語っていうやつ使ってるんですけどぉ～しっくりこないんですよぉ〜！いちいちnewって書かないといけなくて使いにくいんですぅ～！ぷんぷくり～ん（怒）」と言いましょう。だいたいの男はインスタンスを生成せずに、すべてstaticな関数でプログラムを書く習性があるので、newなんてキーワードは使っていないはずです。

そこで男が「static関数使わないの？」と言ってくるはず（言ってこない空気が読めない男はその時点でガン無視OK）。そう言われたらあなたは「なんかなんかぁ～！最近 SQLが人気なんでしょー!?　あれってどうなんですかぁ？　実行時に一行ずつコンパイルするスクリプト言語と違って、もっとも高級な言語なんでしょ？でもなんかよくわかんなーい。私かわいそーなコ★」と返します。すると男は「あぁあいつね、あいつ俺の友達なんだ、イイヤツだろ」といってくるので、そのまま調子に乗らせておきましょう。

2. プログラムでとにかくstaticを使うとモテる

「ファイル内ローカル関数」や「関数自体で状態を持つ」ことなどができる「static」をとにかく無闇につかうと、一般のstatic男性は「この子はstaticを愛してるんだなぁ」や「え？こんなところにもstatic使えるの？なにこれ？」と思ってくれます。インターネット上ではそのような〇〇おじさんや、××おじさんなど、変なひとがいるので、よいこの皆さんは関わらないようにしましょう。

3. とりあえず男には「えー！なにそれ!?　知りたい知りたーい♪」と言っておく

飲み会などで男が女性に話すことといえばstaticの話やVBの話ばかり。よって、女性にとってどうでもいい話ばかりです。でもそこで適当に「へぇーそうなんですかぁ～？」とか「よくわかんないですけどすごいんですねぇ」と返してしまうと、さすがの男も「この女ダメだな」と気がついてしまいます。ダメ女だとバレたら終わりです。そこは無意味にテンションをあげて、「えー！なにそれ!?　知りたい知りたーい♪」と言っておくのが正解。たとえ興味がない話題でも、テンションと積極性でその場を乗り切りましょう。積極的に話を聞いてくれる女性に男は弱いのです。

いろいろと話を聞いたあと、「staticな関数を使えば、newって書かなくていいんですねー。覚えたぞぉ！　メモメモ！」とコメントすればパーフェクト。続けて頭に指をさしてくるくる回しつつ「キュンキュンキュン！　キュンキュンキュン！」と言って、「どうしたの？」と男に言わせるのもアリ。そこで「うるせぇハゲ」と言えば女子力アップ！　そこでまた男は「オブジェクト指向ってしっくりこないんですよね〜オブジェクト指向って(ry」と連呼して壊れだすので、放置しておきましょう。

4. プログラミングするときはインスタンスを生成できない女をアピールせよ

男とプログラミングするときは、とにかく「あーん！　私インスタンス生成ないんですよねぇ～（悲）」と言いましょう。するとほぼ100パーセント「え？インスタンスなんて生成する必要ないじゃん。static理解せずにわざわざインスタンス宣言してるやつなんて笑っちゃうよね〜」といわれるので、(こいつなんなの・・・)と心のなかで思うだけにして口には出さないようにしましょう。ここでまた100パーセント「どうしたの？」と聞かれるので、うつむいて3～5秒ほど間をおいてからボソッとこう言います。「そうですよね〜staticおじさんカッコイイ〜」と心にもないお世辞を言っておきましょう。

その瞬間、あなたの女子力がアップします。きっと男は「なんて優しい天使のようなコなんだろう！　絶対にゲットしてやるぞ！　コイツは俺の女だ！」と心のなかで誓い、あなたに惚れ込むはずです。そういうやつより上にのし上がったら、そんなことは忘れて好きなだけインスタンスを生成して大丈夫です。「インスタンスを生成できないんじゃなかったっけ？」と言われたら「は？」とか「うざい」や「おまえは一生C言語でもかいてろ」と言っておけばOKです。

Permalink | トラックバック(0) | 02:45

2011-03-19

■ドラゴンボールで学ぶオブジェクト指向Z

これは http://anond.hatelabo.jp/20110316202255 の続編です。

GTをやる前に改を書いてくれている人がいてとてもしっかりした内容なのでちゃんと勉強したい人はそっちを見てね！

d:id:ryoasai:20110317 - ドラゴンボールで学ぶオブジェクト指向　改 | 達人プログラマーを目指して

またオブジェクト指向については

d:id:m-hiyama:20080109 いまさらながらだけど、オブジェクトとクラスの関係を究めてみようよ | 檜山正幸のキマイラ飼育記

がとても詳しいです。合わせて読むとかなりしっかりと理解出来ると思います。

変な書籍を買うよりこちらがオススメです。

はじめに（いいわけ）

ホットエントリに行くとは思っておらず、皆様ありがとうございます。

「ドラゴンボールをオブジェクト指向にする」というコンセプトではなく、「オブジェクト指向を（無理矢理）ドラゴンボールで説明する」という遊びだったので

プログラマーの方々にはツッコミを受けてしまいましたがここは遊びだと思って楽しんで下さい…。

ドラゴンボールは小さい頃から大好きでしたが流石にうるおぼえ過ぎました。

専門家の方々からも厳しいツッコミを受けました。

それはさておき「説明する題材を決める→好きな漫画から無理矢理当てはまりそうな例を考える」という思考実験なので、気が向いた方は色々考えてみると楽しいと思います。僕は楽しかったです。

・ジョジョの奇妙な冒険で学ぶオブジェクト指向

　スタンドとか波紋法とか色々面白そうです。

・ジャニーズで学ぶオブジェクト指向

　これは難易度が高そうです。

・BLで学ぶオブジェクト指向

　継承＝誘い受け、移譲＝ヘタレ攻めだと思います。

結論

やっぱりドラゴンボールで例えると分かりやすいな！

無理がある！

ドラゴンボールで学ぶオブエジェクト思考Z ドラゴンボールで学ぶデザインパターン

デザインパターンとはドクターゲロが考えた「こうやって設計すれば色々捗るぞ」という例のことです。実際はGoFという人たちが考えたもので23個のよくあるパターンに名前を付けて整理してくれたわけですね。

23個の中にはブルマさんですらわからないものが多いので（さすがドクターゲロですね）良く使う、代表的な物をいくつか紹介します

Singleton パターン

Singletonは世界に一つだけしか存在出来ないようにする方法です。

balls = new DragonBalls(); //これでは誰でもドラゴンボールを作れてしまう！
balls.callShenron();

クラスの中にはいくつかのメソッドがありますが、簡単に言うと外から呼べるもの、外からでは呼べないものの

二種類があります。そうやってメソッドを保護することで世界の崩壊を防ぐわけですね。

基本的な戦闘力をアップさせるには本人の努力が必要になり、外から簡単に挙げられてしまうとジャンプの三本柱が外れてしまいます。

（某漫画などは努力しなくともあがったりしますが）

ただナメック星の最長老や界王神などはかなり偉いので、本人の才能を引き出すことが可能でした。

現実には思いつきのような仕様を後から言われることが多々あります。困ります。

//地球上にひとつだけ存在するドラゴンボールをつくろう
class DragonBalls{
	private DragonBalls(){
	      //ドラゴンボールを作れないように生成メソッドを保護します。
	}
	static function sagasouze(){
		static singleton_dragonball;
		//ドラゴンボールを生成。
		//DragonBallsクラスの中なので、保護してある「new DragonBalls()」を呼べます。
		if(!singleton_dragonball)singleton_dragonball = new DragonBalls();
		return singleton_dragonball;
	}
}

これで界王神から怒られることもありませんね。

プログラマーは神なのでドラゴンボールを作れます。

Proxy パターン

何かの処理を行うためにProxy、代理人を立てる設計です。

地球のみんなは地球語しか話せませんが、ナメック星にいるクリリンを通して願いを叶える必要があります。

クリリンももちろん地球語しか話せませんが、ナメック語を話せるデンデがいるため、地球のみんなは願いを叶えることが出来ます。

class Kuririn{
     private dende = new Dende();
     
     function request( wish1, wish2, wisth3){
		this.dende.request(wish1);
		this.dende.request(wish2);
		this.dende.request(wish3);
     }
}

kuririn.request(
	"ピッコロを生き返らせてくれ",
	"ピッコロをナメック星へとワープさせてくれ",
	"ナメック星にいる孫悟空とフリーザ以外を全員地球へとワープさせる"
);

この場合のメリットはデンデが何をやっているかクリリンをプログラミングした人が知る必要が無いということです。

デンデを通して願いと伝える実装だけ行えば大丈夫です。

地球の人はナメック星にいるナメック星人が「デンデ」であることを知る必要もありません。

それでも願いは叶うんです。

本来であればデンデやクリリンは願いが叶うのを待つ必要がありましたが、地球の人は一気に伝えることが可能なように設計しました。

それでないと不便ですからね。

//デンデクラス。ナメック星人は英語でNamekianらしいです。
class Dende extends Namekian{
	function translate(word){
		namekian = *****//ナメック語に翻訳します。
		return namekian;
	}
	function request(wish){
		static polunga;
		if(!polunga){
			polunga = DragonBalls.spell("タッカラプト ポッポルンガ プリピット パロ");
		}
		polunga.ask(this.trasnlate(wish));
	}
}

Template Method

大まかなアルゴリズムだけ決めておいて、実装はサブクラスに任せる設計がTemplate Methodです。

ナメック星に行く方法を考えた時いくつかの方法がありました。古い宇宙船を探してきて直して載せて…っていちいち書くより同じメソッドでナメック星に行けたほうが便利ですね。

abstract class WayToNamek{
	abstract function prepareSpaceShip();
	abstract function launchSpaceShip( ship ) ; 
	function gotoSU839045YX( people ){
		ship = prepareSpaceShip( );			//船を修理します
		ship.load(people);					//人を載せます
		this.launchSpaceShip(ship);	//船を出発します。
	}
}

ナメック星に行く方法を定義したので「ブルマ、クリリン、悟飯」組と「悟空」をそれぞれナメック星に連れて行きましょう。

way = new WayWithKamisamaShip();
way.gotoSU839045YX( buruma, kuririn, gohan );

way = new WayWithSaiyajinShip();
way.gotoSU839045YX( goku );

と簡単に方位SU83、距離9045YXまで乗員を連れて行くことが出来ます。

二つの方法を実装します。神様の船を修理して行く方法と、サイヤ人の船(悟空が乗ってきた船)で行く方法の二つです。

//神様の船で行きます。
class WayWithKamisamaShip extends WayToNamek{
 	function prepareSpaceShip(){
 		return new KamisamaShip();　//船を準備します。神様の船を使います。
 	}
 	function launchSpaceShip(ship){
 		ship.inputByVoice("ナメック星に出発");	//
 	}
 }
 class WayWithSaiyajinShip extends WayToNamek{
 	function prepareSpaceShip(){
 		return new SaiyajinShip();      //船を準備します。サイヤ人の船(フリーザの船？)を使います。
 	}
 	function launchSpaceShip(ship){
		//audio = new HighSpecAudio();
 		//ship.setAudio(audio);
 		ship.turnOnCenterButton();	//真ん中のボタンを押すだけ
 	}
 }

元になる船も違いますし、発射の仕方も違いますが同じ呼び出し方が出来ます。

オーディオの位置が決まりませんでしたが、今回の運用では不要とのクライアントからのご意見でしたのでだったので

せっかく用意したオーディオも無駄になりましたが、コメントアウトしてあります。

他のパターン

他にもまだまだあります。のんびり紹介していこうと思います。

ではでは。

Permalink | トラックバック(1) | 02:03

2011-03-16

■「ドラゴンボールで学ぶオブジェクト指向」のクロージャに関して

http://anond.hatelabo.jp/20110316202255 - ドラゴンボールで学ぶオブジェクト指向

また、ポイポイカプセルのように技を塊にして色んな人が使えるように出来ます。
var shotKamehameha = new function(){
	//かめはめ波を打ちます。
}

noumin.kougeki = sendKamehameha;
buruma.kougeki = sendKamehameha;

noumin.kougeki();  //カメハメ波がでます。
このような仕組みをクロージャと言います。クロージャはクロージャの中に記述することも出来ます。

って書いてるけど、クロージャってのはそういうものじゃないよなぁ、と。まあファーストクラスの関数オブジェクトっていうところはあってるけど、それだけでクロージャと言えるのかというとちょっと違う。

"a closure is a first-class function with free variables that are bound in the lexical environment." (Closure - Wikipedia) とあるように、関数内の変数がレキシカルスコープに結び付けられているようなものがクロージャなのである。 JavaScript で例を書くなら、次のようになる。

// クロージャを返す関数
var getClosure = function getClosure() {
    // クロージャからアクセスされる変数
    var counter = 0;
    // クロージャ
    var closure = function closure() {
        return counter++;
    };
    return closure;
};

// クロージャを取得
var closure = getClosure();

// クロージャを実行
closure(); //=&gt; 0
closure(); //=&gt; 1
closure(); //=&gt; 2

匿名ダイアリーで大なり記号とか書くときってどうしたらいいんですかね... ">" ってなっちゃう

Permalink | トラックバック(0) | 23:11

■ドラゴンボールで学ぶオブジェクト指向にもういっちょツッコミ

http://anond.hatelabo.jp/20110316202255

http://anond.hatelabo.jp/20110316215156

http://anond.hatelabo.jp/20110316224648

noumin = new Hito();

noumin.kougekiKuwa = new function(){

//戦闘力たったの5…ゴミめ！

};

noumin.shotKamehameha = new function(){

//な、なんだと！？

};

これが JavaScript だとして, 気法的には間違ってないけど, これだと Function ではなく Object が代入されるので, さすがに勘違いだと思います.

noumin.kougekiKuwa = function () {

// こういうこと ?

};

あと, ドラゴンボールあまり知らない.

Permalink | トラックバック(0) | 22:55

■

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号とは別にする必要があったりします。

＞その他残念とかダメとか誤字とかのコメント

申し訳ありません…。

Permalink | トラックバック(2) | 22:46

■ドラゴンボールで学ぶオブジェクト指向にツッコミ

http://anond.hatelabo.jp/20110316202255

亀仙流やつ鶴仙流など、世の中にはいくつかの流派があり、それぞれ
カメハメ波やドドン波、舞空術などの技（メソッド）がある。
実際に技を使う場合、技を覚えているZ戦士（インスタンス）が必要。

クラス = 流派

メソッド = 技

インスタンス = Z 戦士

というのはおもしろいと思うし, 例えばゲームを作るなら実際にそういう実装になると思う.

例）セルを作りましょう。
class Cell extends Goku,Veget,Picoro,Tenshinhan,Kuririn{
....
}
cell_inst = new Cell();
cell_inst.shotKienzan(); //Kuririnをextendsしているので気円斬が使えます。

しかし, ここではクラス = Z 戦士になってしまっているので, 混乱を招くだろう.

むしろ, 「JavaScript における prototype」に絞って説明するのはどうだろう.

(ついでに「撃つ」の現在形は shot でなく shoot ですね)

var Goku = function () {};
Goku.prototype.shootKamehameha = function () {
  console.log("波!!!");
};

var goku = new Goku;
goku.shootKamehameha(); // 波!!!

var Gohan = function () {};
Gohan.prototype = new Goku;

var gohan = new Gohan;
gohan.shootKamehameha(); // 波!!!

そしてセルによる吸収は, 動的な継承として考えるのがより自然だろう.

var Goku = function () {};
Goku.prototype.shootKamehameha = function () {
  console.log("波!!!");
};

var Vegeta = function () {};
Vegeta.prototype.shootBigBangAttack = function () {
  console.log("ビッグバンアタック!!!");
};

var Cell = function () {};
// 吸収メソッド
Cell.prototype.absorb = function (target) {
  for (var method in target) {
    this[method] = target[method];
  }
};

var goku   = new Goku;
var vegeta = new Vegeta;

var cell = new Cell;
cell.absorb(goku);   // 悟空を吸収
cell.absorb(vegeta); // ベジータを吸収

cell.shootKamehameha();    // 波!!!
cell.shootBigBangAttack(); // ビッッグバンアタック!!!

そして次にクロージャの使用例として挙げられた次の例.

例）連続エネルギー波
var shotRenzokuEnergy = function( count ){
	var shotEnergy = function(){
		//エネルギー波を放ちます
	};
	for(var i=0;i&lt;count;i++){
		shotEnergy();
	}
};

この実装では, shotRenzokuEnergy を実行するたびに shotEnergy が毎回定義されてしまい, 非効率である.

以下のように書き換えることで, shootEnergy の定義は, shootRenzokuEnergy の定義時の 1 回のみとなる.

var shootRenzokuEnergy = (function () {
  var shootEnergy = function () {
    console.log("エネルギー波!!!");
  };

  return function (count) {
    for (var i = 0; i &lt; count; i++) {
      shootEnergy();
    }
  };
})();

shootRenzokuEnergy(10); // エネルギー波!!! x 10

Permalink | トラックバック(2) | 21:51

■ドラゴンボールで学ぶオブジェクト指向

オブジェクト指向の基本

亀仙流やつ鶴仙流など、世の中にはいくつかの流派（＝クラス）があり、それぞれの流派にかめはめ波やどどん波、舞空術などの技（メソッド）がいくつかあります。

実際に流派にある技を使う場合、技を覚えているZ戦士（インスタンス）が必要になります。

例）亀仙流を覚えた孫悟空を使ってかめはめ波を放って敵を倒す
goku = new KamesenRyu("goku");
goku.shootKamehameha(teki);

Z戦士によっては複数の流派の技が使えたり、自分の技を人に教えることが出来ます（継承）。

また悟空とクリリンのように同じ流派でも同じ技で違う性能を持っていたり、オリジナルの技を持っているなどの違いがあります。

クラスはセルを作るためのZ戦士達の遺伝子情報と言っても良いかもしれません。

例）セルを作りましょう。
class Cell extends Goku,Veget,Picoro,Tenshinhan,Kuririn{
....
}
cell_inst = new Cell();
cell_inst.shootKienzan(); //Kuririnをextendsしているので気円斬が使えます。

世界の成り立ち

世界（プログラミング言語）によってはただの人を後付でZ戦士にすることが可能です。

(JavaScriptやRubyなど）

noumin = new Hito(); 
noumin.kougekiKuwa = function(){
	//戦闘力たったの5…ゴミめ！
};

noumin.shootKamehameha = function(){
	//な、なんだと！？
};

農民がいきなりかめはめ波をうつようになったら危険ですね、危ないです。

このように後付でメソッドを追加出来るタイプは危険性を含んでいます。

クラスとインスタンス

http://anond.hatelabo.jp/20110316204446

インスタンスなのかクラスなのかはっきりしろよ・・・

セルを作るならＺ戦士（インスタンス）を継承しなきゃならんぞ

とても良いつっこみが来たので追記します。

前半部分ではZ戦士をインスタンスとしましたが、セルを作るにはZ戦士がインスタンスでは出来ないので

なのでZ戦士それぞれをクラスという形に再定義しました。

何をインスタンスにして、何をクラスにするかが「設計」なんですね。

何がインスタンスで何がクラスか、加えて説明します。

セルの第一段階ではGokuなどのZ戦士の遺伝子があれば作ることが出来ました。

cell_inst = new Cell(); //このセルは第一段階

でも第二段階以降は人造人間17号、18号が必要でしたね。

cell_inst.absorb(17gou); //第二段階に変身
cell_inst.call18gou();
cell_inst.absorb(18gou); //最終段階に変身

class Cell ....{
   function call18gou(){
        if(!this.17gou)return error(); //17号を吸収していないと失敗する
        this.17gou.speak("＊＊＊＊略＊＊＊＊＊ドクターゲロ様＊＊＊＊略＊＊＊＊");
   }
}

この場合、17号と18号はそれぞれインスタンスです。

17gouを吸収したので、17号の声で18号を呼ぶことが出来るようになりました。

でもドクターゲロ「様」って言ったのでセルだってバレバレですね。

細かいセリフは忘れたのでどなたか資料を下さい…。

追記

コメントへのレスを追加。

http://anond.hatelabo.jp/20110316224648

追記２

クロージャについてちゃんと書こうと思って挫折。どなたか良いアイディアを下さい。

変数のスコープを解説する必要があるかなと思ったんですがオブジェクト指向からは外れるような気がします。

エネルギー波→連続エネルギー波がどこかに使えそうな気がしましたが、気のせいだったぜ…

追記3

続編書きました。 http://anond.hatelabo.jp/20110319020332

Permalink | トラックバック(6) | 20:22

2011-02-26

■http://anond.hatelabo.jp/20110223195508

「プログラマー」と名乗っている人をあんまり信用しないほうがいいというのはよく言われる話だが、最近そのことを痛感している。今やってる仕事の一環として、「ほかのプログラマーにプログラムを書いてもらって、それをレビューする」という作業があるのだが、この「ほかのプログラマーが書いたプログラム」というのがひどい。クズみたいなプログラムばっかりだ。

物心ついた頃から不可解で仕方がなかった

たいしたプログラムも書けないそのくせに威張り散らしてる

ってな、黒夢の『C.Y.HEAD』という曲の歌い出しですけど、最近この部分がぐるぐるぐるぐると頭を回るものだよ。

ええ、わかってますよ。仕事相手の悪口を公的な場で言うなんて、問題があるって言うんでしょう。まあ、それもそうなんだけど、たいしたプログラムも書けないくせにプログラマー名乗ってる奴らに本当に腹が立つからせいぜい堂々と書きますよ。

「忙しくってコードの質が下がってる」っていうような事情もあるでしょうが、まともに納品が出来ないなら仕事なら受けるべきでないわけだし、ビジネスの世界は「結果責任」を負うものですから、「事情」なんてのは知ったこっちゃないね！

……っていうふうにね、「仕事」というのは基本的に「事情」を無視するものなんですね。だから基本的にはあんまり僕は「仕事」が好きじゃない。とはいえ、今いっしょに働いている人たちはかなり「事情」というものを意識していて、おかげでそれほど辛くはないんだけれども。ただ「ほかのプログラマー」みたいな、外部の人たちは、事情を共有することができないので、「あー！クズみたいなコード送ってきやがって！」ということにしかならない。「事情」を共有できるような、近しい距離の人たちとのみ、仕事をしていたいものですよ。

で、そのコードがどういうふうにダメなのかというと、主に2つの側面がある。

【１】文法が正しくない、プログラムが読みづらい

【２】ソフトウェアの目的が意識できていない

【１】はもう、そのまんま。文法がおかしいとか、同じ様な処理をコピペで5回かいてるとか、１メソッドが長すぎる上に変数が"hoge"とかでわかりにくく、意味を取るのに困難があるとか。「こんなプログラムに金を払わなければならないのか……」と思うとめまいがする。何せ、それを「まともなプログラム」にレビューするのは僕なのだ。で、その作業に対してお金は一銭も入ってこないのだ。

不具合・先祖返りなんかは誰にでもあるミスだし、それを点検するために僕がチェックしているわけなので、そのあたりはいい。しかし文法の狂っているプログラムを修正するというのは、時には全体を書き換えなくてはならなくて、非常に労力である。それに、受け取ったコードは「ほかのプログラマー」さんの「成果物」であるので、あまり手を加えすぎるわけにもいかない。それが「仕様書」をもとにしたコードの場合、あまり修正するとクライアントに「自分はこんなこと言っていない」と思われてしまう可能性もある。だいいち、こんな作業にあんまり時間をかけたら、ほかのもっと大切な作業をする時間がなくなってしまうのだ。こういった様々な事情を考え合わせ、うまいことバランス取りながら、修正の妥協点を探していくわけだが、これはとてつもない頭脳労働である。疲れる。

【２】は例えば、「バリデートチェック」のためのコードなのに、「intは2バイト」ということばっかり書いて来るとか。「intは2バイトはわかったけど、いつからバリデートチェックになるのだろう」と思って読み進めても、最後までintは2バイトしかチェックしていない。依頼主であるから SIerは、そんなプログラムに金を払いたがるだろうか？

もっと具体的な例。ゲーム会社が、「我が社のキャラクタ版権を利用して、凄く売れるSNS ゲームを作ってくれ」と依頼してきたとする。プログラマーが打ち合わせに行くと、企画者は「動的フラッシュも使って、１００万ユーザーが遊べる。。。」という話を延々とする。プログラマーは「了解しました」と言って安請負する。そのプログラムはメイン処理だけで１０００行というもので、memcachedの「mem」の字もないし、「オブジェクト指向」といった概念も勿論ない。これでは仮にSNS ゲームがリリースされたとしても、１００人さえも遊べない。

このくらいならマシなほうで、ひどいのになるとフリーランス会社から紹介されたプログラマーで、「SQLはselect文くらいしかやった事がない」とか平気で送りこんでくる。たった一人で。

また、意味のないコメントも多い。ループ処理に、「イントのiに３を代入する」と書いて、何の意味があるのだ？せめて「処理速度改善の為にIntegerは使わずにプリミティブのintを使う！」というふうに書くのが本来だと思う、まぁ嘘なんだけど。だって、そんなコメントみて、「なるほど」って誰が思いますかね？

コメントには必ず「目的」というものがあって、次にソースを読む人は処理の概要を知りたいのだから、「プログラム」をそのまんまコメントにしてもダメなんですよ。そういう単純で、最も重要なことが意識できないで、どうして堂々と「プログラマー」なんて名乗れるのか知らん、と思うぜ。

一番、腹が立つのは「偽SE」ですね。「プログラムはだれでもできるでしょ、重要なのは業務知識でしょ！」みたいなのが偽SE。こういうのを本当に思っているのがいる。業務の画面遷移さえ理解してないSEがだよ。

上の例はさすがに大げさでも、「僕は、プログラムが好きでソフト開発者になりました」とか言ってまともにプログラムが書けない奴は、頻繁にいる。自分でサーバ建てろよ。自分で簡単なサービスつくる事もできないなら、向いてないから辞めてしまえ。

「オレはサーバエンジニアじゃないからコマンド打てない」みたいなね。

世も末だ！

ここに挙げたのは「最低限」のことで、「より読みやすく」「より自然に」「より美しく」というところを、自分の能力の限界まで突き詰めてこそ、プロってもんじゃないんかね。もちろん時間や諸々の事情と相談してのこととはいえ、「26歳の若造が吐き気を催すような拙いプログラム」を送ってくる、30代40代のプロプログラマーってのはいかがなもんでしょう？

身の程を知れというか。

なんでプログラム書けない人がプログラマーなんかやってんだろ？

んで、なんでそういう人に「仕事」があるんだろうか？

世の中ってのは本当にわからんもんです。

身の程を知れよ。

自分の欲望ばっかり考えやがってね。

Permalink | トラックバック(3) | 17:45

Permalink | トラックバック(2) | 13:12

2011-01-15

■http://anond.hatelabo.jp/20110115205136

ありがとうございます。

パタヘネは(ヘネパタも)読んだことないですね…。

プログラム自体を好きになって、好きを原動力に色々やれるのが一番理想的なんですけどねえ。

原理原則系の本は、SICPを途中まで読んだとか、コードコンプリートとか、アーキテクチャ系だとCODEとかの啓蒙書に近いのを読んだくらいですかね…。

あとオブジェクト指向の本は結構読みましたね。デザパタを暗記するとかは無理ですが、原理的なところはだいぶ理解してると思います。

（言語仕様とかと違って、ある程度抽象的なので理解しやすいですね。使う頻度が高いというのもありますが）

他にも細かい勉強は色々齧ってますが（プログラミング言語を作る、という本で再帰下降パーサの辺りまでやったりとか）、いかんせん根本的に興味がないのですぐ忘れますね…。

文字列処理云々も、K&Rとか読んだときに一通り勉強してるはずですが、すぐ忘れます。

上っ面だけでなく原理が重要というのはある意味その通りだと思いますが、自分にとっては上っ面の細かい仕様とかが一番苦痛なのが辛いところです。

結局実務では上っ面が必要ですからね。できればpython辺りで全て済ませたいですが、すぐ処理効率だのなんだのといった面倒な話になりますね。

生きるの辛いです。

いや、えーと、この話に関しては、ガチプログラマの方々がどういう価値観で人を判断するのかとかが良くわかってとても為になってます。

ほんと、分散環境で大規模データ処理だの、高速ネットワーク通信だの、ガチプログラマが大活躍のこのご時勢、当分続きそうだと思ってます。

時代の流れ、ニーズの変化に応じて柔軟に対応できるのが本当に優秀な人なんだろうと思いますが、自分にはなかなか難しいですね…。

多分、「魔法」を連呼してた増田の方が自分より向いてると思います。

Permalink | トラックバック(1) | 21:27

2010-12-12

■http://anond.hatelabo.jp/20101211160604

Perlで動いているのは置いといても確かに URLはダサいわな。

コミュニティのトピックなんかも、アドレスに「comment_count=**」とか「comm_id=**」みたいに余計なのがくっつくんだよね。

あれでアクセス統計とか取ってるんだとしたらかなりバタ臭い印象を覚える。

http://anond.hatelabo.jp/20101211154652

Perlは今でもメジャーな言語の一つだが。

とはいえ、PHPと双璧をなすとは言い難い位にかつての勢いなくなっちゃってるよね…。

CPANとか見ても、もう何年も更新止まってるようなのが大量にあるし。

オブジェクト指向も後付のせいか何となく記述が不格好だし。

Permalink | トラックバック(0) | 17:04

2010-11-22

■C言語すら知らなかった云々の記事がちょっとひどい

http://www.lastday.jp/20 10/11/22/objective-c

早速Objective-Cとやらを勉強しようと思ってググってみたら、Objective-CはC言語の拡張なので先にC言語を学ぶ必要があるという驚愕の事実が発覚！

ググる前に公式ドキュメント読もうよ。

この文書はC言語については解説されていないため、C言語にある程度慣れていることが前提となります。しかし、それほど熟達している必要はありません。Objective-Cによるオブジェクト指向プログラミングはANSI Cの手続き型プログラミングとはかなり違っているので、熟達したCプログラマでなくても、さほど不利にはなりません。

　　

Objective-C プログラミング言語　日本語版

http://developer.apple.com/jp/devcenter/ios/library/japanese.html

Cの知識があるに越したことはないけども、どこまで必要かという話になるとごにょごにょ。

少なくとも、Objective-Cを公開している連中が、"Cの手続き型プログラミングとはかなり違う"と言っているのだから、C言語的なコードの流れには（あんまり）ならない（はず）。

それより、フレームワークの扱いに慣れることに重点を置いたほうがいいんじゃないかな。

苦Cで言うところ、文字列やら、ファイルの取り扱いあたりになってくるとかなり微妙で、出来る限り言語機能やフレームワークに任せたい。

ポインタはそりゃ、Python使いが見たら発狂するんじゃないかってぐらいポインタ演算子が出てくるけど、オブジェクトインスタンスは全部ポインタなんだから、いっそ気にしなくていいんじゃない？　それとも関数ポインタとか使いたい？　きっとデバッグが大変だよ。

YouTubeやVimeoで『Xcode tutorial』で検索すると大量のiPhone プログラミングのチュートリアルが無料で視聴可能です！

※動画は全部英語

公式の「iOS　アプリケーションチュートリアル（日本語版）」を読んだ上で言っているのであれば、どこの誰が作ったかも分からない英語の動画が、アップル公式の日本語ドキュメントより優れている点を挙げた上で、その動画のURLを示して欲しい。

英語なんて分からないよ。

初心者にオススメです。この本を読めばiPhoneアプリ自分でも作れるかもしれないと思えるようになります！

オススメってことは必読じゃないのかな？

3.初期投資

Intel Mac + iPhone or iPod Touch + 10,800円

ここから、開発者プログラムの参加費用$99（¥8000程度）を差っ引くと、一冊分しか残らないから、下の方で紹介されてる本が必読なんだろう。

たのしいCocoa プログラミング[Leopard 対応版]

初心者にわかりやすくObjective-Cの事が書かれています。必読です！

こっちが必読？

内容全く知らないで発言するけども、書評を見てみると、Snow Leopardに対応していない旨が書きこまれていて、多少不安。

流行りに乗ってMacbook Airを購入した人は、大抵Snow Leopardのはず。

記事には、"二ヶ月前"からとあるので、少なくとも記事を書いた人はMacbook Airではないのだろう。

自分のアプリの必要な部分だけを勉強すれば、それだけリリースも早くなりますしモチベーションも下がりません。全部網羅しようと思うと開発自体を頓挫しかねません。

遅延評価勉強法の考えで行くと、C言語を先に勉強する必要はなかったと思うけど、どっちなんだろう。

その辺も遅延で気付いたのかな。

英語力がなくてもアプリは作れますが、英語がわかると公式ドキュメントや先にあげたYouTubeのチュートリアル動画も理解できるので簡単な英語くらいはできる方が良いです。

日本語の公式ドキュメントがあるので、是非参照して頂きたいです。

iOS Reference Library日本語版

http://developer.apple.com/jp/devcenter/ios/library/japanese.html

Apple Developer Documentation日本語版

http://developer.apple.com/jp/documentation/japanese.html

日本語ユーザが増えたら、Xcodeのクイックヘルプとかドキュメントとかも日本語化してくれないかなあ。

それとも、実はただの調査不足で既にあったりとか…

Permalink | トラックバック(1) | 22:49

2010-08-30

■http://anond.hatelabo.jp/20100830210841

やっと俺が言いたいことは伝わったのかな。最初からそう返答してくれたら良かったのに、こちらからすればそちらの発言が支離滅裂だよ。

俺が言いたかったことは「オブジェクト指向プログラミング言語でなくてもオブジェクト指向は使える」だけだから、それが伝われば俺の話はおしまい。話を進めるならどうぞ。

Permalink | トラックバック(0) | 21:54

- 転職ならen
- 派遣ならen

「オブジェクト指向」を含む日記

■「コンピュータプログラミングの概念・技法・モデル」の目次

■モノ指向

■「新しいプログラミング・パラダイム」の目次

■ペアプロが広まらない15の理由

■モテるstatic女子力を磨くための4つの心得

1. あえてnewを使ってインスタンスを生成する

2. プログラムでとにかくstaticを使うとモテる

3. とりあえず男には「えー！ なにそれ!? 知りたい知りたーい♪」と言っておく

4. プログラミングするときはインスタンスを生成できない女をアピールせよ

■ドラゴンボールで学ぶオブジェクト指向Z

はじめに（いいわけ）

結論

ドラゴンボールで学ぶオブエジェクト思考Z ドラゴンボールで学ぶデザインパターン

Template Method

他のパターン

■「ドラゴンボールで学ぶオブジェクト指向」 のクロージャに関して

■ドラゴンボールで学ぶオブジェクト指向にもういっちょツッコミ

ブクマコメントへレス

■ドラゴンボールで学ぶオブジェクト指向にツッコミ

■ドラゴンボールで学ぶオブジェクト指向

オブジェクト指向の基本

世界の成り立ち

クラスとインスタンス

追記

追記２

追記3

■C言語すら知らなかった云々の記事がちょっとひどい

3. とりあえず男には「えー！なにそれ!?　知りたい知りたーい♪」と言っておく

■「ドラゴンボールで学ぶオブジェクト指向」のクロージャに関して