「カプセル化」を含む日記 RSS

はてなキーワード: カプセル化とは

2017-11-15

anond:20171115000746

全く正しい! だからクソ案件にはBootstrapクラス命名しかしない。ある種究極のカプセル化、そこしか絶対に壊れないからな。

2017-07-02

日本人はなぜ入門者に厳しいのか?

週末の書店

プログラミングコーナーに行くと、いつもうんざりした気分になる。

何故ってこんなに入門書が溢れかえっているのに、何一つとして入門者向けの本が無いからだ。

日本書籍小売の総本山神保町三省堂書店の棚の端から端まで見た所で、ビギナー向けの本などありはしない。

なぜなら、入門書を謳っている本のコードほとんどが動かないコードからだ。

入門書だと言うのに、ページを割くべきところに文章イラストを割かない本が多すぎる。

例えばポインタコンストラクタインスタンスカプセル化…それぞれの概念

イラスト入門書だってそうだ。「入門」と書いてあるからといって、開いてみればデッサンや形のとり方を教える本などありはしない。

そう、日本入門書とは「元々デキる人がリメディアルとして持っておく本」のことであり、「ビギナー向けのウェルカム本」ではないのである

からといって、誰もがpython専門家になる胎教を受けて産まれるわけではないし、誰もが10代で写真と見まごうスケッチを描けるわけではない。

基本的には「デキる人」に着いて指導してもらうのである

では、その「デキる人」は誰に教わったのか?やはりデキる人たちや、海外入門書を車座になって読んで学習したのである

しかし、その「始祖・デキる人」がヒーロー時代とは、今とは複雑度合いも、求められるものも違う。

今は学生であっても、ある程度の高度な成果(ここでは、ネットで発表したものネットニュースでバズった経験や、学会評価された経験のこと)があって始めて企業受験票でしかない。

なぜ入門者向けの本がないのか?

それは(少なくとも)日本人初心者嫌いの民族からである

習うより慣れろ。仕事は見て盗め。教えられるのを待っているな。・・・

自分より出来ないやつに教えるのが大嫌いなのだ。(入門書の著者ですらそうなのだ!)

上にあるように、ある程度デキる人でないと、その手の会社には認められない。

からといって、大学教育で手ほどきを受けられるわけではない。これもある程度デキる人向けなのだ

では、書籍自助努力を、となっても、文頭にあるように、入門書向けの本など無く。

デキる人に一子相伝の手ほどきを受ける必要があるのだ。

では、デキる人はどこにいる?これもやはり雲の上の大学しかいない・・・

今はネットがある?これも難しい。

知恵袋や、teratailであっても、初心者に与えられる答えは「ググレカス」のみ。

では、ネットジャストな回答があるか?といえば・・・ない。基本的には公式リファレンスコピーや、動かないコードしかない。

デキる人は、デキない人の気持がわからない。何がわからないのかわからない。

からあいつらがわからないのは、あいつらが勉強不足だから、と考える。

からないのは、あいつらの自己責任だ。だから初心者は嫌なんだ。となる。

適性を測っている、という見方もある。

しかし、適性というもの基本的にやらなければわからないもので、やる前の教育から放棄しているのは適性を測るというより、

単純に教育放棄しているだけにほかならない。

日本人初心者軽視、というか教育軽視は今に始まったことではない。

「失敗の本質」でもそれは指摘されている。ということは戦時から既に教育嫌いなのだ

職場でもそう。教えられるのを待っているな、と言っておいて、いざ聞きに行けば「常識でわかるだろ」「ネットで調べて」「リファレンスマニュアル調べて」

学校でもそうだ。

授業の勉強も予習が前提。では授業ではより高度な話をするのか?しない。教師我流の演習である

演習するだけならば、家や図書館黒本赤本を解いていたほうがマシじゃないか

学校教育ですらこうだ。

日本人はとにかく初心者が憎い。潰したくて仕方がないのだ。

2017-04-06

http://anond.hatelabo.jp/20170406092042

元増田です。ありがとうございます

教えてくれた事はなんとなくわかった気がします。

ただ読んでイメージしている限りでは下に引用したあたりのことは

ある程度以上の規模のソースコードにならないと便利さが実感しにくいものなんですね。

まとまりのある複数変数メソッドを1つのクラスカプセル化できること。

ただねぇ、開発規模が大きくなると、関数名の重複を避けた命名が面倒になったり、

連想配列だと好きな場所勝手変数増やされたりして、メンテナンス性が悪くなるのね。

からクラスを使うようになりました。

まとまりのあるデータメソッドがあって、まとめておかないとヤバそうなときだけクラスにすればいい。

http://anond.hatelabo.jp/20170406081854

現役ペチパーだけど、元々PHPHTMLスクリプトを埋め込むところから始まった変態言語なので、

普通に関数を作って組み合わせてしまえば大半は事足りるのも当然なんだけども。

実務で使うと便利だなと思うのは、まとまりのある複数変数メソッドを1つのクラスカプセル化できること。

例えば、ユーザ情報管理するときに、「ユーザ情報」というクラスを作って、

その中に publicな変数として、名前フリガナ郵便番号、住所、電話番号、会員ID階級職業性別

を放り込んでおく。

同時に、ユーザ情報の処理に関連する処理の関数を public なメソッドとして、定義する。

ユーザ情報をタブ区切りで得るメソッド getTABDATA()

フォーム入力からユーザ情報にセットする setFromForm()

ユーザ情報が正しく入ってるか評価する Validate()

こうしておけば、

ユーザ情報を何かの関数に渡す時は、インスタンス変数1つ渡せば済む。

ユーザ情報に関する処理は、ユーザ情報クラス定義部を観れば済む。

という2大メリットが得られる。

そんなのPHPなら連想配列変数はまとめられるし、

メソッドだってつのファイル関数並べてインクルードすれば同じメリットが得られるやん?

…と私も思ってた。ただねぇ、開発規模が大きくなると、関数名の重複を避けた命名が面倒になったり、

連想配列だと好きな場所勝手変数増やされたりして、メンテナンス性が悪くなるのね。

からクラスを使うようになりました。


あとは、例えばメールを送るという1つの大きな処理に関連して複数関数定義する場合に、

その関数をまとめてメール送信クラスとしてしまうのはあるかな

実例

http://web-terminal.blogspot.jp/2014/04/php-file-mail-pear.html

PHPエクセル出力できるPHPExcelもクラスになっているから使いやすそう。

http://qiita.com/suin/items/7a8d0979b7675d6fd05b

PHPからPDF出すのもクラスになっていてありがたかった。

http://cmf.ohtanz.com/blog/archives/2463

結論としては、

まとまりのあるデータメソッドがあって、まとめておかないとヤバそうなときだけクラスにすればいい。

2016-03-27

たまたまソースコードレビューして貰う機会があったので

たまたまソースコードレビューして貰う機会があったので、久々見てもらったら、

「これ、カプセル化通り越して、原子化してません?w」ッて言われたので、ノリノリで定時退社決めてきた😆

2015-10-08

社畜が夜なべをしてエロキュレーションサイト作ってみた

こんにちは社畜です。

社畜はいってもいわゆるホワイト企業に勤めており、毎日19時には家にいてオナニーをしている生活を送っております

ですので、比較時間には余裕があり、周りからプログラミングでも学んでみれば?」と提言されたので、せっかくなので勉強がてら作ってみました。

ちなみに私は非技術職で、高校大学ともに文系人間です。まぁやればできるよね。

作成サイト

アダルト画像Sharing

http://share-ero.pics/

コンセプトはいかに簡単にエロ画像まとめサイトを作るか、ということに注力しました。

もちろん自分管理画面上からシコシコ作ってもいいのですが、せっかくなのでみんなで作れたほうがいいじゃん!ってのがことの発端です。

今回特に注力した点


