Boilerplate vs Magic

kawasima

Boilerplate● アプリケーションを書くうえで、頻繁に繰り返し出て

くるコード片● よい日本語訳がない…

↓Spring boot作ってる人

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;}

MagicMagicというか極端な例

Magicも単一責任原則(Single Responsibility Principle)

が守られているならば、悪くはない

http://プログラマが知るべき97のこと.com/エッセイ/単一責任原則

世論

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

public abstract class ActionForm implements Serializable {

public void setMultipartRequestHandler( MultipartRequestHandler multipartRequestHandler) { this.multipartRequestHandler = multipartRequestHandler; }

リクエストパラメータを保持するためのActionFormに、Multipartのハンドラもセット出来るようになっているため、ここが攻撃の起点になってしまった

Explicit is better than implicit似た話で、「"暗黙的"よりも"明示的"な方がよい」と

いう原則がある。(多分Python由来)

暗黙に頼るとこういうことに…

Mass assignmentリクエストパラメータから、モデルに無条件でコピー

すると、管理者権限のフラグなど書き換えられては

困るものまで、書き換えられてしまう問題。

JavaでもBeanUtils.populateで時々発生する。

Map Entity× 暗黙の一括コピー

SrcBean src = new SrcBean();DestBean dest = new DestBean();...Beans.copy(src, dest).excludes("foo", "bar").execute();

かと言って、includes/excludesする属性を選んでコピーするのも仕様とあっているか確認しづらい

型で明示しようMap

Map

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

および、Entityをイミュータブルに設計しよう

http://www.slideshare.net/kawasima/ss-40471672

まとめ● 単一責任原則が何よりも重要

● 守れないクラス/メソッドを作るよりはBoilerplateの方

がよい

● 暗黙的な設計に頼り過ぎると、大きな落とし穴が待っ

ているので、どこかに明示的なレイヤを設計しよう

● つまりは、Simple made easy