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

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

2020-05-29

anond:20200529165604

きちんとカプセル化して分割してある>>分割されてない>>>>>>>>>>記述だけ分割されて何がどこに影響してるか分からん

みたいな感じだよね。

2020-05-28

あなたが考えるカプセル化ってなに?っていう議論コード無しで議論する難しさというのと、じゃぁどの言語議論するか?、では言語インタプリタないしコンパイラは?難しい議論にどんどんなっていく。

掲示板からざつに、要点だけを言った場合に、あなたにとてカプセル化とは?

anond:20200528082941

あなたの言う通りだよ。

カプセル化という言葉を知っていればカプセル化を使いこなせるわけじゃないけど、だからといってカプセル化という言葉すら知らない人が使えているはずがない。そんなヤツは論外。ただの無知

からオブジェクト指向について全く無知なのかそうでないのかの判別には使えるね。そういう試験だよね、これは。

anond:20200528080145

UMLについてはまるっきりアホだと思うから多めに見といてあげるんだけど

オブジェクト指向カプセル化うんぬんが不要ってほうがわけわからない。

オブジェクト指向理解してるかどうか計る上で、カプセル化って言葉は知らないけど

カプセル化意識して設計コーディングできることなんてあるのかな?

2020-05-27

オブジェクト指向が分からないあなたへ

どうも、都内の某企業に勤めるフルスタックエンジニアです。この記事では、ITの非専門家に向けて、オブジェクト指向解説をしたいと思います

小学生プログラミング教育が開始されたり、AIIoTなどの技術が身近になった今日オブジェクト指向理解しておくことは極めて重要です。なぜならば、オブジェクト指向ITエンジニアとっての「共通言語」であって、今やあらゆるソフトウェア技術オブジェクト指向の上に成り立っているからです。したがって、オブジェクト指向理解すれば、ITのすべての分野の基礎が身についたことになります。難しい概念がいくつか出てきますが、分かりやす解説するので頑張ってついてきて下さい!

オブジェクト指向とは

まず、オブジェクト指向とは何かを解説します。オブジェクト(object)とは、「モノ」のことです。言い換えれば「モノ指向」です。つまりコンピュータのようなバーチャル対象ではなく、現実のモノをモデルプログラミングしようというのが、オブジェクト指向定義です。この考えは、今流行りのIoT(Internet of Things = モノのインターネット)にも取り入れられ、爆発的に影響力を増しています

モノという考え方は、18世紀哲学者カントに遡りますカント純粋理性批判において、理性と経験によって認識できる以前の「物自体」という概念提唱し、大陸合理主義イギリス経験主義を統一しました。オブジェクト指向におけるモノとは、カントのいう物自体です。したがって、オブジェクト指向世界の真理を記述できます。そのため、コンピュータというバーチャル世界を超えて、IoTを作ることが可能になります

現代プログラミング言語オブジェクト指向サポートする最も代表的言語Javaです。これに対して、CやC++といった旧来の言語関数型言語といい、現在では顧みられることはありません。また、JavaMicrosoftであるC#や、Javaに組み込んで使うマクロ言語であるJavaScriptなどもオブジェクト指向言語であり、プロエンジニアは好んでよく使います。一方、学生向けの教育用言であるPythonRubyなども、一応オブジェクト指向サポートしています。これらはプログラミング入門には適していますが、実務で使われることはありません。

オブジェクト指向の三要素

オブジェクト指向で最も重要な要素は

の3つです。これらを駆使することで、食卓から宇宙までを豊かにするIoTを作ることが可能になるのです。一つ一つ解説していきます

カプセル化

カプセル化とは、実装利用者から見えなくすることです。

たとえば、ソフトウェア脆弱性があったとしても、カプセル化をしていれば、利用者からはその脆弱性は無いように見えます。したがって、オブジェクト指向で作られたソフトウェアには、セキュリティ上の問題存在しません。

また、IoTを用いていない従来の家電製品などは、ボタンがたくさんあったりして操作がとても複雑です。カプセル化を応用すると、この操作を全く包み隠してしまっても、機械が使えるようになりますiPhoneスマートスピーカータッチパネルや声認識などで操作できるのは、カプセル化のおかげです。逆に、ガラケーボタンがたくさんある家電製品などは、オブジェクト指向(=IoT)で作られていません。

