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

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

2022-09-09

オブジェクト指向ってこういうこと?

これまでいろいろな書籍サイトから情報を得てきて、オブジェクト指向プログラムを、「知識スキルを持った職人をいっぱい雇ったプロジェクト」というように理解している。

極論を言えば、オブジェクト指向擬人化思考というように捉えているけれど、この理解はどの程度あっているのだろうか?

会社プログラマー

職人=ありとあらゆるオブジェクト

知識データプロパティ

スキル関数メソッド

マニュアルクラス

職人マニュアルを読ませる=インスタンスを生成する

よその会社職人=外部ライブラリとか

とすると、

職人は、会社の指示によって働き、持っている知識スキルを使って仕事をする。

知識スキルは、各職人会社に指示されたマニュアルを読んで覚える。

とか

オブジェクト指向特に有用なのは特に複数会社と協力して作業する場合である

そのような大規模なプロジェクトであるならば、各企業職人一人一人に指示するよりも、マニュアル一つで指示した方が簡単だし、間違いが少ない。

かに置き換えて理解できて、(自分的には)理解やすい。

オブジェクト指向の三大概念として、いろいろな媒体で紹介されている「継承」「ポリモーフィズム」「カプセル化」も、それぞれ「一つのマニュアルを用意して、職人に利用してもらいやすくする」「各職人は、自分にとって必要マニュアルの一部を読んで知識スキルを手に入れる(ここの理解は自信がない)」「マニュアルは、職人によって勝手に書き換えられないようにするべき」みたいな感じでなんとなく理解している。

ただ、根本オブジェクト指向がよくわかっていないため、これが合っているのかもわからない。

のだけれど、なんとなく色々勉強してきて、複数人とプログラムを組むとか、大きなプロジェクトとかでもない限り理解していなくても問題なさそうなので、回収率100%を超える競馬プログラムが出来上がるのを夢見て寝ます

(書いたのを読み返してみると、「会社プログラマー」よりも「プログラマー会社」の方が一般的な気がする)

2022-08-11

anond:20220811120724

オブジェクト指向系ならカプセル化して各ブロックの中身わからんってのはよくあることやん

オブジェクト指向でなくてもライブラリ関数の中身知らずに使うなんてありがちやろうし

ビジュアルプログラミングブロックの中身わからんでええというのも同じ事なんちゃう

2022-01-17

anond:20220116164742

少しでも助けになるなら私の生存方法を書いてみる。

前提

この3点は私も共通している。両親については片親で過干渉ではあったが、しかし大切にはしてくれていた。それでもあなたと同じ思考から抜け出せない。これは、境遇個人努力を超えて、先天的な脳の作り(ADHD)が大きく関係しているのではないか。これに人間関係の失敗経験が積み重なりフィードバックとなり囚われの強化、すなわち脳の悪い思考プロセスネットワークの強化になっていくと仮定している。

人間関係の失敗でさらにこの自己評価が補強されてしまい、どうにも身動きができなくなってしまったのだけど、ここから脱するためにやったことを書く。

考え方

"考え方"についてはプロに任せ、むしろ考えない方法を身につけたほうがいい。

ADHD は考えるだけ無駄

まず、ADHDワーキングメモリが足りないため問題を大雑把にまとめて考えてしまう。

全体を捉えて、最も期待値の高い解決方法理性的に選べている自信はあるだろうか。あなたはある程度客観視できているだろうから落ち着いているときに考えればおそらく、高ストレス時に思っていたことが実は的外れだったという経験があるんじゃないかと思う。

例えば就労が困難だったというケース(あくま一般論の例)を考える。そうなる理由はそんなにシンプルではなく大量の変数が複雑に絡んでいる。 しかし、"自分馬鹿から仕事ができない"という形で問題カプセル化してしまえば、ワーキングメモリ節約できるため、ADHD問題単純化して自分を責める。一時的にはそれが一番ストレスが少ないのだ。本当は"環境が悪かった。定型発達でも仕事が原因で自殺していることもある"など、別の可能性が考えられるのに。

