“状態を制御するということは、セキュア・バイ・デザイン 安全なソフトウェア設計 などでも述べられているように、考え方としては一般的です。しかし、状態の制御を操作の制御より優先度高く考えようとしている人”
良い記事
なぜ日本人は状態や性質を持つ「対象」の話をしないのか？「対象を操作し対象が変わる」「対象により操作の意味が変わる」のに誰も対象の話をしない。だからお前らはオブジェクト指向が分からないと言われるんだよ！
操作より状態が先、よりも仕様が先では？(そんな曖昧な仕様を独断で実装するなという)
id:turanukimaru そういえば卒論発表の時、審査の先生が質疑でOOのことを「対象指向」って言ってたのを思い出したのであった。
直接DOMをいじってグチャグチャにしてたjQuery時代に現れたreactの話に通じるものを感じた。結局手続き的な記述で複雑なシステムを表現するには限界があるんだよね
深夜で長文すぎて読めない。 状態--(操作)-->状態 こういう図を出して説明した方がいい。状態を持つオブジェクトもワークフローもステータス遷移も全部これ。逆に文章だけで説明しようとしてるのがすごいわ。
伝えたいことはいいことを言ってると思うものの、そうすることで何が良くて、そうしないとどんな悪いことが起こるのかがこの例だとイメージ難しいような気がする
関連レコードの注文情報等は削除できないから、退会時にuserレコードは削除せず、無効化するが、その際に個人情報保護もありEmailも消すので、再入会は問題ない。Emailがあって無効化状態があるのは気持ち悪くない？
なるほど？
これは重要な話。「事前条件•事後条件」は契約による設計のそれと意味が違ってシステムやデータベースがもつ状態を表しているので「事前状態•事後状態」のように変えたらいいかも。
必要な操作(関数)を洗い出すタイミングと、操作のIFを考えるタイミングと、操作の動作を考えるタイミングとで、おそらく後者2つの前にやることかな。実際は頻繁に行き来するので、都度先に状態を、な気がした。
記事の主張は良いと思う一方で、業務は操作で設計されていることが多く、操作の方がユーザーに理解されやすい……みたいな話もあるとは思う。
なるほどよさそう、宣言的UIとかそうだもんな、とは思いつつ、あまり具体的なイメージをつかめなかった。宣言的UIでもmutationは命令的だし…。
これは堅牢だが美しいコードではないはず。状態遷移はコードに表れない（表すと冗長で柔軟性を失う）プログラムの本質ではある。
処理前の状態と処理後の状態をまず考える
関数の考え方だ
Immutable Data Modelとの整合を考えたい
何かの処理を作るときに設計の前に要件を定義しようって話？要件がなければinsertするだけになる気はする（それで破綻するかどうかは企画者の責任だし、FBするにも後手になるのは仕方ない気が）
この投稿者自身の「成功すれば」もダメなif文。例えば、削除しようとしたファイルがすでになかった場合、WindowsのDELは「削除できません」と警告を出し、UNIX系のrmは何も返さない。アサーションを書くにも必要な観点。
筆者の注釈にもあるが、この話はUI以前の話と思う。要件→操作(しばしばUIが絡む)でなく、要件→状態(データ構造)→表現(UI)ないし操作(mutation)という順序。
プログラムレベルで状態を排除しても、システム全体は状態からは逃れられない / 例題は事前事後以前に、ユーザの一意性やメアドの重複をどう考えるかいった不変条件もしくはモデルの視点が足りてない気がする。
両者のコード例が欲しかった。
言い方が下手すぎてCTO向いてない。
操作より状態・性質に着目する
“状態を制御するということは、セキュア・バイ・デザイン 安全なソフトウェア設計 などでも述べられているように、考え方としては一般的です。しかし、状態の制御を操作の制御より優先度高く考えようとしている人”
良い記事
なぜ日本人は状態や性質を持つ「対象」の話をしないのか？「対象を操作し対象が変わる」「対象により操作の意味が変わる」のに誰も対象の話をしない。だからお前らはオブジェクト指向が分からないと言われるんだよ！
操作より状態が先、よりも仕様が先では？(そんな曖昧な仕様を独断で実装するなという)
id:turanukimaru そういえば卒論発表の時、審査の先生が質疑でOOのことを「対象指向」って言ってたのを思い出したのであった。
直接DOMをいじってグチャグチャにしてたjQuery時代に現れたreactの話に通じるものを感じた。結局手続き的な記述で複雑なシステムを表現するには限界があるんだよね
深夜で長文すぎて読めない。 状態--(操作)-->状態 こういう図を出して説明した方がいい。状態を持つオブジェクトもワークフローもステータス遷移も全部これ。逆に文章だけで説明しようとしてるのがすごいわ。
伝えたいことはいいことを言ってると思うものの、そうすることで何が良くて、そうしないとどんな悪いことが起こるのかがこの例だとイメージ難しいような気がする
関連レコードの注文情報等は削除できないから、退会時にuserレコードは削除せず、無効化するが、その際に個人情報保護もありEmailも消すので、再入会は問題ない。Emailがあって無効化状態があるのは気持ち悪くない？
なるほど？
これは重要な話。「事前条件•事後条件」は契約による設計のそれと意味が違ってシステムやデータベースがもつ状態を表しているので「事前状態•事後状態」のように変えたらいいかも。
必要な操作(関数)を洗い出すタイミングと、操作のIFを考えるタイミングと、操作の動作を考えるタイミングとで、おそらく後者2つの前にやることかな。実際は頻繁に行き来するので、都度先に状態を、な気がした。
記事の主張は良いと思う一方で、業務は操作で設計されていることが多く、操作の方がユーザーに理解されやすい……みたいな話もあるとは思う。
なるほどよさそう、宣言的UIとかそうだもんな、とは思いつつ、あまり具体的なイメージをつかめなかった。宣言的UIでもmutationは命令的だし…。
これは堅牢だが美しいコードではないはず。状態遷移はコードに表れない（表すと冗長で柔軟性を失う）プログラムの本質ではある。
処理前の状態と処理後の状態をまず考える
関数の考え方だ
Immutable Data Modelとの整合を考えたい
何かの処理を作るときに設計の前に要件を定義しようって話？要件がなければinsertするだけになる気はする（それで破綻するかどうかは企画者の責任だし、FBするにも後手になるのは仕方ない気が）
この投稿者自身の「成功すれば」もダメなif文。例えば、削除しようとしたファイルがすでになかった場合、WindowsのDELは「削除できません」と警告を出し、UNIX系のrmは何も返さない。アサーションを書くにも必要な観点。
筆者の注釈にもあるが、この話はUI以前の話と思う。要件→操作(しばしばUIが絡む)でなく、要件→状態(データ構造)→表現(UI)ないし操作(mutation)という順序。
プログラムレベルで状態を排除しても、システム全体は状態からは逃れられない / 例題は事前事後以前に、ユーザの一意性やメアドの重複をどう考えるかいった不変条件もしくはモデルの視点が足りてない気がする。
両者のコード例が欲しかった。
言い方が下手すぎてCTO向いてない。