継承

継承とは、あるオブジェクト性質を別のオブジェクトが引き継ぐことです。

たとえば、人間は「歩く」「喋る」などの動作を行え、鳥は「飛ぶ」「鳴く」などの動作が行えますオブジェクト指向世界では、鳥を継承することで、人間が飛んだり、鳴いたりすることができるようになります。これを応用したのが、VRVirtual Reality=仮想現実)です。

また、iPhone携帯電話であるにも関わらず、ツイッターをみたり、アマゾンで買い物ができたりするのもオブジェクト指向のおかげです。つまりiPhoneツイッターアマゾン継承しているのです。それだけではなく、iPhone時計や財布、メモ帳など、現実世界の多くのもの継承しています

ちょっと抽象的になりますが、この考えを突き詰めると、次のような応用が生まれます。将来必要となるすべての機能実装したオブジェクトを一度作っておけば、後続の開発者はそれを継承するだけで、新規の開発なしに新機能を追加することができます。このような性質を「再利用性」といい、ソフトウェア開発では極めて重要な考え方となります継承はこの再利用性をもたらすために、ソフトウェア開発のスピードを爆発的に加速させ、現代ITの発展の原動力となりました。

ポリモーフィズム

ポリモーフィズムは、日本語では「多態性」と言います多態性とは、読んで字のごとく、多くの状態を持つということです。

オブジェクト指向では、多くの状態を持つことができます。一方、C言語などの関数型言語状態を持つことができません。関数型言語では、プログラムを関数(つまり入力と出力をもつブラックボックス)の合成として記述します。関数は、中学校数学で学んだように、入力に対して出力が一意に定まるので、状態を持つことができないのです。この制約を「参照透過性」と言います

オブジェクト指向では、参照透過性の制約がないため、プログラマは自由コードを書くことができ、関数型言語と比べて遥かに生産的です。また、上に述べたように状態を持てるということは、プログラムの入力に対する出力を無数に持てるということです。この応用がAI(Artificial Intelligence=人工知能)です。AIが、まるで人間が考えたかのように答えを出すことができるのは、ポリモーフィズムにより無数の出力を得ることができるからなのです。

おわりに

全体的に難解な記事となってしまいましたが

部分的にでも理解すればIT世界を見る目が変わるはずです。

うさんくさい情報に惑わされずに、このような本物の知識を身につけ

そして、皆さんにはIT未来を見通せる人材になっていただければと思います

anond:20200526113816

良門だと思うよ、私たち団体ではカプセル化をなんと呼んでいるかちゃんと覚えて団体ごとに意味を使い分けられてますか?というのは情報処理世界では必要能力

2020-05-26

anond:20200526184755

本人がポエムつってんだからポエムでいいじゃん。そんなの人それぞれだろ。オブジェクト指向カプセル化だなんて深淵概念だし、この問いなんて哲学的であるとさえいえる。だいたい、カプセル化とは「データとそれを操作する手続を一つにして,オブジェクトの内部に隠ぺいすること」である、なんていったら、怒られるんじゃないか隠蔽ってなんだよ。トートロジーかよ。この問題に正解したとしてカプセル化を使いこなせるわけでもないし、分かった気にさせるこけおどしでしかない。そういう霞みたいな文章ポエムつんだよ。

※ ただし一般的にはポエムという語にはそういう下卑た意味合いはないと思います。 悪い意味ポエムという言葉を使うのは確かによくない風潮だと思うので今後は控えるようにします。俺は元増田ではありませんが。

anond:20200526164814

カプセル化の考え方が不要なんてどこにも書いてないんだけど。

「表面的な用語の暗記」を批判するのと、「出題分野そのもの不要」という話が区別できないの?

anond:20200526164413

カプセル化等の用語を覚えること」と「良い設計ができること」を対比して、前者を批判しているのだから、良い設計ができる能力は「技術者としてのスキル」に含まれるとしか読み取れない。

カプセル化等の考え方やUML露骨設計に絡む能力なんでこれらを不要とするのは

設計スキルを向上させる目的に沿わない。

コーディングだけを重視する設定じゃないと矛盾する。

anond:20200526152341

