編集の要約なし
12行目: 12行目:
==参考セオリー==
==参考セオリー==
* アプリケーションでどうしても必要という場合以外は新機能を追加するな
* アプリケーションでどうしても必要という場合以外は新機能を追加するな
* アプリが何ではないのかを定義することは、何であるのかを定義するのと同じように重要。あらゆるニーズに答える必要はない。むしろ互換性を維持した状態で拡張可能にしておけ
* アプリの目的が<u>何ではないのか</u>を定義することは、何であるのかを定義するのと同じくらい重要
* そもそも、あらゆるニーズに答える必要などない。むしろ互換性を維持した状態で拡張可能にしておけ
* ポリシーやルールよりも機構(システム構造)を提供せよ。特にユーザインタフェースはクライアント側に任せておけ
* ポリシーやルールよりも機構(システム構造)を提供せよ。特にユーザインタフェースはクライアント側に任せておけ
* 1つでも例を挙げて一般化したほうが、全く例を挙げずに一般化するよりもマシ
* 1つでも例を挙げて一般化したほうが、全く例を挙げずに一般化するよりもマシ

2019年6月30日 (日) 10:49時点における版

制作セオリー

  • プロトタイプは一度全て消すもの (by ゴスリング)

クラス

  • LocalDate - 100日後の日付を取得したりする
  • Calendar - 100日後の日付を取得したりする

メソッド

  • toCharArray - テキストをタイピングの演出で表示させる
  • currentTimeMillis - 特定の処理にどれくらい時間がかかるか調べる

参考セオリー

  • アプリケーションでどうしても必要という場合以外は新機能を追加するな
  • アプリの目的が何ではないのかを定義することは、何であるのかを定義するのと同じくらい重要
  • そもそも、あらゆるニーズに答える必要などない。むしろ互換性を維持した状態で拡張可能にしておけ
  • ポリシーやルールよりも機構(システム構造)を提供せよ。特にユーザインタフェースはクライアント側に任せておけ
  • 1つでも例を挙げて一般化したほうが、全く例を挙げずに一般化するよりもマシ
  • 問題が完全に把握できないときは解決策も提供しないのが最善の方法
  • 10%の作業で望みの90%の効果が得られるときには、その解法で十分
  • 複雑さは可能な限り「管理できる単純な大きさ」に分割せよ