読者です 読者をやめる 読者になる 読者になる

AWTの勉強1

awtでウィンドウはFrameというオブジェクトで表現される。

このFrameをカスタマイズすることでアプリケーションを作成する。

つまりFrameを拡張継承していく。

 public CustomeFrame extends Frame {

素のFrameはマウスで押しても何も起きない。

なぜならマウスで押したということがわからない状態だから。

ユーザーのなんらかのアクションを受け取るためには、リスナーと呼ばれる

ユーザーのアクションを受け取ることができるオブジェクトを利用する必要が有る。

普通(?)のオブジェクトは外からのアクションを受け取ることができないので、

リスナーを経由して外のアクションを受け取る。

よくadd〜listener()みたいなメソッドでリスナーの参照を得る。

public CustomeFrame extends Frame implements ActionListener {

 //ユーザーがCustomeFrameに及ぼしたなんらかのアクションがActionEventととして通知される。
 public void actionPerformed(ActionEvent ae) {
     ....
    }
} 

リスナーはセンサーで、そのセンサーを壁にくっつけてなんらかのアクションを

感知しているイメージ

センサーは色々あるし、最初からセンサーで感知したあとの動作が決まっているものもある。

まとめ①

浮動小数点演算について

http://docs.oracle.com/cd/E19957-01/806-4847/ncg_goldberg.html

 

インクリメントのタイミング

 C++は不定。次の行までにインクリメントされることが保証されている

Javaは一定

stackoverflow.com

 

a = 5;
i=++a + ++a + a++; =>
i=6 + 7 + 7; (a=8)

a = 5;
i=a++ + ++a + ++a; =>
i=5 + 7 + 8; (a=8)

例からわかるように前置インクリメンタルはその自身の値を評価するタイミングではインクリメントされず、次の値を評価する時にはインクリメントされている。

 

i=a++ + a++ + a++;なら

 

i=5 + 6 + 7; (a=8)

i=18となる。

 

Javaにおけるオブジェクト

メモリ上に確保されたフィールド値を格納する領域 + αがオブジェクト

 

配列の要素番号の型がlongではなくてintである理由

単純に言語仕様を決定した当時はそれで十分だったから。

ちなみにJavaのBinarySortは巨大な配列をソートする場合に生じるバグを含んでいたが、Java開発当初はそのような配列が作成されることがなかったため、しばらくバグを含んだままの状態であった。

Research Blog: Extra, Extra - Read All About It: Nearly All Binary Searches and Mergesorts are Broken

 

 

オブジェクトとは何ぞや 原文:What Is an Object?

Javaのオブジェクトについて整理したかったので、雑に訳してみました。

英語がそんなに得意ではないのでおかしい部分も多々あると思います。

 

docs.oracle.com

What Is an Object?

Objects are key to understanding object-oriented technology. Look around right now and you'll find many examples of real-world objects: your dog, your desk, your television set, your bicycle.


オブジェクトはオブジェクト指向技術の最重要事項だ。周りを見渡すと現実世界のオブジェクトの例にあふれているはずだ。例えばあなたの飼っている犬、机、テレビ、自転車なんかがそうだ。

Real-world objects share two characteristics: They all have state and behavior. Dogs have state (name, color, breed, hungry) and behavior (barking, fetching, wagging tail). Bicycles also have state (current gear, current pedal cadence, current speed) and behavior (changing gear, changing pedal cadence, applying brakes). Identifying the state and behavior for real-world objects is a great way to begin thinking in terms of object-oriented programming.


現実のオブジェクトには2つの性質がある。それは状態と振る舞いだ。例えば犬の状態は(名前、色、血統、はらぺこ具合)、振る舞いは(吠える、愛想をふるまう、しっぽをふる)といった感じに。自転車は〜中略〜だ。現実世界のオブジェクトの状態と振る舞いを認識することはオブジェクト指向プログラミングについて考えるのに有効な方法だ。

Take a minute right now to observe the real-world objects that are in your immediate area. For each object that you see, ask yourself two questions: "What possible states can this object be in?" and "What possible behavior can this object perform?". Make sure to write down your observations. As you do, you'll notice that real-world objects vary in complexity; your desktop lamp may have only two possible states (on and off) and two possible behaviors (turn on, turn off), but your desktop radio might have additional states (on, off, current volume, current station) and behavior (turn on, turn off, increase volume, decrease volume, seek, scan, and tune). You may also notice that some objects, in turn, will also contain other objects. These real-world observations all translate into the world of object-oriented programming.

 

ちょっと身の回りのモノをみてみよう。それについてちょっと2つほど考えて欲しい、『これはどんな状態をもつことができるだろう』『どんなこうどうをするのだろう』といった感じにだ。そして見て考えた結果を書き出してみよう。そうするときっと現実のモノがすごく複雑なことに気がつくだろう。君の机の上にある電灯はON OFFのたった二つの状態と、スイッチをONにするOFFにするの2つの操作しかないかもしれない。でも、ラジオはどうだろうか。オンオフに加えて、『音量・選択された局』、『音量を上げる/下げる・局を探す』などがそれぞれ加わるだろう。これらのことからオブジェクトには他のオブジェクト(状態・ふるまい)が加わるモノものあることが分かると思う。(オンオフに『加えて』という表現からわかると思う。)このように現実世界を観察した結果はオブジェクト指向プログラミングの世界に置き換えることができる。

 

図1

Software objects are conceptually similar to real-world objects: they too consist of state and related behavior. An object stores its state in fields (variables in some programming languages) and exposes its behavior through methods (functions in some programming languages). Methods operate on an object's internal state and serve as the primary mechanism for object-to-object communication. Hiding internal state and requiring all interaction to be performed through an object's methods is known as data encapsulation — a fundamental principle of object-oriented programming.

 

ソフトウエェアオブジェクトは現実世界のオブジェクトと考え方は似ている。両方とも状態と振る舞いからできている。1つのオブジェクトは自身の状態をフィールド(なんらかのプログラミング言語で記述された変数)として、自身の振る舞いをメソッド(なんからのプログラミング言語で記述された関数)として持つ。メソッドはオブジェクトの内部状態を操作したり、オブジェクトとオブジェクトの関係性を決める働きをする。状態を隠蔽しオブジェクトのメソッドを利用して全ての関係性を操作する技法カプセル化として知られ、オブジェクト指向言語の基本原則とされる。

 

図2

By attributing state (current speed, current pedal cadence, and current gear) and providing methods for changing that state, the object remains in control of how the outside world is allowed to use it. For example, if the bicycle only has 6 gears, a method to change gears could reject any value that is less than 1 or greater than 6.

 

状態を付与してそれを編集するメソッドを追加する時、外部から許可された使用方法で対象オブジェクトを操作可能な状態にしておかなければならない。

たとえば、6変速ギアしかない自転車は1速から6速以外のギアチェンジは受け付けないだろう。

 

Bundling code into individual software objects provides a number of benefits, including:

コードをソフトウェアオブジェクトとしてまとめると以下の効用がある。

 

 Modularity: The source code for an object can be written and maintained independently of the source code for other objects. Once created, an object can be easily passed around inside the system.

モジュラリティ:オブジェクトを表現するソースコードは一つのオブジェクトに対して一つ記述することができ、他のオブジェクトと独立したソースコードで管理される。(ソースコードとオブジェクトの関係が一対一)一度作成したソースコードはシステムの中で容易に使いまわすことができる。


Information-hiding: By interacting only with an object's methods, the details of its internal implementation remain hidden from the outside world.

情報の隠蔽:オブジェクトのメソッドによって相互に作用する時のみ、オブジェクトの内部実装の詳細は外部から隠蔽される。


Code re-use: If an object already exists (perhaps written by another software developer), you can use that object in your program. This allows specialists to implement/test/debug complex, task-specific objects, which you can then trust to run in your own code.

コードの再利用性:もしオブジェクトが既に存在するなら(もしかしたら誰かあなた以外の開発者があなたが欲しているオブジェクトを開発しているかもしれない)、そのオブジェクトをあなたのプログラムに取り込むことができる。この性質によって、熟練の技術者は、自身のコードで動かしても良いと判断したオブジェクト作成に固有のタスク群である、実装・テスト・デバッグを再利用することができる。

 

Pluggability and debugging ease: If a particular object turns out to be problematic, you can simply remove it from your application and plug in a different object as its replacement. This is analogous to fixing mechanical problems in the real world. If a bolt breaks, you replace it, not the entire machine.

プラグインを利用することでデバッグが容易に:もし特定のオブジェクトに問題がみつかったら、そのオブジェクトを別の正しく動作するオブジェクトに入れ替えることができます。これは現実世界の機械を修理することに似ています。もしボルトが壊れたらそのボルトだけを取り替えて、機械全体を取り替えることはしないでしょう。

 

 

謎ファイル #(シャープ)と~(チルダ)付きのファイル

#init.el#

init.ele~ (環境によって上付きチルダ)

 

が存在していた。

今までこの形式のファイルは『たぶんバックアップ的なファイルだろう』と

あまり気にせず無視していた。

 

今回調べてみたところ

 

#init.el# は編集中に自動バックアップされるファイル

init.ele~ は現在のファイルの一つ前のバージョンのファイル

 

になっているらしい。