(同じ利用者による、間の4版が非表示)
1行目: 1行目:
==制作セオリー==
==制作セオリー==
* プロトタイプは一度全て消すもの (by ゴスリング)
* プロトタイプは一度全て消すもの (by ゴスリング)
* ターミナル版を作ったらスマホ版に移植する?最初からスマホ版を作る?


==クラス==
==クラス==
* [[LocalDate]] - 100日後の日付を取得したりする
* [[PrintStream]] - 私はストリームデータを出力します。出力と同時に整形もできます
* [[LocalDateTime]] - 普通の日時を扱う。100日後の日付を取得したりする
* [[LocalDate]] - 普通の日付を扱う。100日後の日付を取得したりする
* [[Calendar]] - 100日後の日付を取得したりする
* [[Calendar]] - 100日後の日付を取得したりする



2021年3月17日 (水) 00:06時点における最新版

制作セオリー

  • プロトタイプは一度全て消すもの (by ゴスリング)
  • ターミナル版を作ったらスマホ版に移植する?最初からスマホ版を作る?

クラス

  • PrintStream - 私はストリームデータを出力します。出力と同時に整形もできます
  • LocalDateTime - 普通の日時を扱う。100日後の日付を取得したりする
  • LocalDate - 普通の日付を扱う。100日後の日付を取得したりする
  • Calendar - 100日後の日付を取得したりする

メソッド

  • toCharArray - テキストをタイピングの演出で表示させる
  • matches - 正規表現を利用して適切な文字列かどうか真偽する
  • format - プレースホルダ表記を利用して指定の書式で文字列を組み立てる

参考セオリー

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