情報更新

last update 10/13 18:05

ツイート検索

 

@mkgask
サイトメニュー
Twilogユーザー検索

Twilog

 

@mkgask

みかげあすか@mkgask

  • 1,222フォロー
  • 452フォロワー
  • 33リスト
Stats Twitter歴
3,685日(2009/09/12より)
ツイート数
59,384(16.1件/日)

ツイートの並び順 :

表示するツイート :

2019年10月12日(土)1 tweetsource

2019年10月11日(金)5 tweetssource

10月11日

@mkgask

みかげあすか@mkgask

オブジェクト指向言語が持つ「同一性」とは別物であることに気をつけてほしい。Javaでは==演算子でメモリ上のオブジェクトの同一性が確認できるが、これらはアプリケーションドメインではほとんど意味をなさない

posted at 15:07:30

10月11日

@mkgask

みかげあすか@mkgask

エンティティはモデリングと設計において特別な考慮が必要だ。連続性の繋がりを維持し、効果的に追跡できければならない。エンティティのクラス定義、責務、関連などは、特徴や属性が中心となるのではなく、「どれであるか」が常に明確になるようにするべきだ。

posted at 15:03:59

10月11日

@mkgask

みかげあすか@mkgask

オブジェクトのライフサイクルを通じて、同じ属性を持っている他のオブジェクトとであっても区別の必要がある時、そのオブジェクトがエンティティである。またライフサイクルの中で必要な属性に変更があっても、同一のオブジェクトだと判定する必要のあるオブジェクトもエンティティである。

posted at 14:55:25

10月11日

@mkgask

みかげあすか@mkgask

エンティティは別名を参照オブジェクトと言う。オブジェクト指向では属性でオブジェクトを表そうとすることが多いが、実際にあるべきオブジェクトは属性でなく連続性と同一性に本質を持っているものが多い。

posted at 14:50:54

2019年10月10日(木)5 tweetssource

10月10日

@mkgask

みかげあすか@mkgask

(エンティティは連続性と同一性が重視される「どれであるか」が必要なオブジェクト、で比較的わかりやすいんだけど、値オブジェクトは「何であるか」が大事で、「どれであるか」は問わないオブジェクト・・・何となくは分かるんだけど、まだ自分の理解として曖昧さが抜けてない)

posted at 15:36:22

10月10日

@mkgask

みかげあすか@mkgask

「おや、もしかしてあなた、ニンゲンですか?いやーデータでしか知らないので生きているニンゲンを見るのは初めてですよ。あ、これ音声伝わってます?言語あってますか?」ってフランクに喋ってくるC-3POかクラップトラップみたいなロボはありかもしれない

posted at 13:59:50

10月10日

@mkgask

みかげあすか@mkgask

トラックにひかれて見知らぬ天井で目が覚めてはてここは?と思いつつ外に出ると動物が死滅していて死にかけの植物と廃墟が延々と続くポストアポカリプス異世界転生(なろうにたくさんありそう)

posted at 13:20:26

2019年10月09日(水)2 tweetssource

10月9日

@mkgask

みかげあすか@mkgask

風邪引くレベルでめっっっっちゃ涼しいのが好きなので毎年秋が来るたびに僕の時代きたかと思っちゃうんだけどほんとに風邪引くのは嫌なので気をつけて頑張って暖かくしていかないといけない

posted at 17:29:32

10月9日

@mkgask

みかげあすか@mkgask

(あんまり長くなかったらエンティティと値オブジェクトとの違いを見ながらまとめたかったから先を読んでたんだけど思ったより長かった)

posted at 15:24:55

2019年10月08日(火)4 tweetssource

10月8日

@mkgask

みかげあすか@mkgask

具体的なビジネスルールが何であれ、関連に対する制約が見つかったら、モデルと実装に含めるべきだ。そうして関連を蒸留していくことはモデル駆動設計に大いに役に立つ。
それではいよいよオブジェクトに目を向けていこう。次はエンティティと値オブジェクトについてだ。

posted at 15:14:10

10月8日

@mkgask

みかげあすか@mkgask

関係性を制限することで実装がシンプルになり、本来伝達すべきであった情報が浮き彫りになる。そして、それでもなお残った双方向の関係性こそがドメインのコアであると明確にすることが出来る。ドメインのセマンティックな特徴で、アブに、とって必要であるなら、双方向であるのは必然だ。

posted at 15:06:13

10月8日

@mkgask

みかげあすか@mkgask

Unityアセットストアの3Dモデルセール、色々買わないとなーと思って昨夜見てたんだけど、セールで50%引かれててもまだお値段張るなーってなってる
あと完全にローポリか超美麗かで2極化してるから、間のいいとこ取り出来そうなのはやっぱ難しいなー

posted at 10:53:34

2019年10月07日(月)4 tweetssource

10月7日

@mkgask

みかげあすか@mkgask

身の回りにあるほぼ100%の物が、自分の知らない誰かの想像もつかない技術で作られていて、そういうもので埋め尽くされているということはもっとしっかり意識していきたい

posted at 12:52:38

2019年10月04日(金)7 tweetssource

10月4日

@mkgask

みかげあすか@mkgask

アプリケーションの複雑度をできるだけ上げないようにするために、関係性を制限することが重要だ。「関連の方向を制限」「限定子を付加し多重度を減らす」「本質的でない関連の除去」の3つが効果的だ。

posted at 15:16:22

10月4日

@mkgask

みかげあすか@mkgask