では、いつも正しい判断をするにはどうしたらいいだろう?これは、"自分判断を常に保留する"が疲弊したADHDには正しい方針だと思う。判断は常にプロに任せる。それはどこに住んでどんな仕事をすればいいか、という大局的な判断だけでなく、"誰が悪いのか"、"なぜこうなったのか"、"どうして不快なのか"なども含めてだ。特性上、強力に単純化してしまうので疲弊してIQが下がっている今はどれも的外れになる。

 寝て起きたら、デモデモダッテ思考が顔を出した。父と離れたいなんて、私のわがままじゃないかと疑っている。よく分からいから、今日相談支援専門員さん(何回かソーシャルワーカーさんと書いてるけど、勘違いでした)に電話してみようかと思う。

からこれで電話できたあなたはとても賢いし、自分客観視するセンスがある。

考えない方法

マインドフルネス瞑想がよい。方法適当ぐぐるとでてくる。(大きいトラウマがあると難しい場合がある。↓に追記あり) 浮かんだアイディアを0.5秒以内に棄却できるようになってくれば、鬱でも躁でも、脳の暴走状態を食い止めやすくなる。

人生史を書くとか考えたものをすべて紙に出すとか、自分トラウマを再認識するようなセラピーは無理に実践しないほうがいい場合がある。プロセラピストでない限り PTSDトリガーになりかねないので、慎重に。

考えられる人になるには

疲弊する環境を脱するのが最優先だ。

ストレス回避反応を高める。ただでさえADHDは弱いとされる、長期的な価値評価するための前頭前野が働かなくなり、極端な単純化をし始める。生存のヒントを得るために(存在しないかもしれない)脅威をあちらこちらに探し始める。

IQを上げる方法はたくさんある。有酸素運動無酸素運動を組み合わせたインターバルトレーニング読書楽器演奏、人との会話、人と比べて自分が優れていると実感する、など。しかし、どれもそれができる基盤が無ければ成り立たない。基盤は、どんな形であれ"安心できる生活"だ。

生活

プロ相談して模索しているのはとても素晴らしい。これこそ良い判断だと思う。

あなた場合愛着のある肉親だろうが、親元、実家から離れるのは最優先だ。トラウマ体験のある場所にいると記憶トリガーが多く、思考ノイズ高まる瞑想を頑張っていても考えの棄却という技術では捌ききれない量になる。例えるなら、イラク戦争PTSDになった米兵戦後もその戦場の脇で延々とセラピーを受けるなんてことがあるだろうか。アメリカに帰って湖で犬とキャンプでもしているべきだろう。

孤独

追記や他へのレスを見ると、同居した者と揉めた経験からグループホーム同棲抵抗があると言っている。

父に笑顔で頷き続けるか、他の障害者暴力を振るわれるかの2択しかない。

↓もそう。私もこの囚われとは長年付き合っている。 自分場合、親には愛されているはずなのに。

 環境を変えても、私がダメからダメだと、ずっと思ってた。愛されるためには愛される能力必要で、残念ながら私にはそれが決定的に欠けていると思えるから

ちょっとつらいかもしれないから今は受け入れられなくてもいいのだけど、これこそADHD特有の極度な問題単純化の例になっている。あのときうまくいかなかったという一例を以って、だからあれはやめたほうがいいのだ、というように考えるとワーキングメモリが大幅に節約できる。実際は、相手特別クズだったとかグループホームガチャとか色々分解できて、次の一手はまたフラットに考えることもできるはずなのに。

今は総括(判断)せず、プロに任せて、最善の環境に居れるまで模索するのがよい。次がダメだったとしても単純化せず、また次のチャンスを模索する。単純化バイアスを除いて考えれば、定型発達でも転職離婚病気のような失敗は何度も経験するのだ。

人間のつながりが欲しいと思ったとき、そうできている人とのライフスタイル比較するのがいいと思う。親族、家、お金車など財産ではなく、朝起きて何をしているのか、どんな本を読んでいるのか、どんなご飯を食べているのか、どんな娯楽を好んでいるのか。"考える"代わりに"行動する"のがよい。考えても考えても財産ライフスタイルも変わらないどころか極度の単純化で誤った判断をするのが疲弊したADHDの末路だ。

