Boilerplate vs Magic
-
Upload
yoshitka-kawashima -
Category
Software
-
view
1.054 -
download
0
Transcript of Boilerplate vs Magic
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