実務では多対多の双方向の関連が最も多く見られるだろう。だが多対多の双方向の関連では、実装と保守が複雑になるばかりで、関係の性質について何も伝えられない。ソフトウェアの要件が双方向を求めないなら一方向に限定するべきで、ドメインを理解していくとどちらの方向が的確なのか明らかに出来る

posted at 15:13:20

10月4日

@mkgask

みかげあすか@mkgask

ある一対多の関連の実装が、インスタンス変数のコレクションかもしれないし、アクセッサがDBから情報を広い、オブジェクト化しているかもしれない。同じモデルを反映している実装の表現はいくつもあるかもしれないが、モデル内にある関連と設計での定義と実装を一致させなければならない

posted at 15:04:33

10月4日

@mkgask

みかげあすか@mkgask

外良い天気になってきて微妙に涼しめで風強めで大変最高なので今日は仕事しないで外で寝てたいのでそれでいいですよね(よくない)

posted at 12:01:47

2019年10月03日(木)2 tweetssource

2019年10月02日(水)8 tweetssource

10月2日

@mkgask

みかげあすか@mkgask

@_starnak なんとかPayはあんまり気にいるPayがあんまりなくて・・・
あととっくに前から非接触決済できてるのにわざわざQR使うとかめんどいだけでは???って出てきた時からずっと思ってる

posted at 16:43:08

10月2日

@mkgask

みかげあすか@mkgask

kyashとGoogle Pay入れてQUICK Payでスマホで払えるようにしたんだけど、QUICK Payのグェッってカエルが潰れたみたいな音何とかならないのあれ・・・

posted at 16:17:55

10月2日

@mkgask

みかげあすか@mkgask

(エンティティと値オブジェクトについて書いてあるんだけど、曖昧で冗長な記述になってる気がするんだけど、上手く説明できるほどまだ噛み砕けてない)

posted at 15:27:29

10月2日

@mkgask

みかげあすか@mkgask

モデルと実装上の関心事の間の関係性を絶えず精査しながら、要素を3パターンに区分する。エンティティ、値オブジェクト、サービスだ。

posted at 15:24:30

10月2日

@mkgask

みかげあすか@mkgask

モデル駆動設計の基本は、モデルと実装を詳細レベルで結びつけることだ。そのために、関連を設計して無駄をなくすことから始める。オブジェクト間の関連は想像するのも描くのも簡単に見えるが、実際に実装を進めていくと想像出来ないほどの泥沼であることがたびたびある。

posted at 15:11:32

2019年10月01日(火)3 tweetssource

10月1日

@mkgask

みかげあすか@mkgask

利口なUIではアプリケーションを成長させようとするとすぐに複雑さに突き当たってしまう。また抽象化が欠けるためリファクタリングに適したコードにすることも難しい。結果、コードを一から書き直すような修正をする結末になることも多い。

posted at 15:47:17

10月1日

@mkgask

みかげあすか@mkgask

モデル駆動設計とは相容れないアンチパターンとして、「利口なUI」がある。アプリをUI毎に分離し、ロジックもUI内に含んでしまい、ビジネスルールはほんとんどなく、データの共有はDBを介して行われる。モデル駆動設計は大規模アプリに最適だが、小さいアプリなら利口なUIが適する場合もある

posted at 15:40:52

2019年09月30日(月)1 tweetsource

2019年09月29日(日)1 tweetsource

2019年09月28日(土)1 tweetsource

2019年09月27日(金)5 tweetssource

9月27日

@mkgask

みかげあすか@mkgask

モデル駆動設計は、たった一つの特別なレイヤ「ドメイン層」が存在することを強く要求する。
モデル、ビジネスロジックの設計と実装のすべてがここにあり、その他の関心事とは明確に分離されていなければならない。これはモデル設計駆動を行う上での必須事項だ。

posted at 15:22:46

9月27日

@mkgask

みかげあすか@mkgask

フレームワークが今後進化していくと、自動化が進みアプリケーションを組み立てるだけで良くなったりするだろう。開発者がコアドメインのモデリングだけに集中出来るようになれば生産性と品質は爆上がりするだろう。だがそこで、フレームワークの技術的な側面に溺れるようになってはいけない

posted at 15:17:29

9月27日

@mkgask

みかげあすか@mkgask

Visual Studio Code、Local History入れてみたんだけど、メソッドの定義先に飛ぶとLocal History側のファイルに飛んじゃうのちょっと問題ある

posted at 12:36:21

2019年09月26日(木)4 tweetssource

9月26日

@mkgask

みかげあすか@mkgask

全翼機作ってみたいけどまず航空機作ってないのでプロペラ機で遊んでみてジェットエンジンで遊んでみてからじゃないと作れない

posted at 17:24:15

9月26日

@mkgask

みかげあすか@mkgask

フレームワークの機能の中で価値あるものだけを適用し、実装とフレームワークの結合度を下げ、設計変更を容易にしておくべきだ。このミニマリズムによって、使うのが大変な複雑なフレームワークでもビジネスオブジェクトを読みやすく、表現豊かな状態に保つことが出来る。

posted at 15:19:17

9月26日

@mkgask

みかげあすか@mkgask

フレームワークは技術的な課題を解決しつつドメインに集中出来る良い手段で、通常は採用すべきだ。だがフレームワークによっては、設計に酷く制限を受けたり、実装が重苦しくなるものもある。フレームワークを採用したからといってもその機能のほとんどを使わなくても良いこともある。

posted at 15:14:19

このページの先頭へ