ขนาดวิดีโอ: 1280 X 720853 X 480640 X 360
แสดงแผงควบคุมโปรแกรมเล่น
เล่นอัตโนมัติ
เล่นใหม่
コンストラクタ内で直接生成すればいいってのはカプセル化の観点から見ればそうだけど、他クラスへの依存性を減らすDI(Dependency injection)の観点ではコンストラクタで部品を受け取りたいことがありますね。個人的にはカプセル化は使用者から詳細を隠すためのものであるから、参照によって内部に手を加えるのが使用者でなければ問題無いと思っています。複数オブジェクト間で同じ参照を持たせて狭域のグローバル変数っぽく使ってみたりしたことがあります（これが良いか悪いかは微妙ですが）。
イミュータブルの話は説明するのがむずいので助かります。
ありがとう。それしか言葉が見つからない
生命医科学系のデータ解析を行うために勉強をしている大学生です。非常に面白く参考になる動画で、シリーズ全部視聴しました。データ解析の文脈だとまた目的が違うものと思うので、この動画の内容が僕の実務にどれだけクリティカルに関わるかはわかりませんが（対照的に、環境構築の動画はものすごく参考になりました）、頭の中でモデルをどのように整理して考えるか、それがプログラムの形でどのように表現されるのかという、「物事を頭の中で整理、理解するための方法論」という意味だけでもとっても有意義な内容でした。おそらく沢山の実務と勉強を通して、ゆっくりと投稿者さんの中で作り上げられてきた理解の形なのだと思います。それが全部で20分と少しで、しかもとても平易に簡潔に伝えられているというのは、衝撃です。惜しむらくは、①これだけ高度な視点で物事を理解する必要のある作業を日常で要求されない人からするとこの動画の有益さがわからない②やはりある程度OOPのパラダイムで書かれているコードに触れてないと意味がわからないために、再生回数が伸びないことですね。随所に登場する例が必要十分だったり、図式での説明が適切に使用されていたりして、目的とする理解の状態に最短で到達できるクオリティーの高い動画になっているという印象です。相当な労力の結晶であることは分かる人が見ればわかるのに、あまり広く知られていないのが残念です。正直、これまで見てきたプログラミング関連の動画の中でダントツトップで有益な動画でした。これだけ長文を書いたのも、コメント欄を見ていると、説明不足で非建設的な批判コメントがあったり（大変丁寧で大人な対応をされていると感じました）、あまり評価されている印象がなかったため、少しでもその真価を理解して応援している人がいると感じてほしいという動機もあります。これからの動画の投稿も楽しみにしています。
ありがとうございます！
すばらしい。イミュータブルの存在意義を理解できていなかったけど、言語化できていないモヤモヤが一つ取れました。開発の経験によって感想が変わりそう。技術水準がそろっていない大きめの開発で他人による 参照先すり代わり の厄介なバグ経験をしていないと、一見遠回りなだけに見える。この設計の意味を理解できないかも。
その通りなんだけど、言語によって参照してるのか複製してるのか分からんのが悩ましいのよね。。。引数にせよ戻り値にせよ、参照と複製とて型が違うとか、両方存在しているならありがたいけど、「この場合はデフォルトは参照で、複製したい場合は処理増やしてね」とか、初見言語だと分かんない(T_T)ところで、ここで紹介してる言語は・・・Python？
はい、Pythonですメモリを意識しない言語だと厳しいですよね（苦い経験があります）
3:21 合成と集約の違い（下記の要約が間違っていたらすみません）合成は、全体オブジェクト内で部分オブジェクトを生成する。集約は外部で部分オブジェクトを生成したあとに、それを全体オブジェクトに引数として渡す。
プログラマ達はなんで自分と意見が違うというだけですぐ喧嘩腰になっちゃうんだろうねせっかく自分で労力をかけて勉強したものを無料で公開してくださっているんだからまずは感謝が先なんじゃないの？対話力を鍛えましょ🔥
オブジェクト指向の本質は、保守性とカプセル化ということで良いんだろうか？
流石に要約しすぎたかもしれない。
カプセル化も保守性の一部だと思うだからオブジェクト指向の本質？は保守性と思うカプセル化だって不用意なアクセスを断つ事でバグを防ぐし、役割を分けられるから管理も簡単になる継承も同じコードを複数書かなくて良くなるからアプデでの更新忘れを防げる⇒保守性ポリモーフィズムも同様⇒保守性
そもそも大きな勘違いをしてます。original_obj が本体で、retrieved_obj が参照だと言いたいようですが。これは、どちらも参照です。Someインスタンスの本体はメモリ上にだけ存在し、どちらもそのメモリ上のインスタンスを参照してるという点は同じです。変数名が違うだけです。 合成？というのがこの人のオリジナルの考え方でしょうけど、この動画の合成の場合も結果は同じです。Someインスタンスの作成をクラス内でやるかクラス外でやるかという違いしかありません。クラス内でobjを作ったとしても結局、get_obj() で参照を返してるわけですから。 original_obj = get_obj() retrieved_obj = get_obj() として使われる可能性があるので、結局おなじことです。 クラス外部で変更されることを防ぐには get_obj() を無くして、get_obj()の参照が必要になる様な外部の処理をすべてクラス内部に実装するべきです。objが変更されたくない場合は、objをクラス内部だけで管理すべきです。それを外部で管理させるとカプセル化の意味が無いです。
そもそもカプセル化の役割は隠蔽や外部アクセスの拒否ではないですよね。なぜそのような間違った解釈をしてるのか疑問です。あなたがそのような使い方を望んでるだけであって、それがカプセル化ではないです。 そもそもプログラム全体も一つのカプセルみたいなものですよね。その全体の中に子カプセルを用意して、処理をグループ化することでプログラム全体を調べる必要が無くなるのがカプセル化の強みです。それをグループ外から操作したり参照したりすれば、グループ化のメリットが無くなるのはあたりまえな話です。カプセルの外から参照が必要になる様な作り方をまずやめるべきです。言語のデメリットであるかのように説明されてますが、それは単にあなたの使い方がおかしいだけです。
なんだろう、こんなこと言いたくないが・・・「参照の問題」は投稿者のオブジェクト指向の理解がおかしいんじゃないですかね。関連（Association）って知ってますかね？あと、Haskellの純粋関数型言語だとか、Rustの所有権の話だとか、ちょっとかじった知識をとってつけてるだけにしかみえないですよ。
あなたのフィードバックに感謝します。あなたのような視聴者からの意見や指摘は非常に有益です。自分の理解を動画にしているので、ご不快に思うところがあるかもしれません。私の勉強不足な部分が見えたなら申し訳ございません。説明に誤りを正すためにどの部分が間違っているのか、具体的に教えていただけますか？また、私の理解を深めるために参考になる資料やリソースがあれば、それも共有していただけると幸いです。コメント欄だと長くなってしまうのなら、ビジネス関係のお問い合わせメール宛でも構いません。
@@amazkaede 0:51-『参照先の値が変わったから、カプセル化（データ隠蔽）が破られた』という主張がヘンでしょ。もちろん包含関係の場合には、参照先のオブジェクトを他から変更されたくないというケースもあるでしょうが、そんなのオブジェクト指向の世界では稀です。もしかしてあなたはオブジェクト指向をコンポーネント指向かなにかのように捉えてしまっているのかな？
返信コメントありがとうございます。私の動画の説明が間違っていることで誤解を与えたようで申し訳ございません。カプセル化は、オブジェクトの内部状態を外部から直接アクセスできないようにすることで、オブジェクトの状態を保護するものです。これにより、オブジェクトの状態が意図しない方法で変更されるのを防ぐことができます。あるオブジェクトが別のオブジェクトを参照していて、その別のオブジェクトの値が変更されたとしても、元のオブジェクトの状態は変更されません。この状態は集約です。本動画では、合成のはずが意図せず集約になっていて、予期せず値が変更されてしまう場合はカプセル化が破られるという内容を説明しています。このようなケースは稀かもしれませんが、起こりうることなので……。かなり限定されたケースの話をしてしまったと後悔しています。私の説明の間違いが酷い誤解を与える内容になってしまったこと、お詫び申し上げます。今後は、より正確な説明を心がけたいと思います。
具体的な指摘をせず、芯をずらしたことだけ言いながらただ「おかしい」とだけ言うこの感じ、反論を避けて優位性を保とうとするかなりずるい姿勢だと思うんですよね。投稿者の方が平身低頭へりくだって問い返して、やっと少し具体的なことを言い始めたと思ったら「～というケースもあるでしょうが、そんなのオブジェクト指向の世界では稀です」。つまり「投稿者が言うような問題は（稀かもしれないが）存在する」と言っているわけで、大上段から「おかしい」「ヘン」と言っていたところからずいぶん後退したなあという感想です。
カプセル化の破壊は変更容易性の問題なので、参照で変更可能なことがカプセル化の破壊と例える表現は語弊を残す点かなとは自分も思いました意図しないアクセス手段を排除していないことが問題のためで、これは参照の問題というより設計の課題ですなので文体は乱暴ですが、主張自体は真っ当かなと思いますある複数のオブジェクトが一つのオブジェクトを参照していて、管理を共有するモデルは決して珍しくはありません大切なのはそのパラメータを利用する側にいかに意図した制約を課すかですそもそもイミュータブルなインスタンスを作り直せる状態はカプセル化を果たしたと言えるのか？という問題もありますRustでも参照をパスしたりmut変数の参照を作ってパラメータの共有は可能ですしね
![[Introduction to Git] Basics of Git for beginners ~ Get started in 30 minutes!](/img/n.gif)
コンストラクタ内で直接生成すればいいってのはカプセル化の観点から見ればそうだけど、他クラスへの依存性を減らすDI(Dependency injection)の観点ではコンストラクタで部品を受け取りたいことがありますね。
個人的にはカプセル化は使用者から詳細を隠すためのものであるから、参照によって内部に手を加えるのが使用者でなければ問題無いと思っています。複数オブジェクト間で同じ参照を持たせて狭域のグローバル変数っぽく使ってみたりしたことがあります（これが良いか悪いかは微妙ですが）。
イミュータブルの話は説明するのがむずいので助かります。
ありがとう。それしか言葉が見つからない
生命医科学系のデータ解析を行うために勉強をしている大学生です。非常に面白く参考になる動画で、シリーズ全部視聴しました。データ解析の文脈だとまた目的が違うものと思うので、この動画の内容が僕の実務にどれだけクリティカルに関わるかはわかりませんが（対照的に、環境構築の動画はものすごく参考になりました）、頭の中でモデルをどのように整理して考えるか、それがプログラムの形でどのように表現されるのかという、「物事を頭の中で整理、理解するための方法論」という意味だけでもとっても有意義な内容でした。おそらく沢山の実務と勉強を通して、ゆっくりと投稿者さんの中で作り上げられてきた理解の形なのだと思います。それが全部で20分と少しで、しかもとても平易に簡潔に伝えられているというのは、衝撃です。
惜しむらくは、
①これだけ高度な視点で物事を理解する必要のある作業を日常で要求されない人からするとこの動画の有益さがわからない
②やはりある程度OOPのパラダイムで書かれているコードに触れてないと意味がわからない
ために、再生回数が伸びないことですね。随所に登場する例が必要十分だったり、図式での説明が適切に使用されていたりして、目的とする理解の状態に最短で到達できるクオリティーの高い動画になっているという印象です。相当な労力の結晶であることは分かる人が見ればわかるのに、あまり広く知られていないのが残念です。正直、これまで見てきたプログラミング関連の動画の中でダントツトップで有益な動画でした。
これだけ長文を書いたのも、コメント欄を見ていると、説明不足で非建設的な批判コメントがあったり（大変丁寧で大人な対応をされていると感じました）、あまり評価されている印象がなかったため、少しでもその真価を理解して応援している人がいると感じてほしいという動機もあります。これからの動画の投稿も楽しみにしています。
ありがとうございます！
すばらしい。イミュータブルの存在意義を理解できていなかったけど、言語化できていないモヤモヤが一つ取れました。
開発の経験によって感想が変わりそう。技術水準がそろっていない大きめの開発で他人による 参照先すり代わり の厄介なバグ経験をしていないと、一見遠回りなだけに見える。この設計の意味を理解できないかも。
その通りなんだけど、言語によって参照してるのか複製してるのか分からんのが悩ましいのよね。。。
引数にせよ戻り値にせよ、参照と複製とて型が違うとか、両方存在しているならありがたいけど、「この場合はデフォルトは参照で、複製したい場合は処理増やしてね」とか、初見言語だと分かんない(T_T)
ところで、ここで紹介してる言語は・・・Python？
はい、Pythonです
メモリを意識しない言語だと厳しいですよね（苦い経験があります）
3:21 合成と集約の違い（下記の要約が間違っていたらすみません）
合成は、全体オブジェクト内で部分オブジェクトを生成する。
集約は外部で部分オブジェクトを生成したあとに、それを全体オブジェクトに引数として渡す。
プログラマ達はなんで自分と意見が違うというだけですぐ喧嘩腰になっちゃうんだろうね
せっかく自分で労力をかけて勉強したものを無料で公開してくださっているんだからまずは感謝が先なんじゃないの？
対話力を鍛えましょ🔥
オブジェクト指向の本質は、保守性とカプセル化ということで良いんだろうか？
流石に要約しすぎたかもしれない。
カプセル化も保守性の一部だと思う
だからオブジェクト指向の本質？は保守性と思う
カプセル化だって不用意なアクセスを断つ事でバグを防ぐし、役割を分けられるから管理も簡単になる
継承も同じコードを複数書かなくて良くなるからアプデでの更新忘れを防げる⇒保守性
ポリモーフィズムも同様⇒保守性
そもそも大きな勘違いをしてます。
original_obj が本体で、retrieved_obj が参照だと言いたいようですが。これは、どちらも参照です。Someインスタンスの本体はメモリ上にだけ存在し、どちらもそのメモリ上のインスタンスを参照してるという点は同じです。変数名が違うだけです。
合成？というのがこの人のオリジナルの考え方でしょうけど、この動画の合成の場合も結果は同じです。Someインスタンスの作成をクラス内でやるかクラス外でやるかという違いしかありません。クラス内でobjを作ったとしても結局、get_obj() で参照を返してるわけですから。 original_obj = get_obj() retrieved_obj = get_obj() として使われる可能性があるので、結局おなじことです。
クラス外部で変更されることを防ぐには get_obj() を無くして、get_obj()の参照が必要になる様な外部の処理をすべてクラス内部に実装するべきです。objが変更されたくない場合は、objをクラス内部だけで管理すべきです。それを外部で管理させるとカプセル化の意味が無いです。
そもそもカプセル化の役割は隠蔽や外部アクセスの拒否ではないですよね。なぜそのような間違った解釈をしてるのか疑問です。あなたがそのような使い方を望んでるだけであって、それがカプセル化ではないです。
そもそもプログラム全体も一つのカプセルみたいなものですよね。その全体の中に子カプセルを用意して、処理をグループ化することでプログラム全体を調べる必要が無くなるのがカプセル化の強みです。それをグループ外から操作したり参照したりすれば、グループ化のメリットが無くなるのはあたりまえな話です。カプセルの外から参照が必要になる様な作り方をまずやめるべきです。言語のデメリットであるかのように説明されてますが、それは単にあなたの使い方がおかしいだけです。
なんだろう、こんなこと言いたくないが・・・
「参照の問題」は投稿者のオブジェクト指向の理解がおかしいんじゃないですかね。関連（Association）って知ってますかね？
あと、Haskellの純粋関数型言語だとか、Rustの所有権の話だとか、ちょっとかじった知識をとってつけてるだけにしかみえないですよ。
あなたのフィードバックに感謝します。あなたのような視聴者からの意見や指摘は非常に有益です。
自分の理解を動画にしているので、ご不快に思うところがあるかもしれません。私の勉強不足な部分が見えたなら申し訳ございません。
説明に誤りを正すためにどの部分が間違っているのか、具体的に教えていただけますか？
また、私の理解を深めるために参考になる資料やリソースがあれば、それも共有していただけると幸いです。
コメント欄だと長くなってしまうのなら、ビジネス関係のお問い合わせメール宛でも構いません。
@@amazkaede 0:51-
『参照先の値が変わったから、カプセル化（データ隠蔽）が破られた』という主張がヘンでしょ。
もちろん包含関係の場合には、参照先のオブジェクトを他から変更されたくないというケースもあるでしょうが、そんなのオブジェクト指向の世界では稀です。
もしかしてあなたはオブジェクト指向をコンポーネント指向かなにかのように捉えてしまっているのかな？
返信コメントありがとうございます。私の動画の説明が間違っていることで誤解を与えたようで申し訳ございません。
カプセル化は、オブジェクトの内部状態を外部から直接アクセスできないようにすることで、オブジェクトの状態を保護するものです。これにより、オブジェクトの状態が意図しない方法で変更されるのを防ぐことができます。
あるオブジェクトが別のオブジェクトを参照していて、その別のオブジェクトの値が変更されたとしても、元のオブジェクトの状態は変更されません。
この状態は集約です。
本動画では、合成のはずが意図せず集約になっていて、予期せず値が変更されてしまう場合はカプセル化が破られるという内容を説明しています。
このようなケースは稀かもしれませんが、起こりうることなので……。かなり限定されたケースの話をしてしまったと後悔しています。
私の説明の間違いが酷い誤解を与える内容になってしまったこと、お詫び申し上げます。今後は、より正確な説明を心がけたいと思います。
具体的な指摘をせず、芯をずらしたことだけ言いながらただ「おかしい」とだけ言うこの感じ、反論を避けて優位性を保とうとするかなりずるい姿勢だと思うんですよね。
投稿者の方が平身低頭へりくだって問い返して、やっと少し具体的なことを言い始めたと思ったら「～というケースもあるでしょうが、そんなのオブジェクト指向の世界では稀です」。
つまり「投稿者が言うような問題は（稀かもしれないが）存在する」と言っているわけで、大上段から「おかしい」「ヘン」と言っていたところからずいぶん後退したなあという感想です。
カプセル化の破壊は変更容易性の問題なので、参照で変更可能なことがカプセル化の破壊と例える表現は語弊を残す点かなとは自分も思いました
意図しないアクセス手段を排除していないことが問題のためで、これは参照の問題というより設計の課題です
なので文体は乱暴ですが、主張自体は真っ当かなと思います
ある複数のオブジェクトが一つのオブジェクトを参照していて、管理を共有するモデルは決して珍しくはありません
大切なのはそのパラメータを利用する側にいかに意図した制約を課すかです
そもそもイミュータブルなインスタンスを作り直せる状態はカプセル化を果たしたと言えるのか？という問題もあります
Rustでも参照をパスしたりmut変数の参照を作ってパラメータの共有は可能ですしね