並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 17 件 / 17件

新着順 人気順

イミュータブルの検索結果1 - 17 件 / 17件

タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。

イミュータブルに関するエントリは17件あります。 設計プログラミングjavascript などが関連タグです。 人気エントリには 『ドメイン駆動設計とイミュータブルなクラス設計』などがあります。
  • ドメイン駆動設計とイミュータブルなクラス設計

    クラスをイミュータブルに設計するパターンの紹介 ・閉じた操作 ・withメソッド ・イベントリポジトリ&集約ファクトリ

      ドメイン駆動設計とイミュータブルなクラス設計
    • JavaScript にイミュータブルな配列操作メソッドを導入するプロポーザルについて

      この記事では、現在 Stage 1 のプロポーザル Change Array by copy について解説する。 プロポーザルの詳細については、https://github.com/tc39/proposal-change-array-by-copy を参照してほしい。 また、ここで紹介した仕様に関しては今後更新されていく可能性がある。 概要 Change Array by copy は、簡単にいえばイミュータブルな配列操作メソッドを導入するプロポーザルである。 JavaScript の配列には多くのインスタンスメソッドがあり、それらを使って配列を操作できる。 配列のインスタンスメソッドには、ミュータブルなもの、つまりもとの配列を変更することによって配列を操作するタイプのものがいくつかある。 たとえば、Array.prototype.push や Array.prototype.pop、A

        JavaScript にイミュータブルな配列操作メソッドを導入するプロポーザルについて
      • なぜ昨今のJavaScriptではイミュータブルであるべきと言えるのか歴史的背景を踏まえて言語化する - Qiita

        先日JavaScriptに慣れていない人のコードをレビューする機会があり、constで宣言されたオブジェクト内部に副作用を与えている記述がありました。 その時に「今の動作に問題ないけど、今風のJSならイミュータブルの方が良いかも」と指摘したものの、JSに疎い人からすれば背景が分からないはずで、理由を自分なりに説明したものの案外言語化が難しかったことがありました。 難しい理由として、イミュータブルであることは実利面と同時に、Facebook発祥のトレンドという側面も多分に含んでおり、JavaScript自体の潮流も踏まえておく必要があるからです。 今回は実利面に加えてトレンド面も交えて、なぜイミュータブル性がJavaScriptで重宝されるのかを見ていきましょう。 フロントエンドの世界では状態を持ち、時間やインタラクションと共に変化するから サーバーサイドの世界から見た場合、HTTPはステー

          なぜ昨今のJavaScriptではイミュータブルであるべきと言えるのか歴史的背景を踏まえて言語化する - Qiita
        • 並行・並列プログラミングと同期・排他制御とイミュータブル性の話〜その1「背景: クロック周波数の停滞とコア数の増加」 - Qiita

          大学の授業で講義資料を作ったので,Qiitaにも展開しておきます. 背景: クロック周波数の停滞とコア数の増加 コンピュータはクロック周波数に同期して計算をします.おおむね1秒間にクロック周波数の数で示されるだけの数の機械語命令を実行できると考えると良いです.たとえばクロック周波数が1GHzであれば,1GHz=1,000MHz=1,000,000(百万)kHz=1,000,000,000(10億)Hzですので,1秒間に1,000,000,000(10億)個の機械語命令を実行できるというような感じです.もちろんこれは概算です. いわゆるヘネパタ本(J. L. Hennessy & D. A. Patterson: Computer Architecture: A Quantitative Approach, 6th edition. Morgan Kaufmann, 2017; 邦訳 中條・

            並行・並列プログラミングと同期・排他制御とイミュータブル性の話〜その1「背景: クロック周波数の停滞とコア数の増加」 - Qiita
          • DDDのエンティティはイミュータブルな実装にしてもいいの?(サンプルコード有り)[ドメイン駆動設計 / DDD] - little hands' lab

            本記事はドメイン駆動設計(DDD) Advent Calendar 2021の13日目の記事です。 エンティティとイミュータブル性 オブジェクトをイミュータブル、つまり内部状態を変えない実装にすることで可読性やマルチスレッド対応性が向上することがあります。 エンティティはモデリング上の定義はミュータブルなものですが、実装方法をイミュータブルにすることは可能です。 (DDDでは、エンティティはミュータブルもしくはイミュータブル、値オブジェクトは必ずイミュータブルという定義です。詳しくはこちら) DDD基礎解説:Entity、ValueObjectってなんなんだ - little hands' lab 本記事ではエンティティをイミュータブルな実装にするサンプルコードと合わせて、イミュータブルにした場合の旨みを感じられるコードを紹介します。 イミュータブルなエンティティ実装の例 エンティティをイ

              DDDのエンティティはイミュータブルな実装にしてもいいの?(サンプルコード有り)[ドメイン駆動設計 / DDD] - little hands' lab
            • [TypeScript]型の基本とイミュータブルな追加・更新・削除 ~ 際限なき型地獄 ~ - Qiita

              今回はTypeScriptの型の基本を扱っていきたいと思います。練習用の題材として、データ操作の基本中の基本、追加・更新・削除を行う関数をイミュータブルの形で実装していきます。 前提条件 イミュータブルの形を崩さないように、狂ったようにreadonly 一度生成したオブジェクトの書き換えは許さない interfaceにはプライマリーキー用とデータの用のインターフェースを用意 データの構造は後から変えられるようにする addItemは自動的にidを採番するため、入力データはidがあっても無くても通るようにする もちろん他に関係ないプロパティが来たらエラー updateItemはidが必須、それ以外のデータは任意 送られてきたプロパティだけ置き換え deleteItemはidが必須 それ以外のデータは任意で関連プロパティはあってもエラーにはしない この条件を満たすための型設定を各所で行います

                [TypeScript]型の基本とイミュータブルな追加・更新・削除 ~ 際限なき型地獄 ~ - Qiita
              • イミュータブルでゆこうに参加してきた - 天の月

                modeling-how-to-learn.connpass.com 今日はこちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。 会で話されていたこと イベント資料 イミュータブルデータモデルの極意~川島義隆さん~ 川島さんの問題意識~Division into cases~ Dataの場合分け EventとResourceの関係性 EventとResourceのサブタイプ Resource同士の関連付けをする際のコツ 記録として残すEvent, 残さないEvent ドメイン駆動設計とイミュータブルデータモデルの素敵な関係~増田亨さん~ イミュータブルについての厳格性 必ずイミュータブルにする際の設計パターン 増田さんがイミュータブルに拘る理由 ドメインイベントの観点から再考するソフトウェア設計~かとじゅんさん~ ドメインイベントとは ドメインイベントはなぜ有用か

                  イミュータブルでゆこうに参加してきた - 天の月
                • イミュータブルが大事な理由、そしてImmerで簡単実現!

                  始め JS,特にReactを勉強してるとよくimmutabilityという言葉を聞きます。最近immerを使ってみて不意にimmutabilityは何で重要だったっけ?と思ったので、投稿します。 1. immutabilityとは immutabilityは不変性、つまり変わらない性質という英単語です。 プログラミングでのimmutabilityは「stateを変更しないこと」とも言えます。(韓国では漢字の方の「不変性」を採用していますが、日本語あまり分からないので今回は英単語そのまま書きます。) ここで、「stateを変更する」ということは正確に何を意味するのでしょうか?一番簡単な例を見てみましょう。

                    イミュータブルが大事な理由、そしてImmerで簡単実現!
                  • JavaScriptでイミュータブルに配列を操作するメソッドまとめ

                    Reactでアプリケーションを作っていくときなど、純粋な(副作用のない)関数を最大限使うことが推奨される。 純粋関数(Pure Function)であるためには、基本的に以下の条件を満たしておく必要がある。 関数は少なくとも1つの引数を持たなくてはならない 関数は1つの値、または1つの関数を返さなくてはならない 関数は引数を変化させてはいけない 3つ目の条件がなかなかのくせもので、意識せずにいると思わぬ副作用を起こしてしまうので注意が必要。特にJavaScriptの場合、配列を操作するときにはもとの配列を直接操作してしまっていないか意識する必要がある。 JavaScriptのArrayオブジェクトに属するメソッドには「破壊的な」メソッドが存在しており、「破壊的な」メソッドはもとの配列を直接操作(破壊)してしまう。一方で「非破壊的な」メソッドとは、配列を直接操作するのではなく、もとの配列のコ

                      JavaScriptでイミュータブルに配列を操作するメソッドまとめ
                    • 【Flutter, Dart】ミュータブルの代償とイミュータブルの代償、そしてfreezed - Qiita

                      はじめに 本記事は The Mutability Tax をベースにしています。 意訳・抜粋しまくったので翻訳記事と呼ぶには忍びないですが、記述の足らない箇所があれば元の記事を参照してください。 筆者の David Morgan 氏はGoogleのソフトウェアエンジニアです。 元記事の公開は2019年7月15日です。 本文中に登場するコードは Dart で記述されています。 The Mutability Tax では、MutableとImmutableそれぞれの設計によって生じるコードメンテナンスコストのことを Tax(税金) と形容しています。 本記事では 代償 と表現します。 3点要約 Mutableな型はバグを生みやすいです。 Immutableな型も正しく扱わないとコードが肥大化してバグを生みやすく、遅くなります。 コード生成(freezed)の力を借りて、簡単に安全な型を定義しま

                        【Flutter, Dart】ミュータブルの代償とイミュータブルの代償、そしてfreezed - Qiita
                      • Amazon ECR でイミュータブルなイメージタグのサポートを開始

                        Amazon Elastic Container Registry (ECR) で、イミュータブル (変更不可能) なタグのサポートを開始しました。これは、イメージタグが上書きされないようにするための機能です。これまでタグは上書き可能だったため、イメージを一意に識別するには手作業による識別が必要でした。しかし、イミュータブルタグを使用することにより、CI/CD ビルドオプションに簡単に統合できる共通の直感的な手法を使用できるようになりました。 お客様は Amazon ECR のイミュータブルタグにより、イメージを追跡して一意に識別するための信頼できるメカニズムとして、イメージの記述タグを使用できるようになります。これまでタグは上書き可能だったため、開発者はどのイメージがデプロイされているかを知るためにイメージの SHA を使用する必要がありました。タグをイミュータブルとして設定できるように

                          Amazon ECR でイミュータブルなイメージタグのサポートを開始
                        • イミュータブルでゆこう

                          概要 2021/11/24に開催された下記勉強会のメモです セッション イミュータブルデータモデルの極意 データの種類 Event -> 日時属性を持つ Resource -> ライフサイクルで属性が変わる イベントの7W3Hがリソースと関連を持つ リソース同士では依存関係があるか?ライフサイクルを同じとするかで場合分け リソースのサブタイプは「区分」で分類 イベント同士の関係は時系列の並びで関係が変わる。時系列は変更してはいけない 例)注文に請求IDを保持、請求が決まった時に更新だと後から情報を変えてしまう事になる->中間テーブルを使う イベントが連なる場合はそれらを束ねたロングタームのイベントを作る リソースの関連とそれに関するイベントは別で識別する どのイベントを記録として残すか、が設計 お金を産むもの、記録がないとお金を失うリスクがあるものを取捨選択 記録すると決めたイベントは変更

                            イミュータブルでゆこう
                          • 技術用語を比喩から学ぼう ! - 第 3 回「イミュータブル」- builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS

                            builders.flash 読者の皆さん ! こんにちは ! テクニカルトレーナーの吉田慶章です。 builders.flash には様々なカテゴリがありますが、本記事は「How to be a Developer」というカテゴリーに所属しています。エンジニアを目指している方やインフラエンジニアからアプリケーションエンジニアにロールチェンジを目指している方などを読者層とし「どうやってエンジニアになれば良いのだろう ?」をテーマにしています。 そして、本記事は「初学者が理解しにくい技術用語を現実世界の比喩で紹介する」シリーズです。トレーニングの場でも比喩を使って説明することが重要になり、私自身とても意識しています。 比喩シリーズ 第 3 回の技術用語は「イミュータブル」です。 サーバーを「イミュータブル」に運用する 「イミュータブル」インフラストラクチャ 「イミュータブル」なオブジェクトを

                              技術用語を比喩から学ぼう ! - 第 3 回「イミュータブル」- builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
                            • 並行・並列プログラミングと同期・排他制御とイミュータブル性の話〜その2「スレッドと同期・排他制御」 - Qiita

                              大学の授業で講義資料を作ったので,Qiitaにも展開しておきます. この記事シリーズでは,並行・並列プログラミングについて,要(かなめ)となる同期・排他制御の役割をCとJavaを例に簡単なプログラム例を示します.次に同期・排他制御の問題点をCのプログラム例とともに示します.そしてElixir(エリクサー)によって実現されている,全てをイミュータブルにすることによる利点について示します. シリーズ 並行・並列プログラミングと同期・排他制御とイミュータブル性の話〜その1「背景: クロック周波数の停滞とコア数の増加」 並行・並列プログラミングと同期・排他制御とイミュータブル性の話〜その2「スレッドと同期・排他制御」(本記事) 並行・並列プログラミングと同期・排他制御とイミュータブル性の話〜その3「同期・排他制御の2つの問題点」 並行・並列プログラミングと同期・排他制御とイミュータブル性の話〜その

                                並行・並列プログラミングと同期・排他制御とイミュータブル性の話〜その2「スレッドと同期・排他制御」 - Qiita
                              • Reactのこともっとよく知ろう! ~ Redux基礎・イミュータブル編~

                                Reactに関することで、同じことを別の人に繰り返し説明している...ような気がしたので、 一念発起して勉強会を開くことにしました。 実装半分/解説半分で勉強会を開催予定です。 今記事は、その解説のために作成した資料ですが、この記事単体でも作業可能なように作っています。 今回扱う主な題目は FLUXとは Reduxのデータフローとは(redux toolkitは何をやっているのか) なぜイミュータブルである必要があるのか になります。 lesson1 - FLUXとは Reduxのデータフローとは(redux toolkitを実装しながら学ぶ) リポジトリを準備する 勉強用リポジトリをGithubにて準備しています。 Github takanokana/react-tag 上記リポジトリのブランチ lessson/1に切り替えて作業を行なってください。 コマンドで、ローカルサーバーが問題な

                                  Reactのこともっとよく知ろう! ~ Redux基礎・イミュータブル編~
                                • Python のイミュータブル, immutable ってなに? | 民主主義に乾杯

                                  # 1. 簡単に言えば... 変更できないオブジェクトのことをイミュータブルと言います。 反対に変更できるオブジェクトのことをミュータブルと言います。 値を変更できるオブジェクトのことを mutable と呼びます。 Objects whose value can change are said to be mutable; 値を変更できないオブジェクトのことを immutable と呼びます。 objects whose value is unchangeable ... are called immutable. 3.1. オブジェクト, 値 そして 型 - Python 言語リファレンス 3.1. Objects, values and types - The Python Language Reference immutable (opens new window) (イミュータブ

                                  • イミュータブルにデータを扱うライブラリと Stage 2 Record & Tuple

                                    【2023/05/05 変更】 ES2023 Change Array by Copy の議論によって Array に追加するメソッドが減り、同様に Tuple から取り除かれた pushed や sorted などの独自メソッドについての記述を削除 Symbols as WeakMap keys が ES2023 となったため修正 0, -0, NaN の等価性、同値性が決まったため修正 JSON.parseImmutable が別提案としてスプリットされたため修正 支持されなかった Box についての記述を削除 JavaScript におけるイミュータブル、ミュータブル JavaScript においてプリミティブはイミュータブル、つまり変更不可能です。 一方でオブジェクトは基本的にミュータブル、つまり変更可能です。Object.freeze を使って凍結することは出来ますが、アクセサプ

                                      イミュータブルにデータを扱うライブラリと Stage 2 Record & Tuple
                                    1

                                    新着記事