編集の要約なし
編集の要約なし
2行目: 2行目:
* ポリモで一括処理したい時が来ることが予想されるので、大抵は大きな型グループとして見なす癖をつけておく?
* ポリモで一括処理したい時が来ることが予想されるので、大抵は大きな型グループとして見なす癖をつけておく?
* 作りたいアプリで使いそうなクラスをとりあえず記録しておくバランスアプローチ
* 作りたいアプリで使いそうなクラスをとりあえず記録しておくバランスアプローチ
* returnには「元々の所有者に返す」や「帰る」という意味があるので「処理をメインルーチンに返す」「サブルーチンからメインへと帰る」「戻り値(サブルーチンから帰ってときに持ってくる値)」という使い方は正しいが、「メソッドによって加工した値を返す」という使い方はおかしい。「戻る」「返す」の違いが語弊を生んでいる
* サブクラスでオーバーライドしていないならサブサブクラスで「super」使ってセットできる
* コンストラクタを複数用意するときは「this()」を利用してコードの重複をなくす
* コンストラクタを複数用意するときは「this()」を利用してコードの重複をなくす
* 「is-aの原則」より「他クラスでも使い回しそうだし、多態性で一括りにしたいから」が本質的
* 「is-aの原則」より「他クラスでも使い回しそうだし、多態性で一括りにしたいから」が本質的
13行目: 11行目:


==アーカイブ==
==アーカイブ==
* returnには「元々の所有者に返す」や「帰る」という意味があるので「処理をメインルーチンに返す」「サブルーチンからメインへと帰る」「戻り値(サブルーチンから帰ってときに持ってくる値)」という使い方は正しいが、「メソッドによって加工した値を返す」という使い方はおかしい。「戻る」「返す」の違いが語弊を生んでいる
* Javaの標準クラスは3,500くらい。まぁ英語の2,3万と比べたら少ない
* Javaの標準クラスは3,500くらい。まぁ英語の2,3万と比べたら少ない
* 「x += 3」は「x」の中に「3」を混ぜるイメージ
* 「x += 3」は「x」の中に「3」を混ぜるイメージ

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

  • クラスファイルには、「public」がついたclass代表が1人いる。「public」を付けなければ「class」はいくつ書いても良い
  • ポリモで一括処理したい時が来ることが予想されるので、大抵は大きな型グループとして見なす癖をつけておく?
  • 作りたいアプリで使いそうなクラスをとりあえず記録しておくバランスアプローチ
  • コンストラクタを複数用意するときは「this()」を利用してコードの重複をなくす
  • 「is-aの原則」より「他クラスでも使い回しそうだし、多態性で一括りにしたいから」が本質的
  • 「has-aの関係」の関係にするためにはフィールドに「=」でしっかり割り当てているか確認する
  • パッケージがドメイン名の場合は「逆になったものが文字通りの」パス配置にする必要がある
  • Stuck領域の変数には、Heap領域に作成されるインスタンスのアドレスが割り当て(assing)られる
  • ちなみに、インスタンスのクラス情報はメソッド領域(Static領域)に配置される
  • クラス:「静的メンバ→フィールド→コンストラクタ→能動メソッド→受動メソッド→ゲッタセッタ」

アーカイブ

  • returnには「元々の所有者に返す」や「帰る」という意味があるので「処理をメインルーチンに返す」「サブルーチンからメインへと帰る」「戻り値(サブルーチンから帰ってときに持ってくる値)」という使い方は正しいが、「メソッドによって加工した値を返す」という使い方はおかしい。「戻る」「返す」の違いが語弊を生んでいる
  • Javaの標準クラスは3,500くらい。まぁ英語の2,3万と比べたら少ない
  • 「x += 3」は「x」の中に「3」を混ぜるイメージ
  • 税率など変わらない変数は大文字で「定数」にする。(final double TAX = 1.08)

旧) 特殊スキル『OC没頭』を早く手に入れる

  1. 基礎知識をしっかりと固めておく(基礎的な必勝セオリーの蓄積)★ 今ここ
  2. コマンドやサンプル等を大量暗記・潜在表現力の増幅(応用的な必勝セオリーの蓄積)
  3. 街を作りまくる・あとは組み合わせることに慣れるだけ・写経も(英語と同じ)
  4. 人様のためにアプリを作れる状態になる
  5. 何でもいいからアプリ制作(Web制作)を受注して作りまくる
  6. フリーランス化

Java概要(旧)

Java では、コマンドたちが(クラス設計図から生成されるインスタンスとして)文字通り擬人化されている。彼らはUnixの天才たちによって生み出された小人みたいな存在。よく使うコマンドたちはもちろん、便利なコマンドたちや彼らができる動きをしっかり把握して自分が構築するシステム内でもたくさん働いてもらえるようにする。

つまり、自分の理想を実現するために必要な「優秀な人材」はすべて、Java の中にすでに詰まっている。彼らはずっと PC の中で利用されることを待っている。問題は、自分が彼らのことをキチンと把握し使いこなせるか、ただそれだけ。彼らは喜んでタダ働きしてくれる。素晴らしいレバレッジ。

アプリ開発の指針

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