カプセル化等の用語を覚えること」と「良い設計ができること」を対比して、前者を批判しているのだから、良い設計ができる能力は「技術者としてのスキル」に含まれるとしか読み取れない。

単純にお前の国語力が低いからそう思えるだけ。

情報処理技術者試験なんて何の役にも立ちません

情報処理技術者試験資格を取っても実質的に得るものはありません。「実質的に」というのは、技術者としてのスキル向上に貢献するということであり、「報奨金が貰える」とか「履歴書に書ける」などの技術無関係ものを含まないということです。

なぜ、情報処理技術者試験が役に立たないのかと言えば、出題内容が表面的な知識問題に極端に偏っており、本質的理解を問うていないからです。たとえば、オブジェクト指向の三要素に「カプセル化」「継承」「ポリモルフィズム」がありますが、これらを御題目のように唱えていても何の意味もありません。しかし、情報処理技術者試験ではこれらの用語さえ覚えておけば、しっかり点になります

オブジェクト指向におけるカプセル化説明したものはどれか。

  1. 同じ性質もつ複数オブジェクト抽象化して,整理すること
  2. 基底クラス性質派生クラスに受け継がせること
  3. クラス間に共通する性質抽出し,基底クラスを作ること
  4. データとそれを操作する手続を一つにして,オブジェクトの内部に隠ぺいすること

https://www.fe-siken.com/s/kakomon/19_haru/q42.html

こんなのは単なるポエムであり、これが解けたところでコードが書けるわけでも、良い設計ができるわけでもありません。

数学で喩えれば、「加減法」とか「代入法」のような用語を暗記して、具体的な連立方程式の解き方は分からないようなものです。

ひどい問題は挙げればキリがありません。

UML2.0において,オブジェクト間の相互作用時間の経過に注目して記述するものはどれか。

  1. アクティティ
  2. コミュニケーション
  3. シーケンス
  4. ユースケース

https://www.ap-siken.com/s/kakomon/22_haru/q44.html

図の名称を答えさせる問題。図を読み取らせる問題なら、まだ理解できますが。そもそもUMLなど別に技術者として知っておくべき知識でもありません。

要求分析から実装までの開発プロセスを繰り返しながら,システムを構築していくソフトウェア開発手法はどれか。

  1. ウォータフォールモデル
  2. スパイラルモデル
  3. プロトタイピングモデル
  4. リレーショナルモデル

https://www.fe-siken.com/s/kakomon/23_aki/q50.html

これも、こんな分類自体、覚えたところで何にもならないわけですが、その用語を答えさせる問題いかに、この試験エンジニアリングプロジェクト管理本質関係いかがよく分かります

極めつけはこれ。

次の画像符号化方式のうち,携帯電話などの低速回線用の動画像の符号化に用いられるものはどれか。

  1. JPEG
  2. MPEG-1
  3. MPEG-2
  4. MPEG-4

https://www.fe-siken.com/s/kakomon/17_haru/q52.html

地方公立中学校定期試験レベルのひどい問題です。出題者は、1だの2だの4だの7だのといった数字語句対応を覚えることが重要だと思っているのでしょうか。

情報処理技術者試験で測れる能力は以下の2つだけです。

  • 内容の理解はともかく、ある用語を「聞いたことがある」かどうか。
  • 150分間、落ち着いて椅子に座っていられるかどうか。

まり、ある種の発達障害ではない意識高い系ポエマー認定するための試験であり、そもそも技術者のための試験ではないということです。あとは、中小企業診断士などを受ける人が試験免除を獲得するためとか。

そもそもコンピュータプロジェクトマネジメントの技術を、資格試験勉強しようというのがピントがズレています。それらは既に良質な解説書が豊富にあるのだから、それで勉強すればいいのです。

2020-03-04

大丈夫」?

あなたがどうしてもビッグマックを食べたいと思い、マクドナルドに入ったとする。「ビッグマックコーラ」と頼むあなたに、当然のように店員はこう言うだろう。

ポテトはいかがですか?」

何言ってんだ、ビッグマックコーラだけでカロリー的に大冒険なのに、この上ポテトなんか食うわけねえだろ……そこまではいい。そこでどう答えるか、が問題なのだ。私ならこう答える。

「二品だけで結構です」

面倒なときは、何も言わず右手を出して左右に振るかもしれない。けれど、世間では今こう答える人が多いのではないか