安全生活が得られるようになってきたら、形から入る。脳は考えて変わるわけではなく、運動、適度な負荷(勉強練習など)、食事で変わるのだ。脳に振り回されて困っていたのだから、脳を手なずけるのがよい。だから順番を変える。"まともな自分になれば孤独ではない生活が得られる"というのはやめて、"孤独じゃない人の生活を真似てみればまともな自分になれる"ということ。

増田について

私も自分自身そう思いたいという部分はあるんだけど、見ている文章を見る限り全然馬鹿ではない。というか文章のみのコミュニケーションであれば誰も重度の発達障害とは感じない。

これはこの番組の予告だけ見ても思った。もし道路出会ったらまるで思考が通じない人にしか見えないのに、文章は物凄く理知的で美しいのだ。

https://www2.nhk.or.jp/archives/tv60bin/detail/index.cgi?das_id=D0009050591_00000

我々は入出力や瞬発的な行動については困難があるかもしれない。しかし、中身までおかしいわけじゃない。

親さえもそれはわかってくれなかったかもだけど、今は世の中に知見が溜まってきているし、お互いこのようにネットで話すこともできるようになってきた。だから幼少期よりはまだ模索できる道は多いはずだ。

おせっかいかもしれないけど増田きっかけで過集中に入ったので最後まで書きました。

ブコメ言及など

スターがついていたので。

hamamuratakuo 個人的な見解だが、頭が悪い人に共通している特徴は「嘘つき」であること。全てを曖昧にしており、現実直視できず、被害妄想に耽溺。それゆえ認識が歪んで知性も劣化している。嘘をやめることが改善スタート地点

言っていることの大筋は私と同じだ。しかし、それを「頭が悪い」「嘘つき」という主観性の強い表現であえて言い直す必要は無い。今回で言えば頭が悪いのではなくワーキングメモリが小さいと言えるし、嘘つきなのではなくワーキングメモリ節約無意識に行っている、というようにより具体性のある話にしたつもりだし、「嘘をやめる」に対応する極度の単純化をやめる方法も示したつもり。

これも脱線するが、自分発達障害自覚する前、定型発達的な人々に対してリスペクトを欠いた態度を取っていた。彼らは(今思えばADHDの私に比べれば、だが)会議発言しない、積極性が無い、すぐ行動しない。「頭が悪い愚鈍な人々だと思っていた。つまり自分が得意なことができない人を簡単に「頭が悪い」と言うのは主観的すぎる。特に今回の文脈では発達障害という特異な脳の状態について話しているのだから、少し配慮してもいいんじゃなかろうか(隙自語同士なのでまぁいいけど)。発達障害知的障害は異なる。高IQ発達障害大勢いるし、発達障害の診断時にIQテストを受けるのでむしろ発達障害者のほうが自分IQを正しく理解している。

misarine3 嘘ではなく現実を正しく把握できなsので偏って間違った認識を伝えてしまうケースもある。あとADHDかと思ったら発達性トラウマ障害複雑性PTSD)というケースもあるので一考してほしい。

programmablekinoko マインドフルは合わなかった。多動優先だとじっとしているのが難しい。有酸素運動強制的に頭空っぽにするか、NBackやラジオ流しながら何かを音読するなど、脳内ノイズをかき消す方法自分には良かった。

https://anond.hatelabo.jp/20220118124641

元増田ではないけどマインドフルネス瞑想トラウマ持ちだと困難だったぞ

TFT自己否定強いと自分を叩き出して失敗した

ブクマにもあったけど発達性トラウマ考慮しないと危ない

これはそうかもしれない。実は自分場合自己流の荒療治でトラウマ追体験を繰り返してみたり瞑想でつらいことを棄却する訓練をやってみたりと実験してみた。この中で瞑想継続できたということなので、n=1 なのは確か。カウンセラー精神科医などプロ相談しながらがよい。

本当は睡運瞑野がうまくかみ合えばいいのだけど、睡運瞑野ができるのは睡運瞑野がうまくいっているときだけという難しさがある。 瞑想の代わりに運動する、それもできないなら何もせず寝てしまうなどで、あまり考えないようにできるといい。