大学の同期に何人か理系人間がいたのでいろいろと助けてもらえました。

動作環境

言語Ruby on RailsOSはubuntu14.04、RDBMySQL5.6を基本とし、後で述べますが他にRedisやVarnishなどのツールも使っております

いまのところ、サーバーは1台体制ですが、今後アクセスが急増した時に備えるため、NFSマウントロードバランサー、MasterSlaveによるレプリケーションには少なくとも対応予定です。

この辺は少し触れる予定です。

なおサーバー会社海外Linodeを使っています。なんでAWSじゃないの?と思われるかもしれませんが、単純に費用対効果の話になってきます

それこそ企業で行うのであれば、AWS機能面もすごいし、ターミナルでコツコツおこなっていたことがポチポチできちゃって、すごーいんですが、いかんせん高い。

LinodeはいわゆるクラウドというよりもよりVPSに近いと思います。ただ海外でのシェアも高いし、価格リーズナブルなので私はこれを使ってみることにしています

Sakuraはいいんですけど、エロには少し厳しいとのことなので。。。

デザイン

デザインというか、UIに関してはかなり気を使って作りました。いかに簡単に画像を選択して、まとめるかが鍵になってくるので.。

なので、

画像サイトをいくつか選択→タイトル説明カテゴリーをいれる→画像を選択→送信

の流れで簡単にアップできるようにしました。洗練するポイントはたくさんありそうですが、とりあえずはこれで行こうと思います。なおスマートフォンにも対応をしております

なお、こういうサービスを作る時のポイントってやはりjavascriptを使い過ぎない、ということだと思うんですよね。

しかたがないんですけど、イベント駆動型の言語ってどうしてもコード煩雑になる傾向があります。大きな会社できちんと管理できるようなコスト(というか時間)をかけられる会社ならいいんですけど、そうでないならまずjavascript無しでのプログラムを考えてみる、どうしても必要であればjavascriptを使う、みたいな。

私も今回はjavascriptは一部でのみ使用しております

ところで全体のイメージとしては、はてなさんを意識してみたのですが、デザインセンスの無さからか、全く別のものができてしまいましたwww

非同期におけるプログラミング

非同期プログラミングってご存知でしょうか?私はRubyから入った立場なのでピンと来るまでだいぶ時間がかかりました。

Rubyとかの同期プログラムってのは上から流れてきて、上の処理が終わるまで次の処理が進まない、というものになります

一方非同期プログラミングは上からの処理を待たずに、どんどこ次の処理を行いますちょっと乱暴な言い方ですが、だいたいのイメージはつくと思います

実はJavascriptも非同期プログラミング言語一種でして、たとえばなんかどっかのボタンを押して処理が進んでも、他の動作をしようと思えばできますよね?Gmailブラウザ上で受信をしていても、メールを書くとかの動作はできるわけです。つまりこれは処理を待たずに、別の処理が走っています。これが非同期プログラミングです。

そんで、なんでこんな話をしたかっていうと、今回の仕組みって画像ダウンロードしてきて、サムネイル化するわけですけど、実はダウンロードには時間がかかります。ヘタしたら2分くらい時間がかかるケースも有り、ボタンを押してからそんな時間待ってられません。

と、ここで上述の非同期プログラミングが効いてくるわけです。とりあえず処理は別のところに投げるからトップページを表示しておくね。こんなことができます

やり方は実はたくさんあるのですが、Rails4.2からActiveJobといって、それまでの様々なライブラリに枝分かれしてきた機能カプセル化したものになります。とはいってもバックエンドには一応ライブラリを置く必要があり、私はsidekiqというライブラリをそこに置きました。

他にもdelayed_jobとかなんかいろいろあるので、ぜひ見てみてください。

パフォーマンス周りで気を使っている点とこれから気をつける点

下に箇条書きしてみますね。

気を使っている点

今後気をつかう点

他にもMySQLクエリキャッシュとか、Apacheチューニングとかやることはありますが、この辺は正直Varnishで。。。というのが正直なところです。みんな使おうよ、Varnish。

SEO

つくっても人がこなければ仕方がありません。そこで大事になってくるのが、SEO(SearchEngineOptimization)です。

昔はとにかくリンクを張っていればそこそこ検索順位が上がったのですが、最近は賢くなってきたのでなかなかそうはいきません。

今はとにかく良質なコンテンツと、ソーシャルメディアでの拡散ですね。私は怠惰人間なので、みなさんに良質なコンテンツを作ってもらうと考えておりますwww

良質なコンテンツを書いてもらうにはやはりインセンティブ必要なので、Naverみたいに広告タグを貼ることができる機能でも作ろうかな、なんて思ってます

今後増やしたい機能としては




今はまだまだ機能が少ないんですが、今後どしどし増やしていく予定なので、応援よろしくお願いいたします!ご意見いただければ嬉しいです!

さて私は明日仕事なので、成瀬心美様でシコッて寝ます

2015-05-02

オブジェクト指向プログラミングとは、オブジェクトと呼ばれる機能部品ソフトウェア構成させるものであり、一般的に以下の機能や特徴を活用したプログラミング技法のことをいう。

カプセル化(振る舞いの隠蔽データ隠蔽

インヘリタンス(継承) -- クラスベース言語

ポリモフィズム多態性、多相性) -- 型付きの言語

ダイナミックバインディング(動的束縛) -- 動的型付言

この機能文法的提供するプログラミング言語は、オブジェクト指向プログラミング言語 (OOPL; object-oriented programming language) と呼ばれる。これらの機能のうち、オブジェクト指向の考え方で不可欠なのはカプセル化」の機能だけである。そのため、オブジェクト指向プログラミング言語の中には、カプセル化以外の機能については一部を提供していないものもある。

ただし、カプセル化可視性の定義)やポリモフィズムダイナミックバインディングオブジェクト指向言語に固有の概念というわけではなく、非オブジェクト指向言語の中にもこの性質を備えるものもある。

2014-08-12

http://anond.hatelabo.jp/20140812145234

からだが、言ってることがよくわからないな。

・状態は出来るだけ減らす

・適切にクラス分割、カプセル化して状態の依存関係を極限化する

あたりなら分かるが、private void関数に対して教条的に拒否する合理性は感じない。

2014-05-22

http://anond.hatelabo.jp/20140522185418

そもそもオブジェクト指向がクソだろw

カプセル化隠蔽とかバグ隠蔽しか思えん

オブジェクトポインタに似たクソさがある

まともな言語で言えばHaskell

普及率とかで総合的にみればScalaだろ

2014-04-09

http://anond.hatelabo.jp/20140407135839

オブジェクト指向の説明なんて、単純に一般社会における分担作業だと言えば済む話なのにねー。

ラーメン食べたかったら、ラーメン屋クラスを作って、ラーメン注文する。

ラーメン屋の中では、材料仕入れて、粉練って、スープ煮込んでいろいろやっているだろうが、

そんなことはお客から見えないようにカプセル化していると思えばいい。

2011-12-12

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

第1章 プログラミング概念入門
	1.1 計算器
	1.2 変数
	1.3 関数
	1.4 リスト
	1.5 リストについての関数
	1.6 プログラムの正しさ
	1.7 計算量
	1.8 遅延計算
	1.9 高階プログラミング
	1.10 並列性
	1.11 データフロー
	1.12 明示的状態
	1.13 オブジェクト
	1.14 クラス
	1.15 非決定性と時間
	1.16 原子性
	1.17 ここからどこへ行くのか?
	1.18 練習問題

第1部 一般的計算モデル

