編集の要約なし |
編集の要約なし |
||
1行目: | 1行目: | ||
* | * returnには「サブルーチンからメインへと帰る」とか「値を返す」という意味があるが、そもそも「返す」という言葉は「元々の所有者に返す」という意味なので「処理をメインルーチンに返す」「戻り値(メインルーチンから戻るときに持ってくる値)」という使い方は正しいが、「メソッドによって加工した値を返す」という使い方はおかしい。「戻る」「返す」の違いが語弊を生んでいる | ||
* サブクラスでオーバーライドしていないならサブサブクラスで「super」使ってセットできる | * サブクラスでオーバーライドしていないならサブサブクラスで「super」使ってセットできる | ||
* 「is-aの原則」より「他クラスでも使い回しそうだし、多態性で一括りにしたいから」が本質的 | * 「is-aの原則」より「他クラスでも使い回しそうだし、多態性で一括りにしたいから」が本質的 |
2019年6月10日 (月) 13:34時点における版
- returnには「サブルーチンからメインへと帰る」とか「値を返す」という意味があるが、そもそも「返す」という言葉は「元々の所有者に返す」という意味なので「処理をメインルーチンに返す」「戻り値(メインルーチンから戻るときに持ってくる値)」という使い方は正しいが、「メソッドによって加工した値を返す」という使い方はおかしい。「戻る」「返す」の違いが語弊を生んでいる
- サブクラスでオーバーライドしていないならサブサブクラスで「super」使ってセットできる
- 「is-aの原則」より「他クラスでも使い回しそうだし、多態性で一括りにしたいから」が本質的
- コンストラクタを複数用意するときは「this()」を利用してコードの重複をなくす
- 「Has-a」の関係にするためにはフィールドに「=」でしっかり割り当てているか確認する
- パッケージがドメイン名の場合は「逆になったものが文字通りの」パス配置にする必要がある
- Stuck領域の変数には、Heap領域に作成されるインスタンスのアドレスが割り当て(assing)られる
- ちなみに、インスタンスのクラス情報はメソッド領域(Static領域)に配置される
- 税率など変わらない変数は大文字で「定数」にする。(final double TAX = 1.08)
- クラスは以下のような構成にする
「静的メンバ→フィールド→コンストラクタ→ゲッタセッタ→能動メソッド→受動メソッド」 - メソッド名はJavaでは全て動詞だが、受動態と能動態があることを意識する。作法に含める?
アーカイブ
- 「x += 3」は「x」の中に「3」を混ぜるイメージ
旧) 特殊スキル『OC没頭』を早く手に入れる
- 基礎知識をしっかりと固めておく(基礎的な必勝セオリーの蓄積)★ 今ここ
- コマンドやサンプル等を大量暗記・潜在表現力の増幅(応用的な必勝セオリーの蓄積)
- 街を作りまくる・あとは組み合わせることに慣れるだけ・写経も(英語と同じ)
- 人様のためにアプリを作れる状態になる
- 何でもいいからアプリ制作(Web制作)を受注して作りまくる
- フリーランス化
Java概要(旧)
Java では、コマンドたちが(クラス設計図から生成されるインスタンスとして)文字通り擬人化されている。彼らはUnixの天才たちによって生み出された小人みたいな存在。よく使うコマンドたちはもちろん、便利なコマンドたちや彼らができる動きをしっかり把握して自分が構築するシステム内でもたくさん働いてもらえるようにする。
つまり、自分の理想を実現するために必要な「優秀な人材」はすべて、Java の中にすでに詰まっている。彼らはずっと PC の中で利用されることを待っている。問題は、自分が彼らのことをキチンと把握し使いこなせるか、ただそれだけ。彼らは喜んでタダ働きしてくれる。素晴らしいレバレッジ。
アプリ開発の指針
- アプリケーションでどうしても必要という場合以外は新機能を追加するな
- システムが何ではないのかを定義することは、何であるのかを定義するのと同じように重要。あらゆるニーズに答える必要はない。むしろ互換性を維持した状態で拡張可能にしておけ
- 1つでも例を挙げて一般化したほうが、全く例を挙げずに一般化するよりもマシ
- 問題が完全に把握できないときは解決策も提供しないのが最善の方法
- 10%の作業で望みの90%の効果が得られるときには、その解法で十分
- 複雑さは可能な限り管理できる単純な大きさに分割せよ
- ポリシーやルールよりも機構(システム構造)を提供せよ。特にユーザインタフェースはクライアント側に任せておけ