sisya 前提が少しおかしい。「頭が悪いから人に大事にされない」ではなく「考えが足らずに人が傷つくことをしてしまっているが、そのことに自分が気づけないので遠ざけられる」なので、相手にその旨先に伝えてくといい。

自分アイディアはこれとも違う。そもそも大事にされていない」「遠ざけられている」という認識が正しくないかもしれないというのが私の立場だ。元増田についても、すでにこのスレッドブクマで多くの人から大事にされているのだから大きな反例になっている。 少なくとも汲める事実は「両親からモラハラがあった」「グループホーム暴力を起こした人がいた」ということだけだ。これを「遠ざけられている」と読み取ることは、私が何度も言っている極端な単純化だ。

もし「自分の考えが足りず人を傷つけるのだ」というところに根拠を置いてしまうと、「自分の考えを洗練させなければならない」という出来もしない曖昧課題が作られてしまう。私もおそらく元増田も、このような袋小路でさんざん自分を苦しめてきた。私の主張が伝わっていれば、期待値が高い対処は例えば「なるべく親元から離れる」「相性のいいグループホームを探し、医師など専門家支援を受ける」などになる。的外れな自省をさせる意味は無い。

aox ASMRに限らず増田さんみたいにスパスパ考えられて実行できるなら誰も苦労しないのでは ʕ•̫͡•ʕ•̫͡•ʔ•̫͡•ʔ•̫͡•ʕ•̫͡•ʔ•̫͡•ʕ•̫͡•ʕ•̫͡•ʔ•̫͡•ʕ•̫͡•ʕ•̫͡•ʔ•̫͡•ʔ•̫͡•ʕ

私も偉そうに書いてしまっているので労せずこれに至ったと思われても仕方ないが、これに至るまでは大変な苦労をした。自殺未遂をして警察保護されそのまま措置入院(強制)というのを何度かやった。ずっと不登校だったが一念発起して就職した会社も、それで復職できず退職した。短絡的な行動で多くの人間関係を失った。何年も睡眠が浅く、悪夢で夜中に飛び起きることが多かった。今もギリギリバランスでやっと立っているが、それでも以前に比べれば前向きに暮らせている。むしろ読む人がこんな苦労をせず役立ててくれるなら幸いだ。

2021-11-18

OOP信仰大分抜けてきた

最近はもうカプセル化とか継承とか面倒くさくて、「処理の使い回しとか、関数使った方が明示的だし、十分じゃない?」とか「インターフェイスさえ定義できれば良くない?」とか考えたりしている。

あらゆる言語イミュータブルな構造体が欲しい。

2021-11-01

anond:20211101171948

Python みてるとカプセル化とかなんやったんかとか思うが、JavaRuby とかの継承比較すると、特に変な感じがする。ここ見ても、イマイチよくわからん。多重継承とかも、本当にコントロールできとるのかね? 雰囲気で書く言語だと思うことにしてる。 https://postd.cc/pythons-objects-and-classes-a-visual-guide/

Pythonオブジェクト指向はなぜ出来が悪いのか……

2021-07-12

anond:20210712140857

局所化の話はカプセル化の話やろ

動物キリンさんが出てくるのは、継承インタフェースの話やろ

なんで混ぜたん

2021-05-21

個人的Python についての不満

良い言語だと思うが、不満がある。

Perl比較して、


Ruby比較して、


Java比較して、


PHP比較して、

  • 後発のくせに、なんであの時に負けたのだろうねー。
  • OOP としては、流石に Python の方が良いと思う。

JavaScript と比較して、

  • カオス具合は、五十歩百歩ですね。
  • 文法的には、JS のが好き。
  • OOP としては、JS の方が優れていると思う。

Haskell比較して、


R と比較して、


C と比較して、

  • まぁ、比較ができんね。どうせ Python も中身は C だし。
  • どーせ C が最後には勝つんだよ。


という愚痴がある。他人の書いたものを読む分には良い言語だと思うよ。

追記。または、コメント欄への返事。

今日日型ヒント書くし、タプルは複数の値を返すけどクラスを作るほどではない関数を書く局面でよく使う