大丈夫です」

最初にこれを聞いたときに、妙な答え方をする人もいるものだと思った。「ポテトがなくても大丈夫」ということなのだろうが、「大丈夫」だけではその意向は伝わらないんじゃなかろうか。まあでも、その補完で問答としては成立するから、それ以上他人言葉遣いにどうこう言う必要もないのかな……私は絶対に使わないけどね。それ位に思っていた。

そのうち、私はあるきっかけで転職することになった。次の仕事が始まるまでに二か月程の空きがある。何もしないでいるのも時間と金無駄だしどうしよう、と思っていたら、丁度選挙が行われることになった。出口調査バイトが出たので飛びついたわけだ。

出口調査はなかなかに過酷バイトだった。丁度夏だったのだが、炎天下ボードを持って、

すみません、○○○ですが、投票された内容に関しての調査にご協力いただけますか……」

と、市役所から出てくる人に声をかけ続ける。知らぬ人に声をかけることが苦にならない性質からよかったが、最近学生さんには辛い仕事かもしれない。むしろ私は、脱水症状になりかけたのと首筋の日焼けの方が辛かった。

そして、思いもかけないことに出喰わしたのだ。この手の調査なので、当然拒否されることが多々あるわけなのだけど、かなりの割合の人がこう言うのだ。

大丈夫です」

え?どういう意味?何が「大丈夫」なの?……最初意味が分からなかった。最初にそう言った三十代男性は、きょとんとして目前に立ち竦む私に目をやって、軽く舌打ちして大きく私を避けて歩き去った。何秒かの困惑の後にようやく、ああ、これは調査拒否しているんだ、と理解した。どうも私の知らないうちに、このフレーズ他者拒否する文脈表現として定着していたらしい。大体四十代位までの人が多かったが、まあ皆さんこう仰るのだ。

その場は黙って淡々対処していたわけだが、胸の中ではとにかく不可解だという思いが充満していた。この「大丈夫」は、何をどう補完しても何が言いたいのかが分からない。おそらく彼らは皆、自分が何か拒否するときに、無難な、角の立たない表現としてこの言葉を便利に使っていて、やがてその言葉意味を考えないようになり、今回目前に立ちはだかる私にそれをぶつけたのだろう。最初の人は、きょとんとしている私が退かないのを見て、

「なんだこいつ、ちょっと丁寧に言ってやってるのに」

と苛立ち、舌打ちしたのだろう。惰性で意味の通らない言葉を平気で使っているなどとは考えもせずに。

飲食店でもコンビニでも、その後もこのフレーズを耳にすることがあるのだが、その度に、あの舌打ちされた日のことを思い出す。ああ、そうやってカプセル化したフレーズを投げつけてるのね。それがあなたたちの本質なのね、と思いながら。いつか、こう言ってやりたい、と思いながら。

あんた、頭、大丈夫?」

まあどうせ通じもしないんだろうが。

【後記】

東京03ネタって話は知らなかった。ということは……と思いつつ、改めて辞書をひくと、

1 あぶなげがなく安心できるさま。強くてしっかりしているさま。「地震にも大丈夫なようにできている」「食べても大丈夫ですか」「病人はもう大丈夫だ」

2 まちがいがなくて確かなさま。「時間大丈夫ですか」「大丈夫だ、今度はうまくいくよ」

[補説]近年、形容動詞の「大丈夫」を、必要または不要、可または不可、諾または否の意で相手に問いかける、あるいは答える用法が増えている。「重そうですね、持ちましょうか」「いえ、大丈夫です(不要の意)」、「試着したいのですが大丈夫ですか」「はい大丈夫です(可能、または承諾の意)」など。

[副]まちがいなく。確かに。「大丈夫約束は忘れないよ」

これですか。この辞書の文例ならば、