第2章 宣言的計算モデル
	2.1 実用プログラミング言語定義
		2.1.1 言語の構文
		2.1.2 言語意味
	2.2 単一代入格納域
		2.2.1 宣言的変数
		2.2.2 値格納域
		2.2.3 値生成
		2.2.4 変数識別子
		2.2.5 識別子を使う値生成
		2.2.6 部分値
		2.2.7 変数の,変数への束縛
		2.2.8 データフロー変数
	2.3 核言語
		2.3.1 構文
		2.3.2 値と型
		2.3.3 基本型
		2.3.4 レコード手続き
		2.3.5 基本操作
	2.4 核言語意味
		2.4.1 基本概念
		2.4.2 抽象マシン
		2.4.3 待機不能な文
		2.4.4 待機可能な文
		2.4.5 基本概念再訪
	2.5 メモリ管理
		2.5.1 末尾呼び出し最適化
		2.5.2 メモリライフサイクル
		2.5.3 ガーベッジコレクション
		2.5.4 ガーベッジコレクションは魔術ではない
		2.5.5 Mozartのガーベッジコレクタ
	2.6 核言語から実用言語へ
		2.6.1 構文上の便宜
		2.6.2 関数(fun文)
		2.6.3 対話的インターフェース(declare文)
	2.7 例外
		2.7.1 動機と基本概念
		2.7.2 例外を持つ宣言的モデル
		2.7.3 親言語の構文
		2.7.4 システム例外
	2.8 進んだ話題
		2.8.1 関数型プログラミング言語
		2.8.2 単一化と内含(entailment)
		2.8.3 動的型付けと静的型付け
	2.9 練習問題

第3章 宣言的プログラミング技法
	3.1 宣言的とはどういうことか?
		3.1.1 宣言的プログラムの分類
		3.1.2 仕様記述言語
		3.1.3 宣言的モデルにおいてコンポーネントを実装すること
	3.2 反復計算
		3.2.1 一般的図式
		3.2.2 数についての反復
		3.2.3 局所的手続きを使うこと
		3.2.4 一般的図式から制御抽象へ
	3.3 再帰計算
		3.3.1 スタックの大きさの増加
		3.3.2 代入ベース抽象マシン
		3.3.3 再帰計算を反復計算に変換すること
	3.4 再帰を用いるプログラミング
		3.4.1 型の記法
		3.4.2 リストについてのプログラミング
		3.4.3 アキュムレータ
		3.4.4 差分リスト
		3.4.5 キュー
		3.4.6 木
		3.4.7 木を描画すること
		3.4.8 構文解析
	3.5 時間効率空間効率
		3.5.1 実行時間
		3.5.2 メモリ使用量
		3.5.3 償却的計算量
		3.5.4 性能についての考察
	3.6 高階プログラミング
		3.6.1 基本操作
		3.6.2 ループ抽象
		3.6.3 ループ言語的支援
		3.6.4 データ駆動技法
		3.6.5 明示的遅延計算
		3.6.6 カリー化
	3.7 抽象データ型
		3.7.1 宣言的スタック
		3.7.2 宣言的辞書
		3.7.3 単語出現頻度アプリケーション
		3.7.4 安全抽象データ型
		3.7.5 安全な型を備えた宣言的モデル
		3.7.6 安全な宣言的辞書
		3.7.7 資格セキュリティ
	3.8 宣言的でない必要物
		3.8.1 ファイルを伴うテキスト入出力
		3.8.2 グラフィカルユーザインタフェースを伴うテキスト入出力
		3.8.3 ファイルとの状態なしデータI/O
	3.9 小規模プログラム設計
		3.9.1 設計方法
		3.9.2 プログラム設計の例
		3.9.3 ソフトウェアコンポーネント
		3.9.4 スタンドアロンプログラムの例
	3.10 練習問題

第4章 宣言的並列性
	4.1 データ駆動並列モデル
		4.1.1 基本概念
		4.1.2 スレッド意味
		4.1.3 実行列
		4.1.4 宣言的並列性とは何か?
	4.2 スレッドプログラミングの基本的技法
		4.2.1 スレッドを生成すること
		4.2.2 スレッドブラウザ
		4.2.3 スレッドを使うデータフロー計算
		4.2.4 スレッドスケジューリング
		4.2.5 協調的並列性と競合的並列性
		4.2.6 スレッド操作
	4.3 ストリーム
		4.3.1 基本的生産者消費者
		4.3.2 変換器とパイプライン
		4.3.3 資源管理し,処理能力改善すること
		4.3.4 ストリームオブジェクト
		4.3.5 ディジタル論理シミュレーション
	4.4 宣言的並列モデルを直接使うこと
		4.4.1 順序決定並列性
		4.4.2 コルーチン
		4.4.3 並列的合成
	4.5 遅延実行
		4.5.1 要求駆動並列モデル
		4.5.2 宣言的計算モデル
		4.5.3 遅延ストリーム
		4.5.4 有界バッファ
		4.5.5 ファイルを遅延的に読み込むこと
		4.5.6 ハミング問題
		4.5.7 遅延リスト操作
		4.5.8 永続的キューアルゴリズム設計
		4.5.9 リスト内包表記
	4.6 甘いリアルタイムプログラミング
		4.6.1 基本操作
		4.6.2 ティッキング(ticking)
	4.7 Haskell言語
		4.7.1 計算モデル
		4.7.2 遅延計算
		4.7.3 カリー化
		4.7.4 多態型
		4.7.5 型クラス
	4.8 宣言的プログラム限界拡張
		4.8.1 効率性
		4.8.2 モジュラ性
		4.8.3 非決定性
		4.8.4 現実世界
		4.8.5 正しいモデルを選ぶこと
		4.8.6 拡張されたモデル
		4.8.7 異なるモデルを一緒に使うこと
	4.9 進んだ話題
		4.9.1 例外を持つ宣言的並列モデル
		4.9.2 さらに遅延実行について
		4.9.3 通信チャンネルとしてのデータフロー変数
		4.9.4 さらに同期について
		4.9.5 データフロー変数有用性
	4.10 歴史に関する注記
	4.11 練習問題

第5章 メッセージ伝達並列性
	5.1 メッセージ伝達並列モデル
		5.1.1 ポート
		5.1.2 ポート意味
	5.2 ポートオブジェクト
		5.2.1 NewPortObject抽象
		5.2.2 例
		5.2.3 ポートオブジェクトに関する議論
	5.3 簡単なメッセージプロトコル
		5.3.1 RMI(遠隔メソッド起動)
		5.3.2 非同期RMI
		5.3.3 コールバックのあるRMI(スレッド使用)
		5.3.4 コールバックのあるRMI(継続のためのレコード使用)
		5.3.5 コールバックのあるRMI(継続のための手続き使用)
		5.3.6 エラー報告
		5.3.7 コールバックのある非同期RMI
		5.3.8 二重コールバック
	5.4 並列性のためのプログラム設計
		5.4.1 並列コンポーネントを使うプログラミング
		5.4.2 設計方法
		5.4.3 並列性パターンとしての機能的構成要素
	5.5 リフト制御システム
		5.5.1 状態遷移図
		5.5.2 実装
		5.5.3 リフト制御システムの改良
	5.6 メソッド伝達モデルを直接使用すること
		5.6.1 1つのスレッドを共有する複数のポートオブジェクト
		5.6.2 ポートを使う並列キュー
		5.6.3 終点検出を行うスレッド抽象
		5.6.4 直列依存関係の除去
	5.7 Erlang言語
		5.7.1 計算モデル
		5.7.2 Erlangプログラミング入門
		5.7.3 receive操作
	5.8 進んだ話題
		5.8.1 非決定性並列モデル
	5.9 練習問題

