BoilerplateとMagic論争をStruts1を交えて考えてみました。

1. Boilerplate vs Magic
kawasima

2. Boilerplate
●
アプリケーションを書くうえで、頻繁に繰り返し出て
くるコード片
●
よい日本語訳がない…

3. ↓Spring boot作ってる人

4. http://www.davidtanzer.net/boilerplate_vs_magic
public User getUser(final long userId) {
transactionManager.newTransaction();
User user = userRepository.get(userId);
user.setLastAccessed(System.currentTimeMillis());
userRepository.save(user);
transactionManager.commitTransaction();
return user;
}
Magic
Magicというか極端な例

5. Magicも単一責任原則(Single Responsibility Principle)
が守られているならば、悪くはない
http://プログラマが知るべき97のこと.com/エッセイ/単一責任原則
世論

6. 単一責任原則が守られていないことによって
引き起こされるCriticalな問題

7. public abstract class ActionForm implements Serializable {
public void setMultipartRequestHandler(
MultipartRequestHandler multipartRequestHandler) {
this.multipartRequestHandler = multipartRequestHandler;
}
リクエストパラメータを保持するためのActionFormに、Multipartのハンドラもセット
出来るようになっているため、ここが攻撃の起点になってしまった

8. Explicit is better than implicit
似た話で、「"暗黙的"よりも"明示的"な方がよい」と
いう原則がある。(多分Python由来)
暗黙に頼るとこういうことに…

9. Mass assignment
リクエストパラメータから、モデルに無条件でコピー
すると、管理者権限のフラグなど書き換えられては
困るものまで、書き換えられてしまう問題。
JavaでもBeanUtils.populateで時々発生する。

10. Map Entity
× 暗黙の一括コピー
SrcBean src = new SrcBean();
DestBean dest = new DestBean();
...
Beans.copy(src, dest).excludes("foo", "bar").execute();
かと言って、includes/excludesする属性を選んでコピーするのも
仕様とあっているか確認しづらい

11. 型で明示しよう
Map
Map
Form Entity
そのビジネスロジックで使用するものだけを
受け付けるためにForm的なクラスが存在する。
だからこそ、複数のタイプのリクエストでFormクラスを共用するのは危険

12. および、Entityをイミュータブルに設計しよう
http://www.slideshare.net/kawasima/ss-40471672

13. まとめ
●
単一責任原則が何よりも重要
●
守れないクラス/メソッドを作るよりはBoilerplateの方
がよい
●
暗黙的な設計に頼り過ぎると、大きな落とし穴が待っ
ているので、どこかに明示的なレイヤを設計しよう
●
つまりは、Simple made easy