型ヒントはコンパイル時のエラーにならないじゃん。だったら、いらなくね?タプルは複数の値を返すときに使うのね。Go みたいだね。または Ruby の Struct みたいな。

リスト内包表記書かせるのやめてもらえません?

あれ嫌いな人おるのか。俺も好きじゃないが。純粋Haskell と同じ文法だったら良かったのにね。

三項演算子について

アレはキモいね。素直に ?! で良いと思う。というか、Python英語圏の人も納得はできないだろ、っていう文法が多くないか

インデントブロックなのて可読性が上がる

というのは同意する。ただ、書くときにそうは思わない。例えば、with 構文は Ruby の方がブロックを抜けたらクローズするという方針のが良いと思う。

互換性を断ち切って増田にも認めてもらえる仕様Python 4が待望される。

それ Python 2 から 3 になったときに既にやったじゃん。そして大成功したじゃん。ニャンニャン

2021-04-22

anond:20210421172633

わかりました。

 

これから

カプセル化継承してポリモーフィズムでチャチャッと直してよ。」

明後日までに出来るでしょ?」

と言うことにします。

2021-02-14

からオブジェクト指向オブジェクト指向プログラミングは全くの別物だろって言ってるだろうが

言ってないけど。

Cから派生したCやJavaなどでやってるのはオブジェクト指向プログラミング

メッセージングメソッド呼び出しで近似して、

クラスというものを作って、「カプセル化」、「継承」、「ポリモーフィズム」を三本の矢にして

いかデザパタマウント取るかを競い合う競技のことだ。

これを提唱しているのはオブジェクト指向プログラミング日本語解説しているWikipediaなので間違いない。

現在日本人に対してオブジェクト指向とは何かと問えばこれのことなので、これさえ押さえておけば会話に問題はない。

なまじっか真のオブジェクト指向精通していると、英語版wikipediaオブジェクト指向を学び、smalltalkなんかかじった日には、現代日本におけるオブジェクト指向いかに偽物かわかるだろうが、奇異にみられるのはあなた自身であることを付け加えておく。

2020-12-01

anond:20201130214610

1a. 簡単ライブラリとかAPIとかのオープンソースのやつを全部読めばよくね?例えばprintf()の中身とか。

あるいは自分で作ってみればよくね?

例えば、初歩的な動的メモリ管理をするアルゴリズムとか。

 1. 64byteの領域があります

 2. alloc()すると空きがあれば8byte確保してそのアドレスを返します。空きが無ければNULLを返します。

 3. free()すると確保したメモリ解放します。

 これくらいは自分で考えて作れるでしょ?

 そういう事の積み重ねで高度なことをやってる。

1b. オブジェクト指向を知っているならカプセル化も知ってるでしょ?中身を知らなくても外のインタフェースだけ知っていれば使える。てか全ての中身を理解しようとしてたら何もアプリケーションなんて作れないです。

例えば俺ははてな匿名ダイアリーが裏でどのように動いているのかわからないけど、毎日記事を書いてる。これがカプセル化

2a. 一般人説明するには比喩を使うしかないでしょう。あと、その話題領域オブジェクト指向関係なくね?

2b. それと、べつに「知らないことがあるけど使っている」のはITだけじゃないです。たとえば全身麻酔原理とか最近までよくわかっていませんでした。航空力学あんまりわかってないんじゃなかったっけ?なぜ飛行機が飛ぶのか。船も、何故かよくわからないけど速くなる装置があるんですよね。流体力学はよくわからかないです。こんぺいとうがトゲトゲになるメカニズムも解明されていない。べつにブラックボックスはITだけじゃないです。

4. 例えば、長い時間をかけて改善を重ねて2015年の時点で最高の出来のWindows10が発売されたわけです。それを「今更出すな。1995年の時点でWindows10を出せ」とか言われても無理です。強くてニューゲームかよ。

2020-05-29

anond:20200529165604

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

みたいな感じだよね。

2020-05-28

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

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

anond:20200528082941

あなたの言う通りだよ。

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

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

anond:20200528080145

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

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

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

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

2020-05-27

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さんが正しかったのか、あるいは単一責任原則の捉え方が間違っているのか、はたまた・・

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

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

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

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