Скачать с ютуб 【概要速修】なぜプログラミングで設計が必要か?必要な良い設計、コード、考え方などについて広くざっくり解説(疎結合高凝集、継承とコンポジション、インターフェース等)【プログラミング初学者向け】 в хорошем качестве

【概要速修】なぜプログラミングで設計が必要か?必要な良い設計、コード、考え方などについて広くざっくり解説(疎結合高凝集、継承とコンポジション、インターフェース等)【プログラミング初学者向け】

本日は、プログラミングにおける設計、良い設計、コードをざっと紹介する動画です. プログラミングを始めてまだ間もない、またはこれまでは特に指摘されなかったが、コードレビュー時などに良い設計を求められたり、指摘されることが増えてきた方を対象になぜ設計が、どんなことを意識することが必要なのかをざっくり解説します. 影響範囲を抑えるため、今後の仕様変更に耐えられるようにするため、さまざまな先人のプログラミングの設計の考え方、工夫を見ていきます. なぜ疎結合が良いのか、何を大事にして考えるべきなのか、カプセル化、インターフェース、継承、コンポジション、DependencyInjection、SOLID原則など学ぶことはさまざまなです. それらの概要を抑え今後のプログラミングで設計を進めていく基礎知識を紹介します. この動画をきっかけにさまざまな概念や考え方を習得していっていただけたら幸いです. 今回はそのようななぜプログラミングで良い設計がどんな設計が求められるのかを22分で紹介します. ThothChildrenは数分でアルゴリズムのポイントをわかりやすく簡単に理解できること、メリットデメリットの把握を目指した解説を投稿する動画チャンネルです. 【リンク】 ThothChildren - エンジニアをサポートするサイト http://www.thothchildren.com/top 【概要速修】プログラミングを学んだ後にできることをざっと知る(何が作れるかわからない人向け、アプリ開発、自動化等々)【プログラミング初学者向け】    • 【概要速修】プログラミングを学んだ後にできることをざっと知る(何が作れるか...   【概要速修】Stable Diffusion(テキストから画像生成)はどうやって実現するのかざっくり仕組みを知る(DiffusionModel,Deep Learninig)【機械学習解説動画】    • 【概要速修】Stable Diffusion(テキストから画像生成)はどう...   【概要速修】𓀀ヒエログリフ𓅓でプログラミング|古代エジプトの文字𓅓|(Parserを活用してAST生成しTranspile)【JavaScript】    • 【概要速修】𓀀ヒエログリフ𓅓でプログラミング|古代エジプトの文字𓅓|(Pa...   【概要速修】C言語やC++がコンパイルされて実行される仕組みをさっと知りたい. なぜ異なるOSで実行できないかなど【初心者向け】    • 【概要速修】C言語やC++がコンパイルされて実行される仕組みをさっと知りた...   【概要速修】JavaScriptはどう動く?仕組みをさっと知りたい【初心者向け】    • 【概要速修】JavaScriptはどう動く?仕組みをさっと知りたい【初心者向け】   【数分解説】K-means法(k平均法) : クラスタ数を指定してデータを分割、クラスタリングしたい    • 【数分解説】K-means法(k平均法) : クラスタ数を指定してデータを...   【数分解説】ベイズとかp(A|B)、画像や文字列を絡めた確率、条件付き確率のイメージを持てるようにする解説動画【初学者向け】    • 【数分解説】ベイズとかp(A|B)、画像や文字列を絡めた確率、条件付き確率...   【数分解説】ラグランジュの未定乗数法 : 拘束条件を守りつつ関数の値を最大化するパラメータを求めたい【Lagrange multiplier】    • 【数分解説】ラグランジュの未定乗数法  : 拘束条件を守りつつ関数の値を最...   【数分解説】レーベンバーグ・マーカート法 : 非線形な式を扱う場合でも関数の極小値を高速に求めたい:関数フィッティングなどに応用【Levenberg–Marquardt algorithm】    • 【数分解説】レーベンバーグ・マーカート法  : 非線形な式を扱う場合でも関...   【数分解説】ガウス・ニュートン法 : 非線形な式を扱う場合でも関数の極小値を高速に求めたい:関数フィッティングなどに応用【Gauss Newton Method】    • 【数分解説】ガウス・ニュートン法  : 非線形な式を扱う場合でも関数の極小...   【数分解説】ニュートン法による最適化 : 非線形な式を扱う場合でも関数の極小値を求めたい:関数フィッティングなどに応用【Newton Methods】    • 【数分解説】ニュートン法による最適化  : 非線形な式を扱う場合でも関数の...   【数分解説】拡張カルマンフィルタ : 非線形でもノイズを考慮してリアルタイムに直接観測できない状態を推定したい【Extended Kalman FIlter】    • 【数分解説】拡張カルマンフィルタ  : 非線形でもノイズを考慮してリアルタ...   【数分解説】カルマンフィルタ : ノイズを考慮してリアルタイムに直接観測できない状態を推定したい【Kalman FIlter】    • 【数分解説】カルマンフィルタ  : ノイズを考慮してリアルタイムに直接観測...   【数分解説】ベイズ更新 : データを受けて確率を逐次的に更新して推定したい    • 【数分解説】ベイズ更新 : データを受けて確率を逐次的に更新して推定したい   [内容の抜粋] クラスに明確な役割を決めたことです. どんなクラスが必要で、どんなことをすべきかを決めています. 税金とクーポンです. 税金に関わる修正対象は税金クラスのみです、どのファイルも大きくなりすぎることはありません. やることが少なかったりクラスが大きい場合は、役割が正しくないかもしれないので、見直す方が良いでしょう. 単一責務の原則では、一つのクラスが持つ役割は一つにすべきという考え方があり、クラス設計時に意識できると良いです. またイント型の数字をそのまま使うのではなく、年齢というクラスを作ることも必要な時があります. 例えば年齢は0未満にはならないので、そういった値をクラスの関数で設定付加にできます.年齢というただの数字でも想定される前提をクラスに押し込めることができることで、例えばユーザクラスやその他の部分が意識しなくてすみます.そういったクラスを値オブジェクトと読んだりもします. 親クラスを子クラスで置き換えても同じように期待した動作にすべきという原則をリスコフの置換原則と呼びますが、これを満たせていません. 想定しない条件が子クラスで加えられてしまうためです. 継承が難しい時の一つの回避策は、合成、コンポジションを活用することです.特性を継承するのではなく、特性を持つという形にすることで、重複するコードを減らしつつ、クラス間の過度な依存を回避します. 先ほどの例では、ペンギンや鳥に移動手段を持たせてそれぞれのクラスで実装させます. diveが関係ない鳥は全く気にしなくてすみます. ペンギンクラスもfly関数を意識せずdive関数だけ用意すれば良いのです.コンポジションは継承よりも余計な依存関係を持たせないことに価値があります. コンポジションを生かす方法として、Dependency Injectionがあります. これは依存性の注入とも呼び、依存するクラスやオブジェクトを外から与えてやることで、そのクラスに一才の変更なく、新しい振る舞いを与えることができます.まさに依存するものを外から注入してやるという形です. 仕様変更や修正、テストを簡単にしたいことが始まりでした. そのためには影響範囲を押さえて、機能追加しやすい設計が必要です. あるべき状態は、どれも同じことですが、 疎結合高凝集、依存を減らす、役割を明確にするなどがあります. カプセル化やインターフェースを活用、継承とコンポジションの使い分けなどがありました. どんな仕様かによって最適な設計は異なり、実装上の理由を考慮した設計もあり得ます. ドメインに基づいたクラス設計を行うドメイン駆動設計が参考になるため、是非学習してみてください. また、これまでの話からもわかるように、依存する方向は可能な限り抽象度が高い方向へが原則になります. 強い理由がない限りやってはいけないアンチパターンを軽くみてみます. 世の中にはさまざまな名称がついたやるべきではない設計が紹介されているので、ご確認ください. コードは読みやすく、理解しやすくが大事です. 一つの対策はコメントを書くことです. ただ、コメントを書かず関数名と処理を見て意図がわかることが最も理想です. 実際には、やむを得ずコメントを書くべきところがあります. その時は、何をしているかではなく、何のためにしているかが必要です. また 言語によってはconstをつけるというのもあります. 不変かどうかは、大事な特性です. 関数やコンストラクタに与えられた引数が中で変更されないと保証されるなら、調査部分が限定されます. コードの意図も分かりやすく、意図に反した実装はコンパイルエラーになります. 賛否両論はあるものの、メンテナンス性もデバッグ性も上がります. constが邪魔になる時は、当初の設計意図と異なる変更を自身が咥えようとしていることになるため、要確認です. 何より大事なのは良いクラス、変数、関数の名前をつけることです. 名前はそのクラスの役割と責務を表現しています. 名前が疎かだと変更する人が意図を汲み取れず、不適切な機能や修正でクラス設計を崩壊させる原因になります. 機能追加時は、追加先クラスを考えますが、クラス名を見て判断することが多いため、適切な名前が必要です.コントローラ、マネージャーといった名称は、何も役割を伝えないので、避けるようにしてください. デザインパターンを活用することも一つコードレベルで良い設計をする参考になり得ます. パターンを使うことで困り事の鮮やかな会報を把握すること、他の人に一発でどういう目的でそのパターンを入れているかわかること、設計時にほか開発者と相談するときの共通言語になることなどが挙げられます. よく言われることですが、これを何にでも使えるゴールデンハンマー、銀の弾丸として当て込もうとしてはいけません. 背負い投げを覚えて、重い家具の運搬に活用するようなものです. あとは不穏なコードの症状に気づけることも大事です. 先ほど紹介したアンチパターンに近しいですが、もっと症状寄りで細かく、これだけで完全にアウトとは言えません. あくまで症状です. 詳しくは、コードの匂いなどで検索してみてください. 設計が大事とお伝えしましたが、どうしてもそれを破らなくては商品にならないことがあります. 速度や性能が課題になる時です. 設計としては綺麗でも、商品としてUXが悪いのは許されません. どこかで設計の綺麗さを諦める必要があります. ただ、諦めは工程の終盤で行うべきで、初めから壊してしまうのは推奨されません.