第6章 明示的状態
	6.1 状態とは何か?
		6.1.1 暗黙的(宣言的)状態
		6.1.2 明示的状態
	6.2 状態とシステム構築
		6.2.1 システムの性質
		6.2.2 コンポーネントベースプログラミング
		6.2.3 オブジェクト指向プログラミング
	6.3 明示的状態を持つ宣言的モデル
		6.3.1 セル
		6.3.2 セル意味
		6.3.3 宣言的プログラミングとの関係
		6.3.4 共有と同等
	6.4 データ抽象
		6.4.1 データ抽象組織する8つの方法
		6.4.2 スタックの変種
		6.4.3 多態性
		6.4.4 引数受け渡し
		6.4.5 取り消し可能資格
	6.5 状態ありコレクション
		6.5.1 インデックス付きコレクション
		6.5.2 インデックス付きコレクションを選ぶこと
		6.5.3 その他のコレクション
	6.6 状態に関する推論
		6.6.1 不変表明
		6.6.2 例
		6.6.3 表明
		6.6.4 証明規則
		6.6.5 正常終了
	6.7 大規模プログラム設計
		6.7.1 設計方法
		6.7.2 階層システム構造
		6.7.3 保守性
		6.7.4 将来の発展
		6.7.5 さらに深く知るために
	6.8 ケーススタディ
		6.8.1 遷移的閉包
		6.8.2 単語出現頻度(状態あり辞書を使用する)
		6.8.3 乱数を生成すること
		6.8.4 口コミシミュレーション
	6.9 進んだ話題
		6.9.1 状態ありプログラミング限界
		6.9.2 メモリ管理と外部参照
	6.10 練習問題

第7章 オブジェクト指向プログラミング
	7.1 継承
	7.2 完全なデータ抽象としてのクラス
		7.2.1 例
		7.2.2 この例の意味
		7.2.3 クラスオブジェクト定義すること
		7.2.4 クラスメンバ
		7.2.5 属性初期化すること
		7.2.6 第1級メッセージ
		7.2.7 第1級の属性
		7.2.8 プログラミング技法
	7.3 漸増的データ抽象としてのクラス
		7.3.1 継承グラフ
		7.3.2 メソッドアクセス制御(静的束縛と動的束縛)
		7.3.3 カプセル化制御
		7.3.4 転嫁委任
		7.3.5 内省
	7.4 継承を使うプログラミング
		7.4.1 継承の正しい使い方
		7.4.2 型に従って階層を構成すること
		7.4.3 汎用クラス
		7.4.4 多重継承
		7.4.5 多重継承に関するおおざっぱな指針
		7.4.6 クラス図の目的
		7.4.7 デザインパターン
	7.5 他の計算モデルとの関係
		7.5.1 オブジェクトベースプログラミングコンポーネントベースプログラミング
		7.5.2 高階プログラミング
		7.5.3 関数分解と型分解
		7.5.4 すべてをオブジェクトにすべきか?
	7.6 オブジェクトシステムを実装すること
		7.6.1 抽象図
		7.6.2 クラスを実装すること
		7.6.3 オブジェクトの実装
		7.6.4 継承の実装
	7.7 Java言語(直列部分)
		7.7.1 計算モデル
		7.7.2 Javaプログラミング入門
	7.8 能動オブジェクト
		7.8.1 例
		7.8.2 NewActive抽象
		7.8.3 フラウィウス・ヨセフスの問題
		7.8.4 その他の能動オブジェクト抽象
		7.8.5 能動オブジェクトを使うイベントマネージャ
	7.9 練習問題

第8章 状態共有並列性
	8.1 状態共有並列モデル
	8.2 並列性を持つプログラミング
		8.2.1 さまざまな手法概観
		8.2.2 状態共有並列モデルを直接使うこと
		8.2.3 原子アクションを使うプログラミング
		8.2.4 さらに読むべき本
	8.3 ロック
		8.3.1 状態あり並列データ抽象を構築すること
		8.3.2 タプル空間(Linda)
		8.3.3 ロックを実装すること
	8.4 モニタ
		8.4.1 定義
		8.4.2 有界バッファ
		8.4.3 モニタを使うプログラミング
		8.4.4 モニタを実装すること
		8.4.5 モニタの別の意味
	8.5 トランザクション
		8.5.1 並列性制御
		8.5.2 簡易トランザクションマネージャ
		8.5.3 セルについてのトランザクション
		8.5.4 セルについてのトランザクションを実装すること
		8.5.5 トランザクションについてさらに
	8.6 Java言語(並列部分)
		8.6.1 ロック
		8.6.2 モニタ
	8.7 練習問題

第9章 関係プログラミング
	9.1 関係計算モデル
		9.1.1 choice文とfail文
		9.1.2 探索木
		9.1.3 カプセル化された
		9.1.4 Solve関数
	9.2 別の例
		9.2.1 数値例
		9.2.2 パズルとnクイーン問題
	9.3 論理プログラミングとの関係
		9.3.1 論理論理プログラミング
		9.3.2 操作意味論理意味
		9.3.3 非決定性論理プログラミング
		9.3.4 純粋Prologとの関係
		9.3.5 他のモデルにおける論理プログラミング
	9.4 自然言語構文解析
		9.4.1 簡単な文法
		9.4.2 この文法に従う構文解析
		9.4.3 構文木を生成すること
		9.4.4 限定記号を生成すること
		9.4.5 パーサを走らせること
		9.4.6 パーサを「逆向きに(backward)」走らせること
		9.4.7 単一化文法
	9.5 文法インタプリタ
		9.5.1 簡単な文法
		9.5.2 文法のコード化
		9.5.3 文法インタプリタを走らせること
		9.5.4 文法インタプリタを実装すること
	9.6 データベース
		9.6.1 関係を定義すること
		9.6.2 関係を使って計算すること
		9.6.3 関係を実装すること
	9.7 Prolog言語
		9.7.1 計算モデル
		9.7.2 Prologプログラミング入門
		9.7.3 Prologプログラムを関係プログラム翻訳すること
	9.8 練習問題

第2部 特殊化された計算モデル10グラフィカルユーザインタフェースプログラミング
	10.1 宣言的/手続き的方法
	10.2 宣言的/手続き的方法を使うこと
		10.2.1 基本的ユーザインタフェースの要素
		10.2.2 GUIを構築すること
		10.2.3 宣言的座標
		10.2.4 リサイズ時の宣言的振る舞い
		10.2.5 ウィジェットの動的振る舞い
	10.3 対話的学習ツールPrototyper
	10.4 ケーススタディ
		10.4.1 簡単なプログレモニタ
		10.4.2 簡単なカレンダウィジェット
		10.4.3 ユーザインタフェースの動的生成
		10.4.4 状況順応時計
	10.5 GUIツールを実装すること
	10.6 練習問題

第11章 分散プログラミング
	11.1 分散システムの分類
	11.2 分散モデル
	11.3 宣言的データの分散
		11.3.1 オープン分散と大域的ネーミング
		11.3.2 宣言的データを共有すること
		11.3.3 チケット配布
		11.3.4 ストリーム通信
	11.4 状態の分散
		11.4.1 単純状態共有
		11.4.2 分散字句的スコープ
	11.5 ネットワークアウェアネス
	11.6 共通分散プログラミングパターン
		11.6.1 静的オブジェクトモバイルオブジェクト
		11.6.2 非同期的オブジェクトデータフロー
		11.6.3 サーバ
		11.6.4 クローズド分散
	11.7 分散プロトコル
		11.7.1 言語実体
		11.7.2 モバイル状態プロトコル
		11.7.3 分散束縛プロトコル
		11.7.4 メモリ管理
	11.8 部分的失敗
		11.8.1 失敗モデル
		11.8.2 失敗処理の簡単な場合
		11.8.3 回復可能サーバ
		11.8.4 アクティブフォールトトレランス
	11.9 セキュリティ
	11.10 アプリケーションを構築すること
		11.10.1 まずは集中,後に分散
		11.10.2 部分的失敗に対処すること
		11.10.3 分散コンポーネント
	11.11 練習問題

