jboydev

flutter python C#

jboydev

flutter python C#

最近の記事

FlutterのProviderを使用した状態管理

Provider Proiver --- Flutterの優れた機能の1つであるInheritedWIdgetを使った状態管理 Providerを実装したWidget ==== 下の階層である子要素に状態や機能を提供する Redux …… グローバルに保持する実装 Provider ……. 下の階層で同じクラスの別のオブジェクトを定義して利用する Reduxでは下層の管理ができないが、Providerでは可能となる Providerで使用するInheritedWid

    • 基本情報技術者教育第4章[1]

      アルゴリズム

      • 単体テストの使い方/第5章まとめ

        テスト・ダブルとは テストの際に使われるプロダクションコードには含まれない偽りの依存として表現される全てのものを包括的に意味するものである。 テスト・ダブルには以下の種類がある ダミー スタブ スパイ モック フェイク これらのスタブを2分割することができる スタブ - ダミー、スタブ、フェイク モック - モック、スパイ モックは外部に向かうコミュニケーション(出力)を模倣する場合と検証する場合に使われる。 ここでいう外部に向かうコミュニケーションとは

        • 単体テストにおける古典学派とロンドン学派

          ロンドン学派 不変の依存を取り除く全ての依存に対してモックを使うことを推奨している。その依存がシステム内コミュニケーションを行うものなのか、システム間コミュニケーションを行うものなのか違いを意識していない その結果として ドメインクラス同士のコミュニケーションに対する検証であっても外部アプリケーションとのコミュニケーションに対する検証と同じような検証をすることになる。 => テストケースの実装の詳細と結びつき、リファクタリングへの耐性を損なう 古典学派 テストケース間で

          システム内コミュニケーションとシステム間コミュニケーション

          システム内コミュニケーションとは アプリケーション内のクラス間で行われるもの。 実装の詳細となる。 【理由】 クライアントからのリクエストを処理する際、ドメイン層にあるクラス間で行われるやり取りは観察可能な振る舞いの一部にはならないから。 この時に行われるやり取りにはクライアントが達成したいこととの直接的なつながりがない。 -> このようなやり取りをテストに結びつけてしまうと、そのテストは壊れやすくなる。 システム間コミュニケーションとは 外部アプリケーションと行われ

          システム内コミュニケーションとシステム間コミュニケーション

          モック使用、テストの壊れやすさの関係

          ヘキサゴナル・アーキテクチャ 基本的にAPは ・ドメイン層 ・アプリケーション・サービス層 で構成される ドメイン層 …… アプリケーションの核となる部分 ・アプリケーションにとって必要不可欠な機能を実現するためのビジネスロジックが含まれている。 ・競合他社のAPとの差別化を図る部分 アプリケーション・サービス層……ドメイン層の周りに位置して、ドメイン層と外部の世界とのコミュニケーションを指揮する役割

          モック使用、テストの壊れやすさの関係

          カプセル化が必要な理由

          カプセル化の目的 実装の詳細を隠す データ操作にメソッドを経由する 1.実装の詳細を隠す クラスの内部を外部クライアント(他者)からアクセスされないようにすることで、内部の整合性が外部クライアントによって壊されるリスクを減少させることができる。 2.データ操作にメソッドを経由する メソッドを解することでしかデータの操作を行えなくすることでクラスの不変条件が侵害されないようにする

          カプセル化が必要な理由

          FlutterのListについて

          //リストを作成する var list = <int> []; 書式 var リストの変数名 = <型> []; //リストへの追加を行う list.add(10);list.add(200); 書式 リストの変数名.リストの追加メソッド(追加したいもの); //リストへの代入 list[ 1 ] = 10; 書式 リストの変数名[リストが格納されている要素] = 代入したい値 ; 

          FlutterのListについて