{"action":"opened","issue":{"url":"https://api.github.com/repos/kmycode/jstorybook/issues/32","labels_url":"https://api.github.com/repos/kmycode/jstorybook/issues/32/labels{/name}","comments_url":"https://api.github.com/repos/kmycode/jstorybook/issues/32/comments","events_url":"https://api.github.com/repos/kmycode/jstorybook/issues/32/events","html_url":"https://github.com/kmycode/jstorybook/issues/32","id":103271676,"number":32,"title":"コードは最低限ビューとモデルを分離すべき","user":{"login":"kmycode","id":13672783,"avatar_url":"https://avatars.githubusercontent.com/u/13672783?v=3","gravatar_id":"","url":"https://api.github.com/users/kmycode","html_url":"https://github.com/kmycode","followers_url":"https://api.github.com/users/kmycode/followers","following_url":"https://api.github.com/users/kmycode/following{/other_user}","gists_url":"https://api.github.com/users/kmycode/gists{/gist_id}","starred_url":"https://api.github.com/users/kmycode/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kmycode/subscriptions","organizations_url":"https://api.github.com/users/kmycode/orgs","repos_url":"https://api.github.com/users/kmycode/repos","events_url":"https://api.github.com/users/kmycode/events{/privacy}","received_events_url":"https://api.github.com/users/kmycode/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2015-08-26T13:35:41Z","updated_at":"2015-08-26T13:35:41Z","closed_at":null,"body":"oStorybookをフォークした当初は、MVVMモデルに移行しようと思っていた（FontUtilからFontManagerへ移行したはその名残）。\r\nしかし、Storybookは以下の問題をはらんでいる。\r\n\r\n* ユーティリティクラスが非常に多く、OOPとして見苦しい\r\n* オーバーライドがあまりない。あるにはあるが、あまり効率的ではないと思う\r\n* デザインモデルがわからない。最初MVCかと思ったが、どうもコードの大部分がVに集中しているように思える。Vは画面表示を担うところであって、ビジネスロジックを書く場所ではない。MVCのどれにもあてはまらないクラスからもできるだけビジネスロジックを絞り、ロジックを分離しないと後述のJavaFXへの移行が困難になる\r\n* ドメインモデルが典型的な貧血症。インスタンスのメソッドにできそうなメソッドまでがユーティリティクラスのstaticメソッドにされている有り様。org.hibernateを意識したと思うが、これはさすがにないと思う。自分のモデルで完結でき、他の自作クラスと密結合を持たない処理は、極力そのモデルの中に書くべき\r\n* これもorg.hibernateを意識したものと思うが、リフレクションを多用している。論ずるまでもないが、リフレクションはスタックトレースを難解にするため、いくらコードがシンプルになろうが、アプリ内の処理でメインに使うものではないと考えている。OOPの特性を最大限活用し、リフレクションを極力使わない解決法を模索すべき\r\n* swingはこれからjavaにとってレガシーコストになるだろう。早期のJavaFXへの移行の検討が必要だ\r\n* 同じコードを複数箇所に書く、せっかく翻訳ファイルがあるのに一部の文字列リテラルをコードに直接書くなど、この規模のソフトとしてコードの保守性が低いように感じる。保守性は品質にかかわる\r\n\r\nこのままでは、jStorybookの持続的な発展は難しいだろう。そこで、以下の提案をする。\r\n\r\n* jStorybookのソースコードは現在storybookパッケージ内に集約されている\r\n* これに、もう１つパッケージを作る。名前は、jstorybookとする\r\n* 旧設計（storybook）から、クラスや機能を１つずつ削って、新設計（jstorybook）にうつす\r\n\r\n下手すれば１年か２年はかかりかねない大掛かりな作業になるが、仮に成功すればコードの保守性向上が期待できる。しかし、失敗すればコードの可読性が大きく下がるだろう。\r\nよって、まずはこれを実行するか検討すべきだ。それと並行して、新設計の構想を組み立てなければいけない。\r\n\r\n新設計について、MVVMは検討の余地もあるが、疎結合をサポートしていないJavaFXでMVVMを無理に使うかは判断が分かれるし、MVCとの比較も慎重に検討する必要がある。"}}