第12章 制約プログラミング
	12.1 伝播・探索法
		12.1.1 基本的考え方
		12.1.2 部分情報を使って計算すること
		12.1.3 例
		12.1.4 この例を実行すること
		12.1.5 まとめ
	12.2 プログラミング技法
		12.2.1 覆面算
		12.2.2 回文積再訪
	12.3 制約ベース計算モデル
		12.3.1 基本的制約と伝播子
		12.3.2 計算空間の探索をプログラムすること
	12.4 計算空間定義し,使うこと
		12.4.1 深さ優先探索エンジン
		12.4.2 検索エンジンの実行例
		12.4.3 計算空間の生成
		12.4.4 空間の実行
		12.4.5 制約の登録
		12.4.6 並列的伝播
		12.4.7 分配(探索準備)
		12.4.8 空間の状態
		12.4.9 空間クローン
		12.4.10 選択肢を先に任せること
		12.4.11 空間マージすること
		12.4.12 空間失敗
		12.4.13 空間計算を注入すること
	12.5 関係計算モデルを実装すること
		12.5.1 choice文
		12.5.2 Solve関数
	12.6 練習問題

第3部 意味

第13章 言語意味
	13.1 一般的計算モデル
		13.1.1 格納域
		13.1.2 単一代入(制約)格納域
		13.1.3 抽象構文
		13.1.4 構造的規則
		13.1.5 直列実行と並列実行
		13.1.6 抽象マシン意味との比較
		13.1.7 変数導入
		13.1.8 同等性の強制(tell)
		13.1.9 条件文(ask)
		13.1.10 名前
		13.1.11 手続抽象
		13.1.12 明示的状態
		13.1.13 by-need同期
		13.1.14 読み出し専用変数
		13.1.15 例外処理
		13.1.16 失敗値
		13.1.17 変数置き換え
	13.2 宣言的並列性
		13.2.1 部分停止と全体停止
		13.2.2 論理同値
		13.2.3 宣言的並列性の形式的定義
		13.2.4 合流性
	13.3 8つの計算モデル
	13.4 よくある抽象意味
	13.5 歴史に関する注記
	13.6 練習問題

2011-05-20

http://anond.hatelabo.jp/20110520101639

Javaなどの「高機能な」言語仕様が「無自覚に仕込むバグ」を知ってたら、とてもじゃないけど言えない。

「不注意やミス」は良い、単純に「間違い」なだけだから

でも「無自覚(ユーザーが仕込んだわけじゃないバグ)」は不味い、それを拾おうとすると、結局言語仕様で起こりうるバグカプセル化してチェックするって話になるからだ。

CIツールを使って、常にcheckstyleでも走らせておけばいいんじゃないかな。今時、そんなのは人間様が労働力を割かなきゃいけないお仕事じゃないよ。

残りの「不注意やミス」をなんとかしたいなら、それこそ「高機能な」言語を使うべきだよ。

もちろん、特定の言語を使えば全て解決するわけではないが、ダメージコントロールのしやすさが全然違うから

http://anond.hatelabo.jp/20110520101639

Javaなどの「高機能な」言語仕様が「無自覚に仕込むバグ」を知ってたら、とてもじゃないけど言えない。

「不注意やミス」は良い、単純に「間違い」なだけだから

でも「無自覚(ユーザーが仕込んだわけじゃないバグ)」は不味い、それを拾おうとすると、結局言語仕様で起こりうるバグカプセル化してチェックするって話になるからだ。

横だけど、これ何の話してるんだろ?

処理系とか標準ライブラリバグってことではないよねぇ

http://anond.hatelabo.jp/20110520015743

つまり、「生産性の高い言語」は、人間の不注意やミス言語処理系の側で防止したり、影響範囲を最小限にしてくれるということ。

これを無邪気に言い放つ人とは一緒に仕事したくないわ、とだけ言っておきますよ。

Javaなどの「高機能な」言語仕様が「無自覚に仕込むバグ」を知ってたら、とてもじゃないけど言えない。

「不注意やミス」は良い、単純に「間違い」なだけだから

でも「無自覚(ユーザーが仕込んだわけじゃないバグ)」は不味い、それを拾おうとすると、結局言語仕様で起こりうるバグカプセル化してチェックするって話になるからだ。

そこに意識的にならないと、そもそも議論の出発点にすら立ってない。

Java場合ユーザフィードバックにより成熟したライブラリやツール群を、多くの場合無料で利用できるのがメリットと言える。

有料無料・・・そうですか・・・

2009-03-10

オブジェクト指向は、手続き型言語をやっていると自然に導かれる発想

手続き型言語をやっていると、データを組み合わせて取り扱う必要が出てくる。

例えば、顧客データを扱う必要があるとき、顧客の「名前、住所、所属、電話番号、取引内容...」などをまとめて取扱いたい。

そこで、構造体という発想が出てくる。

コンストラクタ、デストラクタ、メソッド、アクセス制御

手続き型言語では

構造体を扱っていると、新しく顧客データを作るとき、毎回毎回、作った後に同じ動作をしないといけないことに気づく。

具体的には、名前、住所、電話番号の登録。

そしたら、それをいっぺんにやってしまうために関数を作ることになるだろう。

init_customer(struct Customer*, char* name, char* addr, char* tel)

また、逆に顧客データが不要になったとき、メモリ解放などをさせるために、

delete_customer(struct Customer*)

も作ることになるだろう。

さらに、取引を行うたびに、取引データを追加しないといけない。そのために、このような関数を作るだろう。

add_deal_customer(struct Customer*, char* deal_name, char* deal_ammount)

そして、複数人でプログラムを作っていると

「おいおい!せっかく取引データ追加用のadd_deal_customer作ったのに、なんで自分勝手に追加してるんだよ!てか、その方法だとメモリ解放どうすんの?ちゃんと作ったの使ってくれたら、delete_customer()でできるようになってるのに」

って状況が生じうる。それを防止するために、コメント

「/* 取引データの追加は必ずadd_deal_customerを使うこと! */」

と書くことになるだろう。

てか、わざわざコメント書いたのにこいつ読んでねーし。あーあ、めんどくさいめんどくさい。

オブジェクト指向

そこで、だ。言語を少し別のものにかえて、構造体に関数を持たせられるようにしよう。

そして、構造体ができたときに、自動でinitって関数を、削除されるときに、自動でdelって関数を呼ぶとしよう。

その関数が、コンストラクタとデストラクタ

そして、add_deal_customerも構造体の中に入れてしまおう。名前は長くて面倒なので、

Customer.add_deal(char* deal_name, char* deal_ammount)

のようにしてしまおう。

さらに、add_dealを使わずに直接、取引データを追加しやがるならず者対策も付け加えてしまおう。

privateにした変数は、構造体が持ってる関数からしか、いじくれないようにしてやろう。

今まではコメント読まない馬鹿の世話に苦労していたのだが、これからはコンパイラがそういうやつにエラーを出してくれる。

継承

次は継承お話。話は変わって、今度はGUIパーツで説明する。

ボタンってあるよね。あれを作りたい。

普通に文字が書いてあって押したら何かが起こるボタンアイコンが描いてあって押したら何かが起こるボタン

この2つを作りたい。

手続き型言語では

まず、文字のボタンを作ろう。

関数を持てる構造体を作り、「表示する文字(変数)、クリックしたときの動作を定義する関数へのポインタ(変数)、描画命令が出た時に描画する関数(関数)、クリック命令を受け取り、構造体にセットされた関数へのポインタを呼び出す関数(関数)」

がいるかな。

次に、アイコンボタン。「表示するアイコン(変数)、クリックしたときの動作を定義する関数へのポインタ(変数)、描画命令が出た時に描画する関数(関数)、クリック命令を受け取り、構造体にセットされた関数へのポインタを呼び出す関数(関数)」

あ、さっき作ったのとほぼ同じじゃーん!文字ボタン構造体をコピペしちゃえ!

あとは文字の変数を、アイコンに変えて、描画命令を、文字描画からアイコン描画に変えればできるじゃん!