「(持っていただかなくとも私は大丈夫

文意は通りそうな気がする。私の書いたマクドナルドの例も、

「(ポテトなしでも私は大丈夫

でも、出口調査の依頼に対して「大丈夫」というのは、何をどうしても通らないと思うのですよ。

「(出口調査に答えなくても私は大丈夫

って……意味通りませんよね。出口調査必要としているのは聞いている側なのだから。では、

「(出口調査に答えなくてもあなた大丈夫

だったら……いや大丈夫じゃねーよ。結局、誰の何がどう大丈夫なのか、皆目分からないのですよ。

2019-08-07

単一責任原則vsカプセル化

投稿につき至らない点があるかもしれないが容赦してほしい。が、指摘は受け入れる所存。

俺はとあるUIコンポーネントライブラリ開発者だが、先日議論されたあるコンポーネント設計について悩み続けている。

これを読んでくれた人の設計センス知識経験から第三者の率直な意見を聞きたい。

悩んでいることの概要は、

ざっくり言えばこの2択だ。

どちらも間違った考えだとは思えないので、そもそもどちらかの捉え方がおかしいのだと思う。そういった意見も聞きたいが、まずは読んでみてほしい。

設計対象コンポーネントは、よくある触って動かせるスライダーである。下記リンク先のようなものだ。

https://material-ui.com/components/slider/

前提として、このコンポーネント構成要素を下記とする。

加えて、下記も前提としてほしい。

Sliderというコンポーネントクラスを作るとして、これらの構成要素をライブラリ-ユーザー間でどう分担するかという点で、AさんとBさんで意見割れた。

それぞれの意見を要約すると下のようになる。Aさんはカプセル化を狙い、Bさんは単一責任原則を重視している。

Aさんの構成イメージは下記のような感じ

画面
└ Slider         (ユーザー作成)
   ├ 背景バーノブ
   └ 進捗バー

Aさん案の場合だと、Sliderクラス内部で勝手にそれぞれの要素を作成し、自分の子にするなりして表示する。

Bさんの構成イメージは下記のような感じ

画面
├ 背景バー     (ユーザー作成)
├ ノブ         (ユーザー作成)
├ 進捗バー     (ユーザー作成)
└ Slider       (ユーザー作成)
   ├ 背景バーへの参照    (ユーザー指定)
   ├ ノブへの参照        (ユーザー指定)
   └ 進捗バーへの参照    (ユーザー指定)

Bさん案では、ユーザー構成要素それぞれを作成し、Sliderにそれを食わせる。

SliderはAさん案のように各構成要素を構築する必要はなく、ノブの移動や進捗バーサイズ変更だけすれば良い。

Aさんはユーザー制御する必要のない背景バーノブ、進捗バー構成隠蔽(カプセル化)しようと提案したが、

Aさん案に対しBさんは、単一責任原則観点から「各構成要素の構築や表示」という責任を外すべきだと訴え、Bさん案を提示した。

またBさんは、コンポーネントユーザーが扱うべきものであり、コンポーネントコンポーネントを内部で勝手使用しているのは混乱を招くとの見方もしている。

ただしAさんの考えの通り、実際に各要素の構成ユーザー制御するユースケース存在しない。

その場では「単一責任原則」を持ち出したBさん案で決定された。

しかしなんとなくAさん案派だった俺はモヤモヤしたまま家に帰り、本当に単一責任原則に反しているのか、カプセル化よりも大事なのかと悩み続けている。

ここまでが事実となる。

さて本当にBさんが正しかったのか、あるいは単一責任原則の捉え方が間違っているのか、はたまた・・

第三者による意見が聞きたい。周りのコメントに左右されない率直な意見が望ましい。なんとなくな意見も歓迎する。

満たすべき機能は見た目だけではないがそこは置いておいてほしい。

以下は個人的意見とか思ったことや疑問など。

2019-07-04

オブジェクト指向」「カプセル化」とかを「はてな」で例えてみて

C#勉強中。

オブジェクト指向とか、カプセル化とか考えてたら訳が分からなくなってきた。

増田とか、はてなとかで例えてみてくれないかな。




無理か。

anond:20190704110836

オブジェクト指向カプセル化って二十年くらい前に流行った概念な気がするけどまだ息してるのか、驚いた。

C#始めた増田だけど、オブジェクト指向カプセル化分からん

setterは使わない、getterは使わない

その他色々と「やらないほうが良い事」はあれど

どう書けばいいのかについては特に記載が無い。

勇者に学ぶオブジェクト指向プログラミング(Java)みたいに、分かりやすい例は無いの?

https://qiita.com/nrslib/items/73bf176147192c402049

これ見たけど、ダメダメダメダメだけで

こうすれば最高!という例が無かった…。

[]2019年7月3日水曜日増田

時間記事文字数文字数平均文字数中央値
009015050167.249.5
0110213383131.244
0231258183.343
03131893145.697
04115466496.9102
05121399116.662
0618111662.035.5
0770452764.749.5
0839286873.553
091241197196.547
101811734395.851
111541501997.546
121981311366.234
131571179675.139
14119822069.148
151241018482.134.5
161961755589.639
171561029066.033
18130973074.833.5
19121731360.428
201311237494.543
2115317111111.854
227713890180.435
23909153101.752
1日249723334593.540

本日の急増単語 ()内の数字単語が含まれ記事

歪めろ(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), ■問1「カンナ」「だけの」「人生だった」を使って文を作れ /20190703153054(5), ■生理用品に軽減税率適用されない! /20190703183611(5), ■C#クラスのまとめ方?について良くわかんない /20190703085703(5), ■結婚予定の女がモテるためにやったこと /20190703093551(5), ■妊婦検診のたび、あそこにモノを入れられるんだ /20190703145736(5)

増田合計ブックマーク数 ()内の数字は1日の増減

6410583(2226)

2019-07-03

anond:20190703172738

こりゃあたちの悪い書き方を知らんからカプセル化のありがたみがわかんないんだよなきっと

環境C#とかで、人物一人分の情報クラスを作る気があって、Personには体重とか身長とかがあって、みたいなわりときちんとした理屈があればああそれはね、それぞれプロパティにしとけば大丈夫、なんてので大丈夫

地獄はこうだ。

char Person[200];
/* 0から19までを名字に使います */
/* 20から38までを名前に使います */
/* 39は年号コードです 0: 明治、 */
/* 40は生年です */
/* ... */

そしてソースコードの中にいきなり現れる

Person[70] = 35; 

なにやってんだこれー!わかんねえぞこれー!

こういうことがないように、カプセル化するんだ。

anond:20190703172738

「【C#】「カプセル化」をもう一度学ぶ」ってのにあった。

New Person person とかやるのだろうか。

プログラムいから参照方法は分からない。

anond:20190703172738

長いことやってるけど、俺未だにカプセル化がわからない

 

継承とかする前提の思想になってるからかなぁ

そんな重要な話に思えないんだけど、むしろ「そりゃそうなるだろ」みたいなテクニック的な話で

anond:20190703172738

Person クラスを作って、プライベートなメンバ変数にそれらの情報をいれる。

あとは、せったーゲッターで他から変えられるようにすれば、最低限のカプセル化完了だよ。

プログラムに強い増田さん!C#カプセル化等について教えて~

Personっていう情報があったとして

名字

名前

・生年月日

・年齢

身長

体重

とかのデータがあるとするじゃん?

どうやってカプセル化するの?

どうやって他のクラス(?)から参照するの?

2019-06-05

anond:20190604104819

もうちょっとかみ砕いて説明したほうがよさそうだな。

好みのプログラミング言語があればそっちに合わせるから言ってくれ。ここは適当な感じで書いておく。

値を決めるのがcaller側でもいいなら、hasXXX、isXXXで当然bool値を返してそのbool値をもとにAかBを設定する。

if hasXXX(x) { r = A } else { r = B }

みたいな感じ。

値を決めるのがcallee側なら、initializeとかnewとかがいいだろうね。

r := module.New(x)

そんでもって、

package module

func New(x) returnType { if hasXXX(x) { return A } else { return B }}

みたいな感じ。

どちらがいいかカプセル化観点から決まると思う。callee側のモジュールに強く依存したデータを返すなら、callee側で値を決める。そこに何のデータが入っているかcallerは関知せず、callee側のモジュールけがそのデータ操作できる。

別にcaller側でも作れるようなデータなら、caller側でやる。

さらに言っておくと、関数名を何にするかはその言語でのお作法とかコーディング規約(不文律的な規約も含む)とかで決まるような気もする。何もなしで決めるならこうするよって例だけれど、すでに似たようなことをしているほかの関数があるなら、それに従うほうがいいだろうね。そいつらがcalculateならcalculateにしたほうがわかりやすいだろうし。

ログイン ユーザー登録
ようこそ ゲスト さん