  |
はてなキーワード: スコープとは
Amazonの中国語の本のカテゴリーを見に行くと下のようになっている。
本の内容をみた印象だが、日本だといくら本を読んでも実務との間に溝がありOJTで頑張らないといけないが、
中国本だと実務にすぐ使える印象がある。
写真技術は普通に写真を撮ったりRAW現像する類のものだ。ストロボスコープのようなものではない。X線撮影はこのジャンルに入っている。
建築はAutodesk Revit、BIMなど。コンクリートや下水処理などもある。
エレクトロニクスと通信は、FPGAやPLC、光ファイバ、レーザーなど。
日本と違う点だと、衛星からターゲットトラッキングするといった本がある。
Space-TimeAdaptiveProcessingというのがあり、Googleで検索かけたら英語がほぼなく中国語ばかりだった。
MATLABの本も定期的に出ている。
LTE-V2Xなどの無線系の書籍もある。MIMO、5Gの信号アルゴリズムと実装など。
電気工学は、送電関係。スマートグリッドや太陽電池、パワーエレクトロニクスなど。
軽工業、手芸産業は、なぜかCNCが入っていたりすが、食品加工や高分子など。
食品をハイパースペクトルで検出するもの、食品のトレーサビリティ、エビの加工技術、微生物、精度保持技術。食品を大量生産する際の技術。
3Dプリントもここ。光硬化樹脂。
農林業。ザリガニの繁殖方法と疫病予防があるのは流石と思う。鯉やガチョウやうさぎ、亀もある。
ぶどうや野菜、きのこなど商業的に育てるのに着目した本が目についた。
原子力に関しては、もう日本はタブー化されていると思うが、普通にある。
原子力発電所のモデリングとシミュレーションといったエンジニアリング寄り。
ミサイルのシミュレーションや、弾頭のデザイン、兵器開発のプロセスと品質管理、ミサイル誘導制御システムの設計、
武器テスト、化学兵器毒物、魚雷発射システムの原理と設計、スーパーキャビテーションの理論基礎、
砲兵弾道学、核兵器防護技術、弾薬製造技術などなどガチ理論本がある。
車だと、AUTOSARの制御ソフト開発といったニッチなものがある。
ここでは、レーダー照射事案での防衛省の対応について述べたいと思います。「韓国の主張は正しいか」は論点にしません。
「なぜ、韓国の主張を責めないのか」というご批判はあるかと思います。それは、極端に言えば、「韓国政府のことを考えるのは無意味」と思っているからです。
台風で被害が出たとき、「原因は台風なんだから、政府の防災対策を検証しても無意味だ」と言う人はいません。
それに近い感覚で「各国は自国の利益のために動く。『そういうもの』なんだから、日本政府がそれにどう対応するかの方が大事」というのが自分の価値観です。
さらに、ここでは、「「低空飛行」問題への防衛省の対応」に絞って考えます。
もちろん、今回の事案の唯一最大の論点は「レーダー照射」です。しかし、その点については日韓双方の主張が食い違っており、また、防衛省がどのような証拠(=交渉材料)を握っているかも不明です。
一方、「低空飛行」問題については、防衛省が動画を公開したこともあり、基本的な事実関係は、ほぼ明らかになっています。防衛省の対応について外部からでも評することが可能なはずです。
また、1月21日に防衛省が「最終見解」を出した後に生じた「低空飛行」問題についても、ここでは述べません。
末尾に、「低空飛行」に対する日韓両国の発信を時系列でまとめましたので、そちらをご覧になりながら読んでください。
韓国側の「威嚇飛行」の筋が通らないことは、各所で検討・指摘されているとおりです。
一般的な軍事行動として危険性があるものではなく、また、過去の同じ行為に対する抗議がなかったことも1月21日に防衛省によって主張されています。
(ただ、これについては、「人命救助活動中だった」という反論があることは留意が必要です)
そもそも、「威嚇されたからレーダーを照射した」ならともかく、「レーダー照射はしていない。それはそれとして威嚇はおかしい」というのは主張として不可思議です。
韓国側としては、今回の事案の中で一定の「落ち度」が自国側にあったことを認識しており、それとの交換材料にするために持ち出したと考えるのが合理的です。
(その「落ち度」が、「レーダー照射」なのか「無線に応答しなかったこと」なのかはわかりません)
しかし、言うまでもなく、今回の事案の最大の問題は「レーダー照射」です。「(防衛省が示唆するような形で)レーダー照射をした」ことが確定すれば、他のことは誤差の範囲です。
韓国側が「低空飛行」を持ち出しても、大した問題にはならないはずでした。ただし、威嚇飛行を論点として戦線が拡大していくと「どっちもどっち」という状況になりかねません。韓国はそれも狙っています。
防衛省は、12月25日という比較的早い段階で、具体的な反論をしました。結果、戦線は拡大し、韓国に付け込む隙を与えました。今日に至るまでグダグダが続く原因です。
本来なら、「低空飛行」はまともにとりあわず、「我が国は適切に飛行していた」の一点張りで、「レーダー照射」のみを取り上げ続けるべきでした。
…というか、「韓国が問題をすり替えようとしてくる」ことぐらい、過去の経験から、わかってたと思うんですが。
防衛省が12月28日に動画公開した際、「参考資料」としてPDFファイルが公開されています。
このPDFファイルの2ページ目には「航空法規における船舶と航空機の離隔距離規定」として「航空法施行規則」「国際民間航空条約第2付属書」の引用が書かれています。
しかし、この引用が、今回の事案にどう関わるのか、あるいは同時に公開された動画とどう関わるのかは、何も記述されていません。
この時点で、この事案は、国際世論に対する広報戦の様相を持ち始めていました。
公的な発信がなくても、国内メディアは、防衛省の言いたいことを忖度して、あるいはリーク等で得た情報から、防衛省の主張を伝えます。しかし、海外メディアが、防衛省のためにそこまで労を取ってくれるとは限りません。
国際世論へのアピールを考えたとき、公的な発信は必須です。しかし、防衛省が出している表(末尾にURL)を見てもわかるように、12月28日から1月21日まで、約3週間にわたって公的な発信はありませんでした。
その間、韓国国防部は、1月4日の動画で「軍用機には適用されない」と反論しています。防衛省から、それに対する反論は1月21日まで出ませんでした(その間の1月14日に実務者協議があったというのはありますが)。
国内メディアの報道に触れていると、「日本はこれだけ主張しているのに…」という印象を受けます。しかし、実際には、防衛省は「ほとんど主張してない」のです。上に書いたように、1ヶ月間、ほぼ沈黙し、その発信でも、主張が明確に述べられていません。
「国際的な発信と国内向け発信に齟齬がある」ことは、「国際世論と国内世論に齟齬が生まれる」という事態を生みます。
これは、非常に由々しき事態です。「国民が国際世論から切り離された国」がどのような姿になるかは、古今東西、様々な例が思い浮かぶと思います。
このことは、防衛省だけでなく、国内メディアも含めた大きな問題だと考えています。
防衛省は12月25日に「低空飛行」への最初の反論をします。その中で、「国際法や国内関連法令」という言葉が登場します。
これに対しては、すぐに韓国メデイアから「国際法と国内法が何か分からない」というツッコミが入ります。実際のところ、軍用機の飛行を制限する国際法はないので当然のツッコミです。
(本来、国内メディアこそツッコむべきだと思いますが、そうした報道は無かったと思います)
それに対して、上に書いたように、12月28日に「国際法」が「国際民間航空条約第2付属書」のことだと示されます。
この条約では、「地水面から150m(500ft.)未満の高さ」での飛行の禁止が決められています。
すなわち、これを持ち出した時点で、「自衛隊機は高度150m未満では飛ばない」と明確な数字で線を引いて宣言したことになります。
つまり、その宣言以降に、もし150m未満で飛べば、韓国から抗議が来る形になるわけです。
そして、実際、1月24日には「60mで飛行した」という抗議が行われ、泥沼化してるのが今の状態です。
実際に60mで飛行したかはわかりません。しかし、数字を出して線を引いた段階で、遅かれ早かれ、こうなることは充分に想定できたはずです。防衛省は、自分から、難癖を付けられるポイントを作りに行ったのです。
難癖を付けられまいとすれば、本来なら守らなくて良かったはずのルールを守ることになります。
おそらく、自衛隊内の規定として「高度150m」が決まっていて、普段から遵守しているのでしょう。しかし、「組織内の規定」と「外交案件」では重みがまったく違います。
北朝鮮の「瀬取り」監視のために、朝鮮半島周辺海域の監視が重要なこの時期に、自衛隊機に要らぬ枷をはめてしまった大愚策です。
上で書いたように、そもそも、具体的に反論したこと自体が失敗でした。まして、民間機向けの条約を持ち出しても、何の根拠にもならないどころか、ツッコミどころを増やすだけです。そして、同時に、自衛隊機の飛行に要らぬ制限を加えます。一言で言えば「何がしたかったかわかりません」
(12月25日の時点で、「150ｍ」の根拠が国際法にあると誤解してたと考えるとスジは通るのですが、さすがにそんなことは無いと信じたいです)
以上、「低空飛行」問題に対する防衛省の対応について語ってみました。
もちろん、2度にわたって非公開の実務者協議が行われており、そこで何が話し合われたかは、我々には知る余地もありません。しかし、ここで書いたように、表に出た部分ではマズい対応が多いです。そして、実際、事態を収められず、泥沼化させています。
韓国の術中に見事にはまった…いや、韓国の想定以上に自分から泥沼にツッコんでいったように見えます。
さらに、今回、防衛省は、最前線にいる自衛隊に対しても、後ろ弾を撃つようなことをしています。
こんな防衛省に、大切な自衛隊員の命、日本の国土、そして自分たちの命を任せられるのでしょうか。
「本番」の敵は韓国とは限りません。中国・ロシアは、国力･軍事力を背景に、より狡猾に立ち回ってくるかも知れません。
…とは言っても、僕たちは、「もっと頑張って！」と応援するしかないんですけどね。
基本的には双方の公的な発信に絞っていますが、報道を踏まえた発信については、元となった報道も記述しました。
プログラミングを教えててよく分かるのは、ちゃんと論理的な思考が出来ているかどうかを計る道具として非常に有用だということ
口先だけで乗り切ってきた人はプログラミングを教えてもちゃんと理解してくれない
知識化するときに表面上だけを理解することに慣れきってしまっていて
だからプログラミングを教えて新しい物を作らせようとすると全然作れない
例えば
def hoge(a, b): c = a + b return c def gaga(a, b): print("Hello ", a, b)
っていうソースがあったとして、gagaっていうメソッドをhogeの演算結果が表示されるように変更してみよう、っていうことをさせると
def gaga(a, b): print("Hello ", a, b, c)
って答える。
もちろんスコープとか名前空間とか、そもそもそれが生まれてきた経緯とかメソッドの意味とかはちゃんと教えてるんだけど
それでも理解してくれない
この問題に関して正解を教えると、この問題は解けるようになるが、しばらくすると似たようなミスを連発する
一方で論理的な思考が出来る子は全然分野違いから来てる子でもそんな間違いはしない
頭の中を整理して理解しているからなのか、とんでもない間違いはほぼない
入試とか面接だと両者の区別は付かないし、下手したら普段の業務でも顕在化しなかったりするんだけど
しばらく一緒に仕事をしたりすると
「あ、なんかそもそもを分かってない」
っていう子はプログラミングができない
前回に続いて、今回もオブジェクト指向プログラミング（OOP）の基本的な仕組みを見ていこう。
OOPに関係してる#18から#24までのうち、後半の#22から#24までを一緒に見てみよう！
クラスベースのOOPでオブジェクトを使う場合、普通は「クラスからインスタンス（オブジェクトの具体的な実体）を作ってから使う」と説明した。
実は、newでいちいちインスタンスを作らなくても、クラスのメンバー（プロパティーやメソッド）を直接呼び出して使える仕組みも用意されている。
それが「static」（静的）という仕組みだ。
「静的」（static）という言葉は、「動的」（dynamic）の対義語になっている。
newでインスタンスをポンポン作っていくのが「動的」なら、new無しでコッソリとメンバーを呼び出すのが「静的」というかんじ？
PHPでは、インスタンスを作らなくても、直接（静的に）呼び出せるメンバーには「static」という目印を付けておく、という文法になってる。
さらに、
それではstaticなメンバーを入れたクラスを定義してみよう。
// プロパティー：インスタンス変数（staticなし。newした後じゃないと使えない）
public $name;
// プロパティー：静的変数（staticあり。newなしでいきなり使える）
public static $count;
}
文法的には「static」という印を付けるか、付けないかの違いしかない。簡単だ！
次は、staticなメンバーの呼び出し方を見てみよう。
ちょっと待った！「演算子」という言葉は初めて出てきたね？意味を確認しておこう。
1+2は3になる等、対象（1とか2とかの数値データ）を操作（＝演算）して、3という結果を得られる。
「::」はスコープ定義演算子とか、ダブルコロンと呼ばれている。PHPマニュアルでは以下のように説明されている。
静的メンバーを呼び出す専用の記号として「::」という演算子（記号）が用意されている、というわけだ。
つまり、「::」という演算子を使うことで、静的メンバーを操作できる。
それでは、「::」を使って、静的メンバーを呼び出してみよう。
// プロパティー：インスタンス変数（staticなし。newした後じゃないと使えない）
public $name;
// プロパティー：静的変数（staticあり。newなしでいきなり使える）
public static $count;
}
// new無しでいきなり使える！
User::$count = 1; // 1を代入する。
実行すると
「PHP Fatal error: Uncaught Error: Access to undeclared static property: User::$name」
というエラーメッセージが表示された。
「staticなプロパティーとして定義されてないから、アクセスできないよ！」と怒られた～～～（涙）
staticじゃないメンバーには、ちゃんとnewしてインスタンスを作ってからアクセスしないと、使えないんですね。（面倒）
オブジェクトのメンバー（プロパティー、メソッド）に、オブジェクトの中のメンバーがアクセスするとき、
という使い分けになってる。単にこれはPHPの文法なので、特に悩む余地はない。
// 普通のプロパティー：インスタンス変数（staticなし。newした後じゃないと使えない）
public $name; // ←この$nameをこの下にあるをhello()から使いたい
public function hello() {
echo "Hello, " . $this->name; // this->で指定する
}
}
$this->nameで、オブジェクト（この場合はインスタンス）内の$nameにアクセスできる。
// staticなプロパティー：静的変数（staticあり。newなしでいきなり使える）
public static $name; // ←この$nameをこの下にあるをhello()から使いたい
// staticなメソッド
public static function hello() {
echo "Hello, " . self::$name; // self::で指定する
}
}
// new無しでいきなり使える！
self::$nameで、オブジェクト（この場合はクラス）内の静的な（staticな）$nameにアクセスできる。
「this」とか「self」とか、いちいち使い分けていて面倒くさいなーと思うだろう。
なんでこんなことをやってるか？というと「スコープ」という仕組みが関係してる。
ドットインストールのPHP入門でも、#16でちょっとスコープについて説明してあった。
「スコープ」（scope, 可視範囲）は、元々は潜水艦に付いてる望遠鏡（潜望鏡）のこと。
プログラミングでは、あるデータ（変数とか）がどこまで見えるか、覗けるか、という範囲のことを「スコープ」と呼んでる。
変数や関数がどの範囲まで有効なのか、使えるのかは、その変数や関数のスコープで決まっている。
Wikipediaで「スコープ」の説明を見ると、ゴチャゴチャ書いてあるけど、要するにスコープには、広い範囲や狭い範囲があるってこと。
thisやselfをわざわざ使い分けているのは、範囲を指し示すときに、
それとも
thisを使ってたら、「ああ、newしてインスタンスを作らないと使えないんだな」と分かる。（インスタンスの中の話）
staticとselfを使ってたら、「newしないで、静的に使えってことだな」と分かる。（クラスの中の話）
太郎の$nameとか、花子の$nameとか、インスタンスの場合は、各インスタンスのメンバーは、明確に分かれていて、両者が混ざることはない＝別々のスコープになってる。
クラスの静的メンバーは、そのクラスに1個しかないので、そのクラスをnewしないで（インスタンス無しで直接呼出したときは）、いろんなところから呼び出されても、共通の中身になってしまう＝スコープが1個、同じスコープになってる。
インスタンス変数とクラスの静的変数は別物なので、thisとselfで使い分けてる、というわけだな！
ここまで読むと「staticって面倒くさいやつだな！なくてもいいじゃん！」と思っただろう。その通り！
staticは使わなくて済むなら、なるべく使わない方がいい。
「static 欠点」で検索してもらえば、staticを使った場合の問題点が紹介されている。
どうしてもstaticじゃないと実現できないこと、staticの方が便利な場合だけ、staticを使うようにしよう。
（参考）PHPのstaticの使い方
具象クラス（今まで勉強してきた普通のクラス）だけではなく、「抽象クラス」という特殊なクラスを作る仕組みも用意されている。
抽象クラスは、継承してその子クラスを作るとき、「必ずこのメソッドを自分で作れよ！」などと強制できる。
つまり、クラスの利用方法（継承とか）について、プログラマーに指示を出せる働きがある。
抽象クラスの特徴として、具象クラス（通常のクラス）との違いを挙げます。
抽象メソッドとは、実際の処理を自身にではなく子クラスに記述させるためのメソッドです。
この抽象メソッドを記述できることが、抽象クラスの最大の特徴です。
抽象クラスを継承したクラスは、この抽象メソッドを必ず「オーバーライド」しなければなりません。（オーバーライドしないとコンパイルエラーとなります。）
OOPの継承には、「単一継承」と「多重継承」という種類がある。
普通は、「単一継承」といって、親クラスから子クラスを継承して作るとき、親クラスは1個だけしか指定できない。（１：１）
クラスA、クラスB、クラスCの３つを親クラスとして、クラスZという子クラスを継承して作る仕組みは、「多重継承」という。多重継承が可能な場合、子クラスは複数の親クラスを持てる。（多：１）
PHPやJavaでは、多重継承ができない代わりに、「インターフェース」という仕組みが用意されている。
インターフェースを使うと、多重継承と似たようなことができる。
↑ここにクラスとインターフェースの相違点がまとめられてたので、参考にしてみてください。
interface sayHi {
public function sayHi();
}
public function sayHello();
}
class User implements sayHi, sayHello {
public function sayHi() {
echo "hi!";
}
public function sayHello() {
}
}
$taro = new User; // コンストラクターに渡す初期データがない場合「new User();」みたいに「()」を付けなくてもOK
$taro->sayHi(); // hi!
#22から#24までを見て、PHPのOOPの基本的な仕組み～使える機能について見てきました。
PHPには、他にもいろんなOOPで使える機能が用意されています。
Javaなど他のプログラム言語には、PHPにはないOOPの機能も用意されています。
オブジェクトを利用するときの仕組みとして、いろんな方法が考えられてます。
使う機会があれば調べてみましょう。
ここまでで、やっとOOPの基本的な仕組み、用意されている機能やテクニックを学びました。
次回は、なぜこんなOOPの仕組みが考え出されたのか？どうやってOOPを活用していくのか？を見ていきましょう。
anond:20181015215004 未経験からのプログラマーなんだが全然分からない
anond:20181016015826 増田式プログラマー養成講座 その１ パソコンの用意
anond:20181016164341 増田式プログラマー養成講座 その２ プログラム＝データ＋処理、プログラム言語の種類
anond:20181016180059 増田式プログラマー養成講座 その３ 構造化プログラミングの基本（順次、反復、分岐）
anond:20181016193144 増田式プログラマー養成講座 その４ 子ども向け教材「Scratch」で構造化プログラミングの練習
anond:20181017161003 増田式プログラマー養成講座 その５ オブジェクトとは何か？
anond:20181017191404 増田式プログラマー養成講座 その６ OOPの種類、PHPの準備
anond:20181019181549 増田式プログラマー養成講座 その７ OOPの仕組み（前半）
anond:20181020230044 増田式プログラマー養成講座 その８ OOPの仕組み（後半） ←★今ここ★
anond:20181022232327 増田式プログラマー養成講座 その９ MVCフレームワークを使ってみよう
anond:20181023184616 増田式プログラマー養成講座 その10 OOPの参考書
：
今回は、手続型プログラミングの後半となる「オブジェクト指向プログラミング」（OOP）について学ぼう。
OOPは内容が多いので数回に分けて説明してみます。（説明が下手だったらフォローお願いしますｗ）
オブジェクト（object）はオブジェクト指向プログラミングにおいて、プログラム上の手続きの対象を抽象化する概念である。
オブジェクト指向プログラミングパラダイムでは、関連するデータを束ね、代入、演算、手続き（関数やメソッドなど）を介した受け渡しといった操作の対象にでき、またメッセージの受け手になれる実体をオブジェクトと呼ぶ。
Wikipediaの説明は分かりづらいね。（初心者だったときの私が読んだら意味が理解できないと思う）
増田式プログラマー養成講座 その２ https://anond.hatelabo.jp/20181016164341 で説明した「プログラムの構成要素」を思い出して下さい。
プログラムは、
- 「データ」
- 「処理」
の２つから成り立っている。
プログラミングの歴史は、この「データ」と「処理」をどうやって使いやすくするか？の試行錯誤になってる。
Javaの入門書にも、データの構造について説明があっただろ？
複数のデータをまとめて入れておく箱は便利な道具なので、だいたいどのプログラミング言語でも用意されている。
この講座では、複数のデータをまとめて入れる箱を「構造体」と呼ぶことにしよう。
構造体の各箱には、普通「データ」を入れておくんだけど、データだけじゃなくて「処理」も入れておけると便利だ。
「データ」も「処理」も保管できるように拡張した構造体に、「オブジェクト」という名前を付けた。
オブジェクトとは、言い方を変えれば、「データ」に「処理」をくっ付けたものなんだ。
このWebページの最初の方に「図: オブジェクトはフィールド(データ)とメソッドを一つにまとめたもの」という説明図があるだろ？
この図で、オブジェクトの中に、いくつか箱があるけど、
なんだ。
オブジェクトそれ自体は特別なものじゃなくて、ただの箱でしかない。データ構造の一種であることが分かっただろうか？
今の段階では、難しく考えなくていい。
ややこしくなるのはこの後だ。オブジェクトを使うときに「なんでそんな使い方するの？」という段階になってからだ。（気を緩めないように、ちょっと脅しておこうｗ）
が「オブジェクト」なら、その反対に、
もあるんじゃないか？と思ったそこのキミ。正解！
「処理」に「データ」をくっ付けた仕組みもあって、「クロージャー」と呼ばれてる。
クロージャ（closure）、関数閉包はプログラミング言語における関数オブジェクトの一種。
この説明文読んで、クロージャーの仕組みがスパッと理解できる初心者っていねーだろ？（いたらビビるｗ）
（Wikipediaの説明は「何言ってるか分かんない」状態だけど、サンプルを動作させてみれば、仕組みは簡単に分かります）
ここまでの説明で、「プログラミング言語は、機能を自由に拡張できる」と分かっただろう。
だから、「データ」と「処理」の扱い方を工夫する歴史の中で、「オブジェクト」という仕組みを閃いちゃった奴がいたんだねｗ
オブジェクトの特徴をもう一度振り返ってみよう。
普段は「データ」をぶち込んでおく箱の集合体に、処理も入れられるように改造しちゃったのが「オブジェクト」だったね？
…ってことは、処理とデータは水と油みたいに別々のものじゃなくて、実は処理もデータと同じように扱えるものだってことになるよね？
そうなんです！
実は「データ」と「処理」は全然別なものじゃなくて、同じようなものとして（扱おうと思えば）扱えるんです！
それで、このデータとして扱えるような「処理」に名前を付けてあげて、「第1級関数」とか「第1級オブジェクト」と呼んでます。
（「第1級データ」という呼び名が使われてないのは、データはデータとして扱えるのは当然なので、わざわざ第1級データという呼び名を付ける必要がないから）
第一級オブジェクト（ファーストクラスオブジェクト、first-class object）は、あるプログラミング言語において、たとえば生成、代入、演算、（引数・戻り値としての）受け渡しといったその言語における基本的な操作を制限なしに使用できる対象のことである。
ここで「オブジェクト」とは広く対象物・客体を意味し、必ずしもオブジェクト指向プログラミングにおけるオブジェクトを意味しない。第一級オブジェクトは「第一級データ型に属す」という。
言語によって異なるが、第一級オブジェクトは概ね次のような性質をもつ。
：
第一級関数（first-class function、ファーストクラスファンクション）とは、関数を第一級オブジェクトとして扱うことのできるプログラミング言語の性質、またはそのような関数のことである。
その場合その関数は、型のある言語では function typeなどと呼ばれる型を持ち、またその値は関数オブジェクトなどになる。
具体的にはプログラムの実行時に生成され、データ構造に含めることができ、他の関数の引数として渡したり、戻り値として返したりすることのできる関数をいう。
上記の説明文の中で「データ構造に含めることができ、」って部分が重要。
フリーパスでどこでも入れちゃうVIPみたいだから、ファーストクラス（第1級）と称されてるんだね？
ドラえもんの「オールマイティーパス」を持ってる奴みたいなのが、「第一級オブジェクト」「第一級関数」ってわけ。
ドラえもんのオールマイティーパスは、どこでも入れる通行証です。
混乱するようなら、上記の説明で、クロージャー以降の話はとりあえず無視してください。
オブジェクトの説明をどうしようか？と考えるとき、参考にしたページも紹介しておきます。
次回、オブジェクトの使い方＝オブジェクト指向プログラミングについて学びましょう。
anond:20181015215004 未経験からのプログラマーなんだが全然分からない
anond:20181016015826 増田式プログラマー養成講座 その１ パソコンの用意
anond:20181016164341 増田式プログラマー養成講座 その２ プログラム＝データ＋処理、プログラム言語の種類
anond:20181016180059 増田式プログラマー養成講座 その３ 構造化プログラミングの基本（順次、反復、分岐）
anond:20181016193144 増田式プログラマー養成講座 その４ 子ども向け教材「Scratch」で構造化プログラミングの練習
anond:20181017161003 増田式プログラマー養成講座 その５ オブジェクトとは何か？ ←★今ここ★
anond:20181017191404 増田式プログラマー養成講座 その６ OOPの種類、PHPの準備
anond:20181019181549 増田式プログラマー養成講座 その７ OOPの仕組み（前半）
anond:20181020230044 増田式プログラマー養成講座 その８ OOPの仕組み（後半）
anond:20181022232327 増田式プログラマー養成講座 その９ MVCフレームワークを使ってみよう
anond:20181023184616 増田式プログラマー養成講座 その10 OOPの参考書
：
西欧的ではあるけどな。最上段に「産めよ、増えよ、地に満ちよ」があり、中長期的な政策の合理性があり、最後に短期的経済合理性があり、資源分配は短期ほど多く、権限は長期ほど強い、という階層構造的な考え方が背景にあるから。
日本ではどうしてもこういった長期的な合理性と短期的な合理性は完全に一致せずしかも優越関係がある、階層構造があるという考え方は受け入れられにくいな。すべてが同じ階層、同じスコープの中で大小関係による闘争があるとした方がウケがいい。キリスト教の布教が全く響かないというのもこの辺りだろうから、受け入れられるようにしてしまっては沽券に関わるのかもしれないが。
2ロック破錠シリンダー交換してるんでしょうし、賃貸だから同等品に交換せなならんと考えるとその値段もありえるのでは。
と思ったらドアスコープの破壊だけなんですね。お疲れさまです。。
月額とか年会費とか取る会員制サービスで鍵解錠とか水回りやります、みたいなのありますが、契約によるけど業者の出張費しか負担しないのが多いかも。
部品代・特殊作業費等の別途費用はお客さん負担で、別途費用分が高額になる場合もあります。
とにかく見積もりを事前に出してもらった方がいいです。あと賃貸なら営業日まで待って管理会社に相談した方が結果的にスムースかつ安い気も。