ところが、文字ボタンクリック命令を受け取る関数バグが見つかった!よし、デバッグできた!

けど、アイコンボタンコピペしてたんだった!またコピペしなおしじゃん。あーめんどくさ。

もしそれ以外に、チェックボックスボタンとか、もっと別のボタンとか、いろいろコピペで作ってたらもっとめんどくさ。

オブジェクト指向

そこで、こんなことができたらいいんじゃないか?

文字ボタンにも、アイコンボタンにも共通する、関数をもった構造体を作っておく。

ボタン構造体「クリックしたときの動作を定義する関数へのポインタ(変数)、クリック命令を受け取り、構造体にセットされた関数へのポインタを呼び出す関数(関数)」

そして、文字ボタンは、ボタン構造体に「表示する文字(変数)、描画命令が出た時に描画する関数(関数)」を、

アイコンボタンは、ボタン構造体に「表示するアイコン(変数)、描画命令が出た時に描画する関数(関数)」を追加すればいいんだ。

これを、継承と呼ぶ。

さらに、文字ボタンアイコンボタンも、同じ「ボタン構造体」を持っているから、どっちも同じ「ボタン」として扱うことができる。

後で画面内のボタンを全部解放する必要があるときとか、実はこれ、すごく便利。

別の構造体で扱っていたら、文字ボタン用の配列アイコンボタン用の配列を用意し、それぞれに作ったボタンをいれ、解放するときはそれぞれの配列の中身を解放しないといけない。めんどくさ。

けど、どっちもボタン継承しているから、ボタン配列を用意して、文字ボタンアイコンボタンも全部同じ配列に入れて、1つの配列の中身を解放したらいい。楽ちん。

まとめ

はい、そうすると、関数を持った構造体はもはや、もとの構造体とは違う感じになりました。

これをクラスと呼びましょう。クラスから作られたデータは、オブジェクトと呼びましょう。

なんか、オブジェクトがほかのオブジェクトから独立してカプセル化されてるみたいですね。

そして、オブジェクトが持ってる関数。メソッドとでも呼びましょうか。これ、まるでオブジェクト自分のやりたいことを知っているかのようです。

手続きを構造体や関数に細かく分離していくにつれて、構造体と関数の組み合わせってのが出てきて、まとまりが見えてくるのです。

そいつらをまとめてしまって、一つの部品として扱って、外からはあんまり部品の中身を見えないようにしましょう。

部品の中身を直接いじらせるんじゃなくて、部品をいじらせるための関数を用意して、それを経由してやってもらいましょう。

それが、カプセル化とかいうやつです。

こんな感じで、手続き型言語をやっていると、自然オブジェクト指向って方向にたどり着くと思うのです。

2008-12-30

カプセル化は常に真ではない

開発効率性を重要視するか、モジュールとしての錬度を重要視するのか、それが問題だ。ここで一つの提案をする。

開発途上において、どの変数を private にすべきで、どの変数に getter が必要で、どの変数に setter が必要で、

どの関数を private にすべきなのかを悩んでいては、本当に重要なところ、つまりアルゴリズム時間をかけられない。

まずは、アジャイルプロトタイピングをするのだ。その時にカプセル化に頭を悩ますのは良い方法ではない。

コードでやることが決まった後、それをモジュールライブラリとして完成度をあげるリファクタリングの段階で、

カプセル化クラス関数名、関数の再利用性について頭を悩ますのが効率が良い。

ただし、イケプログラマに限る。

ダメプログラマにやらせると、アジャイルプロトタイピングの段階で、全ての処理が1つの関数に書いてあるなどということになりうる。

類似の処理がほぼコピペということになりうる。リファクタリングの作業が、もはやリファクタリングではなく、リストラチューリングになりうる。

2008-08-21

プライベートなんてクソだ

クソ。ホントにクソ。

何がプライベートだ。使えねー。

バージョン整合ドキュメントがない?

は?なにいってんの?そんなもの覚悟のうえだ。

俺は機能を弄りたいんだよ。ラップしたいんだよ。継承したいんだよ。

カプセル化?隠蔽?

は?なにいってんの?ソース書き換えたら意味ねーじゃん。

俺はソースを弄りたくないんだよ。追加したいんだよ。分離したいんだよ。

お前の、そのでろでろなところを公開して

ぐちょぐちょに掻き回してもらいなさい

スケベ?変体?は?なにいってんの?

お前はjavascriptなんだよ?変態だよ?

公私なんて言ってると逝てまうぞ。

2008-04-18

http://anond.hatelabo.jp/20080418010901

ほう、その辺の本には「神」なんて言葉が乱舞しとるがな。じゃあ日本古典がどう宗教価値に直結しとるんだ?

そりゃ「影響」はしてるだろうがな。別にキリスト教の神である必然性などない。/いや、親鸞の書いたものは当然古語で書かれてるでしょ?

「一般人レベル」でいうのなら、欧米先進国様の古典を学ぶ意義と同程度のものは間違いなくあるよ。

いや、自明とか間違いなくとか言われてもなあ。具体的に挙げてくれる? 君の議論の最大の弱点って多分具体性がないことだから。

グレコ・ローマン文化の話じゃなかったのかよ。近代以降ならそりゃ当然だろ。

いや君がニュートンを引き合いに出したんでしょうに。民主主義に関してはギリシャにまで遡って意義深い書籍を見つけることは出来るだろうなあ。

ほら、君は「??だとすれば」という仮定が読めないんだよね。

で、いつまで撤回した仮定を引きずるわけ?w

あとさあ、まやかしまやかしで構わないけど、そういう意味なら俺は英語の「役に立つ」もまやかしだと思うがねえ。

何かひとつ共通言語がないとITなんてやってられん、というのは厳然たる事実だろ。

一方で、文化資本による格差なんぞないほうがいいに決まってる。

東大卒は毎年数千人だ。それで、MIT卒は何人いるか知ってる?ハーバードは?プリンストンは?スタンフォードは?オックスフォードは?ケンブリッジは?

数千人か。なおさらたいしたことないな。で、MIT卒全員をエリートと呼んだ覚えはないが?(他の大学もね)。

仮にそうだとしても、「年に数人」レベル人間「教育」なんておこがましいと思わんか。

まあそうね。勝手にどこかで学んできそうな気はする。

教育ってのは、特に公教育ってのは、底上げのためにやるもんであって。

誰も「普通東大生数百人のレベルをギリギリにチューンする」なんて言ってないし、そもそも東大生の中で「教育制度がもっとよければ俺はもっと偉くなれた!」なんて言ってる奴は落ちこぼれだけだよ。だから「普通東大生数百人のレベルをギリギリにチューンする」という発想自体がそもそも無意味

いや、お前そういう話しかしてなかったじゃんw 俺が公教育は平均と底辺を上げるためのものだと主張したらやたら激しく反発してたよなあ?

いや、主流の座から滑り落ちたものを普通スタンダードとは呼ばないだろう。

主流と標準を辞書で引くことをお勧めする。そりゃ、主流が標準を塗り替えてしまうことは結構あるが、少なくとも数値計算世界ではまだだろう。過去の蓄積ってのがあるんだ。

Cを使ってアセンブラまがいのコードを書き、新しい言語なんて覚える暇があったらもっと他のことをするとかなんとか言ってる人だって一定の比率で存在する。おわかり?

それは、特にアセンブラが必要でもないケースでか? ちょっと勘弁して欲しいなw まあ仕事としてうまくやれてるならそれでもいいけどさ、特殊ケースだろ?

まだ、例えば専用プロセッサなり組み込みデバイスなりを制御するためにアセンブラ使うってほうがはるかに一般的なケースだと思うがな。数値計算パターン認識においてさえ。

どうも話が巧妙にずらされてる気がするんだが。

