  |
はてなキーワード: オブジェクト指向とは
分厚いが読みにくくはない。オブジェクト指向やパターンを実践的に学ぶ本。読めたら読め。
"Clean Code"ではなくClean Code"r"。(どっちも同じ著者。)
あなたがプロのプログラマであるなら、上司や顧客に対してウソやごまかしを行ってはいけない。
ウソをついて、その尻拭いを上司に任せるのならば、あなたはプロ意識を持ったプログラマではない。読め。
もしもあなたが「アレクサンダー大王の生まれた年」や「五大湖の総水量」、「2004年時点の米ドルの総通貨流通量」について、
"90%確か"な見積もりをつくることが出来ないのであれば(つまり、「90%の確かさでこの中に正解があると言える下限と上限を示すこと」ができないのであれば)、
あなたは見積もりという行為を誤解している可能性がある。読め。
「pythonで何か書く行為はプログラミングではない」と感じる人々がいるらしい。
「プログラミング言語を直接変更したり自作したり、メモリを弄ったりしない(できない)のならプログラミングではない。それはただのpythonスクリプトキディだ」みたいな。
ぜひnand2tetrisを実践し、pythonコーディングはプログラミングであることに気づいて欲しい。楽しみのために読んで欲しい。
良くないコードとは何かを学んだ方がいい。
世の中良くないコード(を変更する仕事|が生産される状況)の方が多いんだから。読んだ方がいい。
「オブジェクト指向デザイン、データ構造、アルゴリズムデザイン、計算量解析等に対する基礎知識」
えらい大雑把やし、知らなくてもプログラマーやってるのもいっぱいおるで。
本当に学びたければ、3年次編入とかじゃない？
正月に実家に帰ると、今年28歳になる9歳下の弟が会社をやめてプログラミングスクールに通うと言い出したので全力で止めた。
エンジニアになりたいのならカリキュラムは全部俺が組むし、わからないことがあったらいつでも相談にのるし、なんなら仕事の紹介だってするから、
まずは会社をやめるな、そしてスクールには金を払うな、と伝えた。
その後、転職をするのであれば適切な情報を伝えねばと考え、いろいろな会話をしたので、書いてみたいと思う。
例えばこれ。[ https://www.amazon.jobs/jp/jobs/1353081/software-development-engineer-full-time-class-of-2022 ]
プログラミング言語最低一つに"精通していること"というのがあるが、スクールレベルではそこまではいけないし、かなりの高いレベルであることを伝えた。
「オブジェクト指向デザイン、データ構造、アルゴリズムデザイン、計算量解析等に対する基礎知識」も基礎とはいえ、ある程度実務経験がないと身につかないものだとも伝えた。
そして、このポジションがAmazonの中ではかなりジュニアなレベルのポジションであり、もっと上が狙えるはずだということも伝えた。
ただ、弟はといえば、これだけできて、かつ時価総額世界一の会社に入社して、年収は740万円～というのにもやや驚いていたようだ。
スクールの営業には短期間で年収1000万円も夢じゃないというようなことを言われていたようで、期待より低かったらしい。
次に、闇を見せた。
まずIT業界の実態を説明するために「IT土方」、「新3K」といった単語を紹介して、ぐぐらせた。
そういう環境が普通に存在していて、かなりの確率で巻き込まれることになることを伝えた。
さらに、google:エンジニア 平均年収 などと検索させて、日本の平均的なIT業界の報酬の肌感覚のようなものを伝えた。
私の15年以上のIT業界での経験から、学歴や、コネ、その他の特別な才能があったりして、優良企業に運よく入社できたような場合を除き、普通の経験の浅いエンジニアの方々はおおむね200～300万円台の年収になるとも伝えた。
きついうえに、低報酬という職場がにかなりの確率でエンカウントするだろう事実は、弟には衝撃的だったようだ。
もちろん、弟に関していえば、俺がその地雷を避けるアドバイスは提供できるし、いい会社を紹介することもできる。
だけど、コネ入社のようなことはできないので、しっかりと俺が組んだカリキュラムにそって勉強してくれれば不可能ではないと思う、と伝えた。
だけど、弟はIT業界への転職はあきらめた。リスクに見合わないと判断し、今の仕事を続ける決心をしたようだ。
彼はすでに500万円近い年収を受け取っており、同年代にしては優秀な方だと思う。大学時代から付き合っている彼女もいて、結婚も考えているらしい。
今回の話をうけて、私はプログラミングスクールが極めて悪質な存在であると確信を持った。
彼らは、欲しいと言われるものを売っているだけのつもりなのだろうが、彼らが奪っているのはお金だけではない。
今回もし俺か弟かどちらかが実家に帰らず、正月に会話をする機会がなかったら、彼は多くのものを失っていた可能性がある。
もしこの読者にプログラミングスクールに通おうとされている方がいるのであれば、9分9厘やめておいた方がいい。
成功する確率は高くないし、それを隠してサービスを売るようなやつに金を落す必要はない。
まずは、知り合いのエンジニアに相談してみるといい。知り合いにいなければTwitterでもいい。
そして、もし読者の中にプログラミングスクールの運営に携わっている人がいて、もし「年収一千万も夢じゃない」とかぬかしていたんだとしたら、恥を知れ。
この程度でも600万は稼げるという夢を持つか、こんなのでもちょっと何かが違うだけで600万稼げるか否かが分かれてしまう業界に闇を感じるか、600万程度で何ドヤってるの？と思うかはご自由にどうぞ（外資系ってもっと稼げるの？）。
歳は30台前半。学部卒。BtoB向けのパッケージ製品の開発プロジェクトで、設計、コーディング、テストあたりを担当している。仕様について発注元との折衝もやっている。
業務で使う技術のうち、自分自身がそれなりに習得しているものだけを書く。プライベートでしか習得・使用していない技術は別。
以上。
PythonもgitもDockerもkubernetesもAnsibleもCIツールもAWSもGCPもRuby on Railsも知らなくてもなんとかなってしまっている。業務でこれらのスキルを要求されることは（今のところは）ないから。
楽でいいと思う一方、このままだと将来ヤバいとも思っている。いざ転職となったときに詰みそう。
でもいざとなったらググっていくらでも独学できるだろうとたかをくくっているので焦ってはいない。
というか「その他」のところに書いた能力が高ければ世の中大体はなんとかなるんじゃないの。知らんけど。
ちなみに自分は構築できないというだけで、プロジェクトではJenkinsとかgradleとかbabelだかwebpackだかでビルド環境は整えられている。
あとプライベートで、単純な仕様の独自言語のコンパイラフロントエンドをC++とLLVMで作っている（これで金が稼げるとは微塵も思っておらず、完全にただの趣味）。
1についてだけ。
＞分かるけれどこれでどうやって動画や音楽のエンコードをしたり画像処理をしたりするソフトウェアになるのか
エンコードに関してはプログラムはエンコードの理論に従って作られているだけ。大事なのは研究者の考えた理論
画像処理は定型の処理の塊でこれも代替やり方は決まってる。"python 画像処理"とかでググれば多分出てくる
＞あるいはWordとかExcelとかがどうやってこんなので作られているのかが分からない
まず基本的な、ウィンドウシステムがどのように実現されているかをWin32アプリベースでも
よいので理解するべき。ユーザーのマウス操作、キーボード操作をどのようにプログラムが認識し、
処理するかが理解できる。この仕組みは基本的にすべてのアプリで共通と思われ。
＞プログラミング入門書を読んでも、一般的に知られているソフトウェアの作り方みたいな事が書いてない
多くの人が共通的な作り方に挑み敗れているわけで、プログラムは10個あれば10通りの作り方がある。
また、クラスレベルで抽象化してソフトウェア構造を整理しようとする、オブジェクト指向(最近は
クリーンアーキテクチャに昇華させる流れもあり)もあるけれど、オブジェクト指向に向かない
対象領域があったり、なんでもクラス病にかかる等して、銀の弾丸とは言い難い。
また自説だが、順次処理を基本とする、手続き型言語はデータと処理が入り乱れることになるため、
全てを設定しきることが極めて困難なため、きれいにすべてを設計するのであれば関数型言語を使う必要が
あると感じている。
＞だからそのフレームワークがどういう風になっているのかって説明からして欲しいって思う。
そのフレームワークが内包するベストプラクティスの量を鑑みれば、中身を意識せずに
＞つまり言いたいことは、実際に動くアプリケーションというのを作りたいのにも関わらず
＞プログラミング入門書は、これで判定と繰り返しという基礎ができますと言うだけ。
＞これがもう滅茶苦茶イライラする。
天才的な人はコードを書きながら、考えられるけれど、常人はまず詳細設計と言われる
フローチャートを書けるようになったほうがよい。
次に"抽象化"を覚える。"抽象化"を使うことで少なくとも、処理は全体をざっくり設計できる
＞つまり完成しているプログラムを参考にしようと思っているにも関わらずそれがないのでよく分からない。
githubに山のように転がっている。
ただそれを見て理解できるかは別問題。モチベーションを保って継続学習可能な形に
消化できる人間の登場が待たれる
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
268あとで/1884users 管理職のきみと、いつか管理職になるきみと、管理職が苦手なきみへ | サイボウズ式
240あとで/1249users スクラムガイド2020日本語版 | ScrumGuides.org
223あとで/1146users Webページ高速化に必須の知識！ブラウザがWebページをどのようにレンダリングしているか、図を用いて解説 | コリス
209あとで/1667users YouTubeへの動画アップロードも可能！ 無料で多機能の動画編集ソフト「DaVinci Resolve」【レビュー】 - 窓の杜
208あとで/1043users Pythonのオブジェクト指向プログラミングを完全理解 - Qiita
195あとで/1236users データベースを遅くするための８つの方法 | koduki | Zenn
188あとで/1862users お役所「Excel」の改善案が公開 ～あかんヤツ→ええヤツの例がわかりやすく、一般市民にも結構参考になる - やじうまの杜 - 窓の杜
179あとで/1263users 1000万件オーバーのレコードのデータをカジュアルに扱うための心構え - joker1007’s diary
175あとで/2006users Amazonの検索URL末尾に、あるコードを入れると怪しいパチモンとか高額商品とかが排除されるのでとても快適「何この魔法の呪文」 - Togetter
172あとで/1063users 僕「PDFとは何か知りたい」 - Qiita
169あとで/1172users NTT Com Remote Work Handbook | NTTコミュニケーションズ
165あとで/1534users 手指の鬼（四季賞2020秋 準入選）/鏡ハルカ 手指の鬼（四季賞2020秋 準入選） - モーニング・アフタヌーン・イブニング合同Webコミックサイト モアイ
157あとで/811users Web 技術の調査方法 | blog.jxck.io
152あとで/1359users 部下から「議事録ってなんで作成する必要あるんですか？」と聞かれたので議事録の必要性について図解してみた - Togetter
145あとで/861users 【AWS初心者向け】AWS学習方法まとめ【15時間で達成できる】 - Qiita
144あとで/876users プログラミング初心者のための JavaScript と Node.js の歴史、それを踏まえた勉強方法 | mizchi | Zenn
143あとで/1224users 逮捕、無罪判決、そして厚生労働事務次官へ。彼女が続けた地道な歩み｜村木厚子の履歴書 – ぼくらの履歴書｜トップランナーの履歴書から「仕事人生」を深掘り！| エン転職
142あとで/912users アーケードゲームを支えるデバッグ術 - SEGA TECH Blog
140あとで/728users WSL2、Docker、VSCodeで劇的に改善されるWindows開発環境 | Noriyuki TAKEI | Speaker Deck
139あとで/1240users 書いたな、俺の前で、低温調理の話を！ | anond.hatelabo.jp
135あとで/1568users ExcelでVBAを使わないでドラクエ3を再現する | パパセンセイ365
133あとで/735users ゼロから学ぶ Python | rinatz | Github.io
132あとで/1416users [こかげ] フォント : Nu みちしるべ
132あとで/1481users 3年間低温鶏胸肉を食べ続けた | anond.hatelabo.jp
127あとで/959users Webアプリ負荷試験ガイド - withgod's blog
126あとで/1022users 言語が減ることって問題ですか？への私の答え｜下地理則（九州大学人文科学研究院准教授）｜note
126あとで/1523users 大きな枠組みに目を向けさせないようにする - 紙屋研究所
122あとで/565users 大企業の最前線でコードを書き続けるためにやってきたこと - Speaker Deck | kazuhiro4949
122あとで/1331users COVID-19 感染予測 (日本版) の公開について | Google Cloud Blog
121あとで/798users 実践英語 – とあるソフトウェアエンジニアの方法論 | Kazuki Sakamoto | Zenn
121あとで/910users 「リモートワークの達人」はコロナ禍において日本の全社会人が読むべき本｜吉村 総一郎 (sifue)｜note
121あとで/1047users 『桃鉄』の最新シリーズを、崖っぷちな銚子電鉄の社長とやってみたら思いがけない展開になった - ソレドコ
121あとで/1046users インドネシア人が日本語で洋楽カバーしたら人生変わった YouTuberレイニッチ、空前絶後の大反響に「見つかっちゃった」 (1/2) - ねとらぼ
先月に引き続きZennに書かれたエントリーが人気を博す。
漫画が1本ランクイン。ジャンプ系の漫画がブクマを集めているのをしばしば目にするが、数多くあとで読むを集めた今回のこれは講談社アフタヌーン。
「 ①IFでAかBを選択させてどっちかの設定を実行
②Whileで決められた回数分繰り返す
これでやりたいことは分かる。分かるけれどこれでどうやって動画や音楽のエンコードをしたり
画像処理をしたりするソフトウェアになるのかというのがよく分からない。」
プログラミングでやることは、その２つだけじゃなくて、もうひとつある。
③関数を呼び出すこと
Javascriptなら、console.log("Hello world")。
これは、テキストを出力するという関数を呼び出していて、関数の内部を理解しなくても使える。
オブジェクト指向も、結局はこれと同じこと。あらかじめ用意されている関数・メソッドを呼び出せばいい。
これは、大きなゲーム作成専用ライブラリで、ゲームを作るための大量のメソッドを持っている。
この増田読んでで違和感あってなんだろって思って考えたことを書く。
プログラミングで主にやる事は下記の2つ。
①IFでAかBを選択させてどっちかの設定を実行
②Whileで決められた回数分繰り返す
プログラミングで本当に主にやることは下の2つ。
「データの入出力」
「データの加工」
これ。
条件分岐も繰り返しもデータの入出力をソフトウェア上で都合よく行うための補助具にすぎない。
なんならプログラミングに関わらずIT機器がやってるの全部これ。
いや多分当たり前すぎて何言ってんだ？
ってなる人がいると思うが、ITわからん人は多分この前提がピンときてないんじゃないかって思う。
ITのIはインフォメーションつまり情報で、情報はデータです。
画像も音楽も動画も3Dモデルもフォントもアニメーションも全部データ、現代のコンピューターでは数字の羅列になっている。
このデータの元ネタをどこからか取ってきて、加工して、ユーザーに渡すのががプログラミング。
取ってくる元はマウスだったりキーボードだったり、CDだったり、インターネット上のデータだったりほんと色々。
加工するときは変数に突っ込んだり計算する工程が必要で、そのときにIfとかwhileとか必要になる。もちろん適切に加工するためにはアルゴリズムとか数学が必要になるときもある。
これらの工程を一部肩代わりしてくれるのがOSやフレームワークだったりライブラリだったりする。
特に複雑な加工はだいたいライブラリになってるから、初心者はifとかwhileやオブジェクト指向がプログラミングだって勘違いしがちかも。
オブジェクト指向は，ゲームに例えると下のように敵クラス（金型）を作ったなら
>||
auto 防御力;
}
||<
簡単にそのオブジェクト（インスタンス）を複数生成できるんやで
||>
敵B = new 敵("B", 80, 8, 5);
敵C = new 敵("C", 120, 2, 10);
||<
||>
}
||<
この処理で死亡処理を作れる．
プログラミングで主にやる事は下記の2つ。
①IFでAかBを選択させてどっちかの設定を実行
②Whileで決められた回数分繰り返す
とてつもなく複雑で冗長な処理によって実行されている。
わかりやすいので画像処理でいうと、数十万から数百万の画素（RGBAの24bitで表される数値）を小さなブロックに分解し、数学的に周波数の重なりとして計算して変換、含まれる頻出パターンをテーブルにして圧縮伸張を行なう。みたいなことが瞬間的に行われている。
「まさかそんな事できるわけないだろ」というレベルの処理が実際に行われており、これまた直感的でない。
だからそれをどう書くんだよ。という答えはコレ。有名なjpegの実装だ。
libjpeg というライブラリを書くことはできるだろうか？画像の圧縮の理論から考え始めることはできるか？
正直無理だ。自分はプログラマだがそんなに数学が得意ではなく、頑張ったとしても下手するとコレを作るのがライフワークになってしまい、他のことができなくなる。
例えばブラウザを0から作るとして、jpegの処理以外にも画像だけでpngとかgifとかwebpとか、その他もろもろとてつもない作業が必要になる。
「とてつもなくて想像もできないので流石に無理だろう？」
いや、でも、実際動いてるのよ。ここ何十年、コツコツと積み重ねて実現している。
「積み重ね」とはライブラリであったりフレームワークであったりOSであったりする。
「どういう風になっているのか」
外部に向けたインターフェイスがどうなっているのかは理解する必要がある。「使う」ために必要だからだ。
この2つは分けて考えなければならない。
ちなみに、たとえばChromeのコアであるChromiumはのコードはコレだ。
つまり言いたいことは、実際に動くアプリケーションというのを作りたいのにも関わらず
プログラミング入門書は、これで判定と繰り返しという基礎ができますと言うだけ。
これがもう滅茶苦茶イライラする。
「これで判定と繰り返しという基礎ができます」というのが基本的な理論（定理的なもの）で、その他に必然的だが唯一無二ではないベストプラクティスというものがある（法則的なもの）。
後者をうまく説明する入門書に出会っていないんだろうな。という印象。イライラはやめよう。つかれる。
ベストプラクティスはいろいろあるのだが「層の構造にする・レイヤーに分ける」というのは重要なアイデアだ。
libjpegというのはjpegの処理を行う「ライブラリ」だ。他のアプリケーション...たとえばブラウザはこのライブラリを「使う」。
ブラウザではjpeg画像の圧縮展開というとてつもなく難しい処理を「libjpegの使い方」の理解までで済ませ、過去の蓄積であるlibjpegのコードを利用することで真の意味で0から実装しないようにしている。
この場合、libjpegが「低レベル・低レイヤー」の存在であり、中身については「使い方」つまり「仕様」の理解までしか行わないことで、実際に作りたいものを作れるようにしているわけだ。
完成しているプログラムは二例ほど挙げたがどうですかね？
複雑なことをする、特に低レイヤーのコードはとてつもなく難しい。
でも、とりあえずこんな感じのコードなら解るよね？
こういうレベルから理解して、ちょっとずつ難しい処理を学んでいくしかない。
ハードルは高いんですよ。実際。
なので、木材からだと難しいからプレハブのキット的なものを探すとか、ログハウスのカタログを読むとか、あるいは100人乗れる物置を買うのがいいかもしれない。そういうところから始める。
それらがフレームワークであったりライブラリであったりする。目的に合うものを探して、自分がやりたいことをどう実現するかとにかく考える。
「テキシコー」https://www.nhk.or.jp/school/sougou/texico/ で言われる通り、「小さく分けて考える」「手順の組み合わせを考える」「パターンを見つける」「大事なものだけ抜き出して考える」「頭の中で手順をたどる」をひたすら実行する。
unityはコードが公開されているので、本当に読みたいなら。。
オブジェクト指向は一旦忘れよう。
オブジェクト指向の「隠蔽」というのは層の構造が持っている重要な要素ではあるけど、「低いレイヤーについて考えない」のが基本的な作戦だという理解の方が重要だ。
前述の通り「できる限り作らない」んですよ。「使う」だけ。知るべきことを最小化する。
そして本当に作るべきものに関しては、利用する下のレイヤーのライブラリなりを探して・仕様を理解して、どう組み合わせてfor, if, あるいは計算させれば実現できるのかをひたすら考える。
単に翻訳がしたいのか？表示に割り込む方法を知りたい？日本語に翻訳するのは実行時なのか開発時なのか？
要求される表示エリアが言語によって異なるために、デザイン調整が必要になる問題をどうするか？
分解が甘いので何をしたらいいか調べることができないんだと思う。
ちなみに、アプリ内の文言というのはアプリの外部から変更できないように実装されている事が多いので、利用者が上書きする仕組みはかなり難しい。
AndroidなりiOSの仕様にもそのへんに割り込める機能はないはずなので、OSの開発に入っていく必要がある。結構大変だとおもう。
アプリの開発者が、そういう機能を備えた多言語化のためのライブラリを使うようになれば実現可能ではあるので、そっちの方向で頑張るのがおすすめだが、英語圏の開発者には多言語化のモチベーションが低いという基本的な問題はあるのよね。
この辺の「できる・できない・むずかしい」の判断は、いろいろな勉強をすると常識としてある程度みえてくる...気がする。
ついでに。ウェブサイトやウェブサービスの翻訳だとこういうサービスがあったりする。
ブラウザはページの描画処理のなかに割り込む余地が大きく取ってあるので、ブラウザのExtensionとかならできることがいくらかあるかもしれない。
個人的に気に入らない話はOSのアップデートは使いやすくなるからとてもいい事だからすぐにやった方がいいと宣伝されている事。
まあ、半分は嘘だよね。古いものが残っていると先に進めないんだよ...。
現在のクライアントOSは、巨大なプラットフォームのパーツの一部として理解したほうが正しくて、古いパーツが残っているとツライんですよ。
そして「サービスを受けるための道具であって、あなたが何でも好きにできる機械ではないです」みたいな世界になりつつあって、ちょっと問題と言われてもいる。
これはかなり困った傾向なんだけど、全体としての流れはあんまり変わりそうにない。
オブジェクト指向好きですな...。ここではオブジェクト指向は特に気にしなくていいですよ。
とてつもなく複雑なことをやっているために、すべてのバグを潰すことはコストが高すぎてできないんですよね。
それよりバグは未来を先取りするコストと考えて、本質的に価値のある機能を増やしていくというのが基本的な方向になっている。
だからパソコンはたまに不具合を引き起こすんです。しゃーない。
しかし中途半端に理解している老人などは、そんなことじゃ分からん。自分に分かるように説明しろと言い出す。
説明は出来る。しかし相手はイライラするし理解されない。よって説明をしてはいけないという状況に追い込まれる。
ここでどうすればいいのだと理解不能に陥る。
まあ、説明って得てして難しいよ。しゃーない。
そのとおりです。
オープンソースのプロダクトなら原理的には調べられるけどね。Androidとかはオープンになってる。
それを許容することで先に進んできているという事実は受け入れたほうがいいと思う。
「把握・理解可能な範囲」に留めていたら、数十年前のコンピュータの世界から抜け出せなかった。
deep learningの世界ではそれがより一層進むかも。この辺は詳しくないけど。
ここでの「理解」についてはそのとおり。これはもう諦めるしかない。
これが常にある。IT関連は常に新しい情報が出てくるのでそれに送れると無知になってしまう。
なんでこんなことも分からないんだとか言われ放題で、IT系の企業に努めている人は常に新しい知識を入れられる
面倒くさがらない人が向いている。
「面倒くさがり」の方が問題に気づいて「頑張って面倒じゃなくする」ことができるので、プログラマにとっては美徳なんて言われますけどね。
同時にくじけないとか諦めない、しつこいみたいな素養は必要かも。
応用まではとろうな。がんばれ。
このへん自分も知らんですよ。べつに全部知っている必要はない。
（追記: はてな記法の引用すらもさっきまで知らなかったしな！そんなもん）
層の構造をとっているということと関係があるんですが、仕様が変わると、その上に乗っているものを全部なおさないといけないんですよね。
でも革新のために互換性を捨てなければいけないケースも多い。このへんはハードでもソフトでも同じ。
そして、メンテのコストが上がっても使い続けたほうがトータルで安上がりという場合は、古いものが残ってしまう。
あるいは「（多少の問題はあっても）動いているものは変えるな」という経験則から意図的に残す場合もある。
西暦2020年にもなって、プログラミングが簡単には出来ないし、ハードウェアの規格も完全に統一はされていない。
というかプログラミング言語自体多すぎる。ソフトウェアはデファクトスタンダードのモノ程度は知っているが、
ぜんぜん完成していない荒っぽいものを目にしているのだと理解したほうが的確。
それなのに毎日理解のできないパソコンやスマートフォンを使っている。
オブジェクト指向のおかげ様だがオブジェクト指向に対して無性に腹が立つ。
自分の全く知らない場所でいけしゃあしゃあと演算を行い、そして結果を出す。それも大半が正しい結果で
利便性が抜群だ。些細なミス(バグなど)はあるが圧倒的に利便性が勝っている。
そんな道具に踊らされている自分が滑稽だ。理解できない愚かな自分は正に機械の奴隷のようだ。
本当に理解できない。辛い。
勘違いしてはいけないのは、それらはすべて先人の努力の蓄積によって成り立っているということ。
「よくわからないけど存在している道具」ではなくて、信じられないほど複雑だけど、多くの人々の行動によってなんとかかんとか実現した道具なんですよ。
「オブジェクト指向のおかげ様」じゃないんです。（もちろんオブジェクト指向というのも大きな発明の一つですが）
そしてブラックボックスとして使うのは多くの場合正しいです。そこは諦めましょう。
でもエンジニアとしての立場からは、その裏に隠れているとてつもない技術や思考の蓄積に感動してほしいなと思う。
人類がこんなもん作れたのって、かなりすごいよ？
1a. 簡単なライブラリとかＡＰＩとかのオープンソースのやつを全部読めばよくね？例えばprintf()の中身とか。
あるいは自分で作ってみればよくね？
2. alloc()すると空きがあれば8byte確保してそのアドレスを返します。空きが無ければNULLを返します。
これくらいは自分で考えて作れるでしょ？
そういう事の積み重ねで高度なことをやってる。
1b. オブジェクト指向を知っているならカプセル化も知ってるでしょ？中身を知らなくても外のインタフェースだけ知っていれば使える。てか全ての中身を理解しようとしてたら何もアプリケーションなんて作れないです。
例えば俺ははてな匿名ダイアリーが裏でどのように動いているのかわからないけど、毎日記事を書いてる。これがカプセル化。
2a. 一般人に説明するには比喩を使うしかないでしょう。あと、その話題の領域でオブジェクト指向は関係なくね？
2b. それと、べつに「知らないことがあるけど使っている」のはITだけじゃないです。たとえば全身麻酔の原理とか最近までよくわかっていませんでした。航空力学もあんまりわかってないんじゃなかったっけ？なぜ飛行機が飛ぶのか。船も、何故かよくわからないけど速くなる装置があるんですよね。流体力学はよくわからかないです。こんぺいとうがトゲトゲになるメカニズムも解明されていない。べつにブラックボックスはＩＴだけじゃないです。
4. 例えば、長い時間をかけて改善を重ねて2015年の時点で最高の出来のWindows10が発売されたわけです。それを「今更出すな。1995年の時点でWindows10を出せ」とか言われても無理です。強くてニューゲームかよ。
電気の流れがどうやってifとかループになるのかとか、オブジェクト指向がどうとかはこういう本を読めばわかると思うよ
https://www.amazon.co.jp/dp/B00HKN25CQ/ref=cm_sw_r_tw_dp_x_vzFXFb09WXD0N
いやLispは最強のオブジェクト指向システムを持ってるんですが。
Lisp界ではハッシュテーブルとクロージャーとマクロがあればオブジェクト指向システムいらねというポールグレアムみたいな意見はスルーされて普通にオブジェクト指向システム使って書いてる人がほとんどですけど。
半分同感。
おっしゃる通りFW上で開発してる限り意識すべきはオブジェクト指向ではない。
オブジェクト指向を勉強すると小さなクラスをnewして〜メッセージをやり取りして〜継承して〜ってなるが、クラスとはユーザーが定義する単なる「型」。継承は親からの差分。これだけで良い。
現場において向き合うべきはいかに最小限の変数やコード量で実現するかが重要ってこと。
付け焼き刃の知識でオブジェクト指向が〜というヤツに限って、無駄なクラスを作りまくったり無駄なメソッドや変数が多い。
コピペプログラマはOOPとか余計なこと考えずに素直にFWの恩恵に乗っかっていれば良い。
ただ、こういう人たちがIT土方と呼ばれて使い捨てられる可能性も極めて高い。
オブジェクト指向の考え方は、対象物が1:1の関係じゃなくなったら基本的には必要だよ
オブジェクト指向言語でなくてもオブジェクト指向的な書き方をする。
例えばCのファイルIOの関数は、FILE *fpを使って操作するけど、あれだってオブジェクト指向だよ。
同時に2つのファイルを読み書きするなら区別のための識別子が必要で、それがfp。
