  |
はてなキーワード: カプセル化とは
言ってないけど。
Cから派生したCやJavaなどでやってるのはオブジェクト指向プログラミング。
クラスというものを作って、「カプセル化」、「継承」、「ポリモーフィズム」を三本の矢にして
これを提唱しているのはオブジェクト指向プログラミングを日本語で解説しているWikipediaなので間違いない。
現在の日本人に対してオブジェクト指向とは何かと問えばこれのことなので、これさえ押さえておけば会話に問題はない。
なまじっか真のオブジェクト指向に精通していると、英語版wikipediaでオブジェクト指向を学び、smalltalkなんかかじった日には、現代日本におけるオブジェクト指向がいかに偽物かわかるだろうが、奇異にみられるのはあなた自身であることを付け加えておく。
1a. 簡単なライブラリとかＡＰＩとかのオープンソースのやつを全部読めばよくね？例えばprintf()の中身とか。
あるいは自分で作ってみればよくね？
2. alloc()すると空きがあれば8byte確保してそのアドレスを返します。空きが無ければNULLを返します。
これくらいは自分で考えて作れるでしょ？
そういう事の積み重ねで高度なことをやってる。
1b. オブジェクト指向を知っているならカプセル化も知ってるでしょ？中身を知らなくても外のインタフェースだけ知っていれば使える。てか全ての中身を理解しようとしてたら何もアプリケーションなんて作れないです。
例えば俺ははてな匿名ダイアリーが裏でどのように動いているのかわからないけど、毎日記事を書いてる。これがカプセル化。
2a. 一般人に説明するには比喩を使うしかないでしょう。あと、その話題の領域でオブジェクト指向は関係なくね？
2b. それと、べつに「知らないことがあるけど使っている」のはITだけじゃないです。たとえば全身麻酔の原理とか最近までよくわかっていませんでした。航空力学もあんまりわかってないんじゃなかったっけ？なぜ飛行機が飛ぶのか。船も、何故かよくわからないけど速くなる装置があるんですよね。流体力学はよくわからかないです。こんぺいとうがトゲトゲになるメカニズムも解明されていない。べつにブラックボックスはＩＴだけじゃないです。
4. 例えば、長い時間をかけて改善を重ねて2015年の時点で最高の出来のWindows10が発売されたわけです。それを「今更出すな。1995年の時点でWindows10を出せ」とか言われても無理です。強くてニューゲームかよ。
あなたが考えるカプセル化ってなに？っていう議論をコード無しで議論する難しさというのと、じゃぁどの言語で議論するか？、では言語のインタプリタないしコンパイラは？難しい議論にどんどんなっていく。
本人がポエムつってんだから、ポエムでいいじゃん。そんなの人それぞれだろ。オブジェクト指向のカプセル化だなんて深淵な概念だし、この問いなんて哲学的であるとさえいえる。だいたい、カプセル化とは「データとそれを操作する手続を一つにして，オブジェクトの内部に隠ぺいすること」である、なんていったら、怒られるんじゃないか。隠蔽ってなんだよ。トートロジーかよ。この問題に正解したとしてカプセル化を使いこなせるわけでもないし、分かった気にさせるこけおどしでしかない。そういう霞みたいな文章をポエムっつんだよ。
※ ただし一般的にはポエムという語にはそういう下卑た意味合いはないと思います。 悪い意味でポエムという言葉を使うのは確かによくない風潮だと思うので今後は控えるようにします。俺は元増田ではありませんが。
「カプセル化等の用語を覚えること」と「良い設計ができること」を対比して、前者を批判しているのだから、良い設計ができる能力は「技術者としてのスキル」に含まれるとしか読み取れない。
「カプセル化等の用語を覚えること」と「良い設計ができること」を対比して、前者を批判しているのだから、良い設計ができる能力は「技術者としてのスキル」に含まれるとしか読み取れない。
情報処理技術者試験の資格を取っても実質的に得るものはありません。「実質的に」というのは、技術者としてのスキル向上に貢献するということであり、「報奨金が貰える」とか「履歴書に書ける」などの技術と無関係なものを含まないということです。
なぜ、情報処理技術者試験が役に立たないのかと言えば、出題内容が表面的な知識問題に極端に偏っており、本質的な理解を問うていないからです。たとえば、オブジェクト指向の三要素に「カプセル化」「継承」「ポリモルフィズム」がありますが、これらを御題目のように唱えていても何の意味もありません。しかし、情報処理技術者試験ではこれらの用語さえ覚えておけば、しっかり点になります。
https://www.fe-siken.com/s/kakomon/19_haru/q42.html
こんなのは単なるポエムであり、これが解けたところでコードが書けるわけでも、良い設計ができるわけでもありません。
数学で喩えれば、「加減法」とか「代入法」のような用語を暗記して、具体的な連立方程式の解き方は分からないようなものです。
ひどい問題は挙げればキリがありません。
https://www.ap-siken.com/s/kakomon/22_haru/q44.html
図の名称を答えさせる問題。図を読み取らせる問題なら、まだ理解できますが。そもそも、UMLなど別に技術者として知っておくべき知識でもありません。
https://www.fe-siken.com/s/kakomon/23_aki/q50.html
これも、こんな分類自体、覚えたところで何にもならないわけですが、その用語を答えさせる問題。いかに、この試験がエンジニアリングやプロジェクト管理の本質と関係ないかがよく分かります。
極めつけはこれ。
https://www.fe-siken.com/s/kakomon/17_haru/q52.html
地方の公立中学校の定期試験レベルのひどい問題です。出題者は、1だの2だの4だの7だのといった数字と語句の対応を覚えることが重要だと思っているのでしょうか。
つまり、ある種の発達障害ではない意識高い系ポエマーを認定するための試験であり、そもそも技術者のための試験ではないということです。あとは、中小企業診断士などを受ける人が試験免除を獲得するためとか。
そもそも、コンピュータやプロジェクトマネジメントの技術を、資格試験で勉強しようというのがピントがズレています。それらは既に良質な解説書が豊富にあるのだから、それで勉強すればいいのです。
あなたがどうしてもビッグマックを食べたいと思い、マクドナルドに入ったとする。「ビッグマックとコーラ」と頼むあなたに、当然のように店員はこう言うだろう。
何言ってんだ、ビッグマックとコーラだけでカロリー的に大冒険なのに、この上ポテトなんか食うわけねえだろ……そこまではいい。そこでどう答えるか、が問題なのだ。私ならこう答える。
「二品だけで結構です」
面倒なときは、何も言わずに右手を出して左右に振るかもしれない。けれど、世間では今こう答える人が多いのではないか。
「大丈夫です」
最初にこれを聞いたときに、妙な答え方をする人もいるものだと思った。「ポテトがなくても大丈夫」ということなのだろうが、「大丈夫」だけではその意向は伝わらないんじゃなかろうか。まあでも、その補完で問答としては成立するから、それ以上他人の言葉遣いにどうこう言う必要もないのかな……私は絶対に使わないけどね。それ位に思っていた。
そのうち、私はあるきっかけで転職することになった。次の仕事が始まるまでに二か月程の空きがある。何もしないでいるのも時間と金の無駄だしどうしよう、と思っていたら、丁度選挙が行われることになった。出口調査のバイトが出たので飛びついたわけだ。
出口調査はなかなかに過酷なバイトだった。丁度夏だったのだが、炎天下にボードを持って、
「すみません、○○○ですが、投票された内容に関しての調査にご協力いただけますか……」
と、市役所から出てくる人に声をかけ続ける。知らぬ人に声をかけることが苦にならない性質だからよかったが、最近の学生さんには辛い仕事かもしれない。むしろ私は、脱水症状になりかけたのと首筋の日焼けの方が辛かった。
そして、思いもかけないことに出喰わしたのだ。この手の調査なので、当然拒否されることが多々あるわけなのだけど、かなりの割合の人がこう言うのだ。
「大丈夫です」
え？どういう意味？何が「大丈夫」なの？……最初は意味が分からなかった。最初にそう言った三十代男性は、きょとんとして目前に立ち竦む私に目をやって、軽く舌打ちして大きく私を避けて歩き去った。何秒かの困惑の後にようやく、ああ、これは調査を拒否しているんだ、と理解した。どうも私の知らないうちに、このフレーズは他者を拒否する文脈の表現として定着していたらしい。大体四十代位までの人が多かったが、まあ皆さんこう仰るのだ。
その場は黙って淡々と対処していたわけだが、胸の中ではとにかく不可解だという思いが充満していた。この「大丈夫」は、何をどう補完しても何が言いたいのかが分からない。おそらく彼らは皆、自分が何か拒否するときに、無難な、角の立たない表現としてこの言葉を便利に使っていて、やがてその言葉の意味を考えないようになり、今回目前に立ちはだかる私にそれをぶつけたのだろう。最初の人は、きょとんとしている私が退かないのを見て、
「なんだこいつ、ちょっと丁寧に言ってやってるのに」
と苛立ち、舌打ちしたのだろう。惰性で意味の通らない言葉を平気で使っているなどとは考えもせずに。
飲食店でもコンビニでも、その後もこのフレーズを耳にすることがあるのだが、その度に、あの舌打ちされた日のことを思い出す。ああ、そうやってカプセル化したフレーズを投げつけてるのね。それがあなたたちの本質なのね、と思いながら。いつか、こう言ってやりたい、と思いながら。
まあどうせ通じもしないんだろうが。
【後記】
東京03のネタって話は知らなかった。ということは……と思いつつ、改めて辞書をひくと、
１ あぶなげがなく安心できるさま。強くてしっかりしているさま。「地震にも大丈夫なようにできている」「食べても大丈夫ですか」「病人はもう大丈夫だ」
２ まちがいがなくて確かなさま。「時間は大丈夫ですか」「大丈夫だ、今度はうまくいくよ」
[補説]近年、形容動詞の「大丈夫」を、必要または不要、可または不可、諾または否の意で相手に問いかける、あるいは答える用法が増えている。「重そうですね、持ちましょうか」「いえ、大丈夫です（不要の意）」、「試着したいのですが大丈夫ですか」「はい、大丈夫です（可能、または承諾の意）」など。
これですか。この辞書の文例ならば、
「（持っていただかなくとも私は）大丈夫」
でも、出口調査の依頼に対して「大丈夫」というのは、何をどうしても通らないと思うのですよ。
って……意味通りませんよね。出口調査を必要としているのは聞いている側なのだから。では、
初投稿につき至らない点があるかもしれないが容赦してほしい。が、指摘は受け入れる所存。
俺はとあるUIコンポーネントライブラリ開発者だが、先日議論されたあるコンポーネントの設計について悩み続けている。
これを読んでくれた人の設計センスや知識、経験から、第三者の率直な意見を聞きたい。
悩んでいることの概要は、
ざっくり言えばこの2択だ。
どちらも間違った考えだとは思えないので、そもそもどちらかの捉え方がおかしいのだと思う。そういった意見も聞きたいが、まずは読んでみてほしい。
設計対象のコンポーネントは、よくある触って動かせるスライダーである。下記リンク先のようなものだ。
https://material-ui.com/components/slider/
加えて、下記も前提としてほしい。
Sliderというコンポーネントクラスを作るとして、これらの構成要素をライブラリ-ユーザー間でどう分担するかという点で、AさんとBさんで意見が割れた。
それぞれの意見を要約すると下のようになる。Aさんはカプセル化を狙い、Bさんは単一責任原則を重視している。
画面 └ Slider (ユーザーが作成) ├ 背景バー ├ ノブ └ 進捗バー
Aさん案の場合だと、Sliderクラス内部で勝手にそれぞれの要素を作成し、自分の子にするなりして表示する。
画面 ├ 背景バー (ユーザーが作成) ├ ノブ (ユーザーが作成) ├ 進捗バー (ユーザーが作成) └ Slider (ユーザーが作成) ├ 背景バーへの参照 (ユーザーが指定) ├ ノブへの参照 (ユーザーが指定) └ 進捗バーへの参照 (ユーザーが指定)
Bさん案では、ユーザーが構成要素それぞれを作成し、Sliderにそれを食わせる。
SliderはAさん案のように各構成要素を構築する必要はなく、ノブの移動や進捗バーのサイズ変更だけすれば良い。
Aさんはユーザーが制御する必要のない背景バー、ノブ、進捗バーの構成を隠蔽(カプセル化)しようと提案したが、
Aさん案に対しBさんは、単一責任原則の観点から「各構成要素の構築や表示」という責任を外すべきだと訴え、Bさん案を提示した。
またBさんは、コンポーネントはユーザーが扱うべきものであり、コンポーネントがコンポーネントを内部で勝手に使用しているのは混乱を招くとの見方もしている。
ただしAさんの考えの通り、実際に各要素の構成をユーザーが制御するユースケースは存在しない。
その場では「単一責任原則」を持ち出したBさん案で決定された。
しかしなんとなくAさん案派だった俺はモヤモヤしたまま家に帰り、本当に単一責任原則に反しているのか、カプセル化よりも大事なのかと悩み続けている。
ここまでが事実となる。
さて本当にBさんが正しかったのか、あるいは単一責任原則の捉え方が間違っているのか、はたまた・・
第三者による意見が聞きたい。周りのコメントに左右されない率直な意見が望ましい。なんとなくな意見も歓迎する。
満たすべき機能は見た目だけではないがそこは置いておいてほしい。
setterは使わない、getterは使わない
その他色々と「やらないほうが良い事」はあれど
勇者に学ぶオブジェクト指向プログラミング(Java)みたいに、分かりやすい例は無いの？
https://qiita.com/nrslib/items/73bf176147192c402049
こうすれば最高！という例が無かった…。
| 時間 | 記事数 | 文字数 | 文字数平均 | 文字数中央値 |
|---|---|---|---|---|
| 00 | 90 | 15050 | 167.2 | 49.5 |
| 01 | 102 | 13383 | 131.2 | 44 |
| 02 | 31 | 2581 | 83.3 | 43 |
| 03 | 13 | 1893 | 145.6 | 97 |
| 04 | 11 | 5466 | 496.9 | 102 |
| 05 | 12 | 1399 | 116.6 | 62 |
| 06 | 18 | 1116 | 62.0 | 35.5 |
| 07 | 70 | 4527 | 64.7 | 49.5 |
| 08 | 39 | 2868 | 73.5 | 53 |
| 09 | 124 | 11971 | 96.5 | 47 |
| 10 | 181 | 17343 | 95.8 | 51 |
| 11 | 154 | 15019 | 97.5 | 46 |
| 12 | 198 | 13113 | 66.2 | 34 |
| 13 | 157 | 11796 | 75.1 | 39 |
| 14 | 119 | 8220 | 69.1 | 48 |
| 15 | 124 | 10184 | 82.1 | 34.5 |
| 16 | 196 | 17555 | 89.6 | 39 |
| 17 | 156 | 10290 | 66.0 | 33 |
| 18 | 130 | 9730 | 74.8 | 33.5 |
| 19 | 121 | 7313 | 60.4 | 28 |
| 20 | 131 | 12374 | 94.5 | 43 |
| 21 | 153 | 17111 | 111.8 | 54 |
| 22 | 77 | 13890 | 180.4 | 35 |
| 23 | 90 | 9153 | 101.7 | 52 |
| 1日 | 2497 | 233345 | 93.5 | 40 |
歪めろ(14), 折れろ(4), あまえんぼ(4), 桐生(3), スクールカウンセラー(3), リッツ(3), ルルブ(5), カプセル化(6), 応援歌(5), ほなら(13), 政権運営(5), 戸田真琴(3), 嗜好(31), 分散(11), 只(8), 折れ(19), 民主党(11), 譲ら(6), 民主(7), 悪いっ(7), 在日(5), エヴァ(6), 内面(10), 人格(33), 自民(13), 欲望(15), プレッシャー(7), 政権(16), キャンペーン(7), 役所(10), 野党(15), 自民党(16), ロボット(13), 年金(19), 尊重(16), 安倍(14), 罵倒(13), 新卒(10)
■そうなの？ってなる情報を教えて欲しい /20190703111248(17), ■なんでみんな酢を飲まないの？ /20190703072316(15), ■下着を売っていたJKのブスが前向きになった話 /20190703013656(12), ■KKOがモテるためにやったこと /20190703085937(11), ■戸田真琴さんのnoteを読んだ分散SNSユーザ /20190703040517(11), ■仲良しだけどセックスできなくなったから離婚したい /20190628154225(11), ■20代ニートだけど老後2000万問題で歓喜のダンス踊ったわ /20190703012548(11), ■ /20190703101504(8), ■ツイッター絵師とかが「いくら友達でも無料で書かなきゃいけないの？」とか言うけど /20190703085707(7), ■老後のために小説書いたら誰にも読まれなくて詰んだ /20190703202308(7), ■お会計の時にいつもありがとうございますと言われた /20190703123611(7), ■「自分が障害者だった〜」は釣りでした。みんなありがとう。 /20190703165854(6), ■「◯歳で結婚してない奴はおかしい」論はそろそろ無理 /20190702084110(6), ■ /20190703101028(6), ■『アスファルトに咲く花のように』はどこにかかっているのか /20190703181744(6), ■もうご飯食べに行くお店のネタがない /20190703101703(6), ■プログラムに強い増田さん！C#のカプセル化等について教えて～ /20190703172738(6), ■何でエンジニアってちゃんと会社来ないの？ /20190703204618(6), ■実際40過ぎで結婚してない人はおかしいよね /20190701233108(5), ■増田って夫婦の財布どうしてんの /20190703123031(5), ■おじちゃんだけどエッチな目で見ないでほしい /20190703183656(5), ■アフィブロガーだが生きる価値を見失った /20190703203324(5), ■問１「カンナ」「だけの」「人生だった」を使って文を作れ /20190703153054(5), ■生理用品に軽減税率が適用されない！ /20190703183611(5), ■C#のクラスのまとめ方?について良くわかんない /20190703085703(5), ■結婚予定の女がモテるためにやったこと /20190703093551(5), ■妊婦検診のたび、あそこにモノを入れられるんだ /20190703145736(5)
6410583(2226)
こりゃあたちの悪い書き方を知らんからカプセル化のありがたみがわかんないんだよなきっと
環境がC#とかで、人物一人分の情報にクラスを作る気があって、Personには体重とか身長とかがあって、みたいなわりときちんとした理屈があればああそれはね、それぞれプロパティにしとけば大丈夫、なんてので大丈夫。
地獄はこうだ。
char Person[200]; /* 0から19までを名字に使います */ /* 20から38までを名前に使います */ /* 39は年号コードです 0: 明治、 */ /* 40は生年です */ /* ... */
そしてソースコードの中にいきなり現れる
Person[70] = 35;
なにやってんだこれー！わかんねえぞこれー！
こういうことがないように、カプセル化するんだ。
New Person person とかやるのだろうか。
Person クラスを作って、プライベートなメンバ変数にそれらの情報をいれる。
好みのプログラミング言語があればそっちに合わせるから言ってくれ。ここは適当な感じで書いておく。
値を決めるのがcaller側でもいいなら、hasXXX、isXXXで当然bool値を返してそのbool値をもとにAかBを設定する。
if hasXXX(x) { r = A } else { r = B }
みたいな感じ。
値を決めるのがcallee側なら、initializeとかnewとかがいいだろうね。
そんでもって、
package module
func New(x) returnType { if hasXXX(x) { return A } else { return B }}
みたいな感じ。
どちらがいいかはカプセル化の観点から決まると思う。callee側のモジュールに強く依存したデータを返すなら、callee側で値を決める。そこに何のデータが入っているかcallerは関知せず、callee側のモジュールだけがそのデータを操作できる。
別にcaller側でも作れるようなデータなら、caller側でやる。
さらに言っておくと、関数名を何にするかはその言語でのお作法とかコーディング規約(不文律的な規約も含む)とかで決まるような気もする。何もなしで決めるならこうするよって例だけれど、すでに似たようなことをしているほかの関数があるなら、それに従うほうがいいだろうね。そいつらがcalculateならcalculateにしたほうがわかりやすいだろうし。