いや、君自身RubyとかPerlとかC++とかJavaとかに言及しちゃったからねえ。どっちが引っ掛けたかというのは不毛になりそうだからやめようや。なんなら俺がズルかったということにしてもいいが。

たとえばいきなりJavaを覚えさせられた人間がそれがわかるとは到底思えない。ライブラリソースを読めるレベルになってはじめてわかることだろう、それは。

いや、Javaライブラリソースを読むレベルになったらたしかにかなり専門的だが、そもそもJavaで書いたコードで高速計算させようというほうが間違いなわけで。

C++に関して言うなら、アセンブラ的な最適化に手を出すのはだいたい最後の最後だろう。俺(や多分君)のような古い世代はアセンブラからの積み上げで高級言語を見るけど、高級言語の側から必要なレベルまで掘り下げていく、という見方も可能なはずだし、最適化の上ではむしろそちらが本筋。

で、君が重いクラスライブラリとして想定してるのはなんなの? ちゃんと最近のものを使ってれば、そんじょそこらの奴がCでちゃっちゃと書くコードと同じかたいていは速いコードを生成するし、もちろん可読性も高くなるな。

C++の話も同様。敢えて「C++らしい」処理を書けば計算量はどんどん増えて、例えば行列カプセル化して演算子オーバーロードしてなんてことやってたら計算時間が倍ぐらいになってもおかしくはないだろう。一晩で終わる計算が翌日の昼までかかるということになったら作業効率には歴然たる差が出るぞ。

具体的にどこの出してるC++行列演算ライブラリがそこまで効率悪いって?

(補足追記)

最近C++用の数値演算ライブラリはかなり出来がよく、FORTRAN用のそれに性能で肉薄するところまで来ている。そう、ここでは、ライバルは君が主流からも標準からも蹴落とされたと主張したいらしきFORTRANなんだよ。

で、どの辺がネックかというと、君の言うように記述性と実行速度の関係だったりはする。でも、それは低水準処理がどうこうという問題ではないよな。

この件については、議論してる人がネットでも結構いるから読んでみるといい。君が思うほどにC,C++圧勝しているわけではないよ。随分C++が向上してはいるけど。で、FORTRANのほうが言語の構造上最適化が効き易い等の話題はあっても、手作業で機械語レベル最適化をするなんてのは、候補にさえ挙がらないな。

http://anond.hatelabo.jp/20080417234519

あのさあ、「一般的にはこういうことが言われている」ということを主張したら、いつの間にか俺が「こういうこと」を主張していることになってるのはなんでなんですか、とさっきから何度も聞いてるんですが。「そうとしか思えないから」って、あんたの主観でしょ。しかもあんたが俺のことを色眼鏡で見てたことはあんたが自分で言ったことだし。

民主主義自由主義自然科学も、キリスト教論理的に直結はしていない。

ほう、その辺の本には「神」なんて言葉が乱舞しとるがな。じゃあ日本古典がどう宗教価値に直結しとるんだ?

それが「一般人レベル」か? 高校で教える価値があるかどうかは微妙だが。

これは確かに読み飛ばした、失敬。

日本古典の話をしてるんだが。とりあえず便宜的に日本言文一致体以前以後で区切ってみようか。

なんか、今でも一般人が学ぶ意義のあるような文献がそれ以前にある?

しつこいなあ。食い下がってるのはどっちだよ。「意義」の定義によるだろ。「一般人レベル」でいうのなら、欧米先進国様の古典を学ぶ意義と同程度のものは間違いなくあるよ。日本文化のうち文学美術舞台芸術に優れたものがあることは君も否定せんだろうが、それらの趣味思想だのなんだのに劣ることはあり得まい。

欧米政治思想の本なんかはそれこそニュートンの時代のとか普通に今でも重要でしょ。

グレコ・ローマン文化の話じゃなかったのかよ。近代以降ならそりゃ当然だろ。フランス革命1789年明治維新1868年の差が今更どれほど重要だとあんたが思ってるのかは知らんが(明治維新は不完全な革命とかいうなよ。そんなこと言えばロベスピエールとかナポレオンってのはどうなるんだ)。ただその意味で言うなら欧米であってもドイツなんかは後進国なんであって、あんたが言ってるのは「イギリスフランス」の話でしかない。「欧米」ではないぞ。

君の言うステータスシンボルのような意味での「役に立つ」自体を俺は批判し否定してるんだよ。まやかしだってな。で、撤回したんじゃなかったか? やっぱ食いさがってんじゃんww

一方で、海外のほとんどのライブラリドキュメント英語で書いてあるから、英語はとても役に立つなあ。

ほら、君は「??だとすれば」という仮定が読めないんだよね。背理法とか理解できてないんじゃないの?出来の悪い中学生とかで、「もし√2=p/qと既約分数で書けたとするとpもqも偶数になるが」とかいうと、「pもqも偶数なわけないだろ!」とか言って聞かないガキがいるよね。

あとさあ、まやかしまやかしで構わないけど、そういう意味なら俺は英語の「役に立つ」もまやかしだと思うがねえ。

とりあえず、「まやかし」と「役に立つ」をあんたはどういう基準で使い分けてるのか明示してくれ。でないと話にならん。

えーと、そういう主張をしたいのならまずソースよろ。

はあ?何のソースだよ。俺は君の主張を自然演繹しただけであって、敢えて言うならソースは君の発言だが。

俺の言ってるのは、ただの東大卒程度でエリートなんて呼ぶ必要ないだろ、ってことなんだが。毎年数百人も生まれるのに。

東大卒は毎年数千人だ。それで、MIT卒は何人いるか知ってる?ハーバードは?プリンストンは?スタンフォードは?オックスフォードは?ケンブリッジは?

本当に新天地を切り開くようなエリートってのは、せいぜい数人程度だろ。その数人にどういう教育をするかと考えた場合、国内でまかなおうなどと無駄な縄張り意識を発揮するよりは、とりあえず世界トップレベル大学に送り込めばいいんじゃないの、と。

天才信仰ですか。まあいいや。仮にそうだとしても、「年に数人」レベル人間「教育」なんておこがましいと思わんか。そんな人間はほっといても自分に最適な場所を探してくるし、そこが日本である可能性もあれば海外である可能性もある。

国を背負うほどのものでもない普通東大生数百人のレベルをギリギリにチューンすることに金を使うよりは、普通大学を出る普通の何万人のレベルを上げるほうが安上がりだし価値があるんじゃねえの、と。

誰も「普通東大生数百人のレベルをギリギリにチューンする」なんて言ってないし、そもそも東大生の中で「教育制度がもっとよければ俺はもっと偉くなれた!」なんて言ってる奴は落ちこぼれだけだよ。だから「普通東大生数百人のレベルをギリギリにチューンする」という発想自体がそもそも無意味

俺はFORTRANを主流だとは言ってないと思うがね。スタンダード(標準)だとは言ったが。主流と標準の違いは分かるよな?

いや、主流の座から滑り落ちたものを普通スタンダードとは呼ばないだろう。そう言えるからには、後続のものがスタンダードを一つの目標に据えて設計されたとかそういう事情が必要だ。ちなみに釘をさしておくが、別にこの主張に固執するつもりはないから反論は不要。否定してくれてかまわん。

でも、コアの計算部分がライブラリに分離されちゃうケースが増えると、ますます低水準処理がどうこういう意味がなくなるような。

出来合いのライブラリを使ってない研究者だって沢山いるし、そもそも計算アルゴリズム自体に工夫をする人だっているわけでな。その辺は計算の規模と計算機リソースの兼ね合いと、あるいは本人が計算機を好きか嫌いかなんていう、実に卑近な事情によって決まってくる。それこそ情報工学の研究者であっても、俺が例に挙げたパターン認識待ち行列研究者の中には計算機の実践的側面なんかに興味がなく、Cを使ってアセンブラまがいのコードを書き、新しい言語なんて覚える暇があったらもっと他のことをするとかなんとか言ってる人だって一定の比率で存在する。おわかり?あんたの言ってる「情報工学」は「コンピュータ工学」でしかないことに気付いてほしいな、いい加減に。そこだけ理解してもらえればあとはどうでもいい。そうすれば、あんたが噛み付いてる点自体が枝葉末節だってことにも気付くだろうし。

自分の書いたコード計算機のなかでどういう風に動くかというイメージを持っておけば見通しがよくなるだろ

前にも書いて綺麗に見ない振りされたけど、それ言語の選択と無関係だよね。

<<

元々の話覚えてるか?「低レベル寄りの言語を知識としてだけでも知らない人間に」云々という話だっただろう。どうも話が巧妙にずらされてる気がするんだが。たとえばいきなりJavaを覚えさせられた人間がそれがわかるとは到底思えない。ライブラリソースを読めるレベルになってはじめてわかることだろう、それは。

C++の話も同様。敢えて「C++らしい」処理を書けば計算量はどんどん増えて、例えば行列カプセル化して演算子オーバーロードしてなんてことやってたら計算時間が倍ぐらいになってもおかしくはないだろう。一晩で終わる計算が翌日の昼までかかるということになったら作業効率には歴然たる差が出るぞ。

2007-08-24

http://anond.hatelabo.jp/20070824002312

OOPプログラミングに有利なのには同意。

しかし、OOPは各オブジェクトの構造や関連に注目した記述となるため、自然言語との親和性が手続き型よりも低い。オブジェクト指向は視覚的なアプローチなのに対し、手続き型言語言葉による理解。一昔前の言葉で言えば、ランダムアクセスとシーケンシャルアクセス並の違いがある。

OOP人間界、、、人間世界観に沿っているのは同意するが、人間言葉に合わせているのではない。

また、「xxx.doThat()」を羅列しただけのようなプログラムOOPではない。それは手続き型だ。

ちなみに俺はOOPの利点は、メソッド・変数群の名前空間の整理(大規模プログラムを書いても名前が混乱しにくい)、データカプセル化(複数の違うフォーマットデータを同じもののように扱える。多態性)であると思っている。分析との親和性についてはオブジェクトデータフローペトリネットも大して差がない。

いや、なんていうか覚え立ての言葉をいろいろ使ってみたかっただけだ、すまん。

2007-08-22

anond:20070821161033

gdgdっぽいけど反論しておくと、超巨大画像云々はあくまで例です。

メモリ連続云々は、ミップマップ構築等で横方向だけでなく縦方向のアクセスも行われるとき、巨大な画像だとメモリアクセスキャッシュにうまくのらず酷いことになるという話。

それはともかくとして、カプセル化することによって内部実装を隠蔽し、変更可能にするというのはオブジェクト指向の大きなメリットだと思うのだけれど。

趣味で作る規模のプログラムでは内部実装さらけ出し状態でもあまり問題にならないということかな?確かに大学レポート提出用のプログラムC++で組んだ為にCで素直に組んだ場合と比べて非常に冗長になってしまった覚えはあるが。

2007-08-21

http://anond.hatelabo.jp/20070820212459

オブジェクト指向人間らしい書き方かには疑問の余地があるが、C言語とかでプログラミングしてると必然的に行き着く考え方だとは思う。

  • 関数を作成できる言語ならカプセル化の必要性には早晩気付く。
  • 変数にいったん代入せずに関数の返り値をダイレクトに他の関数に渡したりしてるうちに、array.compact().sort().reverse().to_str()みたいに数珠繋ぎにする、という発想がなんとなく見えてくる(Cっぽい書き方だとto_str(reverse(sort(compact(array))))、って感じか?)。
    • これが見えてくると、関数というのは特定の型に付随するものだ、みたいなイメージが出てくるから、型とメソッドが紐付けられているOOPの発想に心から納得できる。

オブジェクト指向ではない世界で、自分で設計しながらプログラミングした経験があるとオブジェクト指向の理解って早いんだよな。最初からオブジェクト指向ありきの書き方を教えちゃうと、その必然性が理解できないから、ついていけない人が発生する。

趣味プログラミングをやっていた人間と、そうでない人間の差はここに生まれる。必要に迫られたプログラミングしか経験していない人は最短距離しか進まないから、試行錯誤の末に先人の叡智と同じ結論に自分で達した人とは、理解の深さが違ってくる。

2007-04-29

オブジェクト指向って言葉も大昔からあるよ!

http://anond.hatelabo.jp/20070429155517

えー、IME 任せは微妙だなあ。めんどくさくてもオンオフぐらいしようよ。状況に応じた大文字小文字の選択もしづらい(できない?)し微妙だよ。少なくともそういう入力方法を叩くプログラマーは少なくないと思う。

19世紀はgoto文の時代だと思ってましたよ。

というかあまりオブジェクト指向プログラムってみたことないかも。

goto文不要論なんてもう何十年も議論され続けてるよ。大体 90年代終盤にはそこそこ普及してた Java は既に goto が実装されてなかったでしょ。今でも実装されないままだし。

それから Amazon.co.jp で「オブジェクト指向」を検索して「出版年月日が新しい順番」にソートして一番ケツに飛ぶ80年代オブジェクト指向本なんて山程出てくる。

というかあまりオブジェクト指向プログラムってみたことないかも。

なんかこのご時世におすすめないかな?

学生さんかなんかかな。もしオブジェクト指向の利点がまだ理解できてないなら、この話の増田ツリーのどっかにあったと思うけど、

  1. 関数も使わずベタ書き
  2. ベタ書きに絶望関数で手続き指向プログラミング
  3. スパゲッティ絶望オブジェクト指向プログラミングカプセル化モジュール
  4. 同じインターフェイスなのに姿を変えてしまうモジュール絶望インターフェイス概念に目覚める

ぐらいの経緯を辿ればまあオブジェクト指向の基本は掴めると思う。当然ある程度の大きさのプログラム(あんまり行数で言いたくないけど、せめて 1000行以上)を書かないと、各プロセス絶望を知ることはできないと思うけど。必要は発明の母。あとは平行して適当Amazon.co.jp で評価のいい本を読めばいい。

インターフェイス概念については、一般に知られているものだと C のストリームで理解できると思う。

FILE *fp;
fp = fopen("log.txt", "w");
fprintf(fp, "Starting log...\n");
fclose(fp);

これは log.txt ってファイルログを吐いてるのね。でも fprintf() ってのは次のような使い方もできる。

fprintf(stdout, "Starting log...\n");

stdout ってのは標準出力で、そこに fprintf でデータを渡すと(Windows の場合)コマンドプロンプトに文字列を表示する。ファイル標準出力は全く違うものだけど、インターフェイスが同じだから全く同じように出力処理を書けてるでしょ。これを発展させれば、

FILE *stream;

if (log_kind == LOG_FILE) {
  stream == fopen("log.txt", "w");
} else if (log_kind == LOG_STDOUT) {
  stream == stdout;
}

fprintf(stream, "Starting log...\n"); /* この時点で stream の種類を知る必要が無い! */

if (log_kind == LOG_FILE) {
  fclose(stream);
}

と書くことができる。年賀状大学受験合格通知は違うものだけど、初期化(書き方)が違うだけでインターフェイスポストに投函)は同じ、みたいな。それよりよく考えたら C を知ってるとは限らんよな。めんどくさくなってきた。あとはしりません。

2007-04-28

http://anond.hatelabo.jp/20070427093912

カプセル化が一番大きい気がするな。

変数管理が実に楽になる。

配列配列を格納してもまぁ同じといえば同じだけど、多次元配列はなんか気持ち悪い。

あと、関数も今まで専用の関数でもグローバルにおいておくしかなかったのが、専用のものとして定義できる。見通しがよくなっていい。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん