約 1,326,388 件
https://w.atwiki.jp/sevenlives/pages/650.html
イミュータブル・オブジェクト 読み:いみゅーたぶるおぶじぇくと 英語:immutable object 別名: 意味: イミュータブル・オブジェクトとは値が不変のオブジェクトのこと。 Javaでは標準API?のStringクラスやラッパークラス?などがある。 同じ参照?ではクラスの値を変更できないので変更する場合は新たなオブジェクトを作らなくてはならない。もしくは新たに内部的に生成される。 値が変更できないのでスレッドセーフであり、他と共有するクラスなどに用いると便利である。 2015年12月04日 ミュータブル・オブジェクト?
https://w.atwiki.jp/overlord/pages/36.html
全オブジェクトを入手するとタワーの支配者実績が解除されるが、 スプリーの食料、ベルベットのベッド、ゴールドーの財宝、地母神の像も対象のため、堕落の排除と同時に解除不可。 完全なる堕落獲得の周で推奨。 また各地に点在するゴールドも対象。 ロイヤルホール内のものはゴールドー討伐後は入手不可のため要注意。 体力増加 マナ増加 引率ミニオン増加 ゴールド 溶鉱炉 ファイアースペル シールドスペル ドミネーションスペル ミニオンスペル その他 増加系 体力増加 1 スプリー城 城壁内。タワーゲート側。 2 エバーナイトの森 聖なる木立側。 3 ゴールデンヒルズ 醸造所の正門を背して左へ行った行き止まり。 4 ヘブンズピーク 墓場。 5 ルボリア砂漠 広い砂漠に出た後右手の廃墟。(爆弾虫の卵で爆弾虫を誘導。ワームに2匹食わせる) 6 ルボリア砂漠 村へかかる橋の手前右。 マナ増加 1 エバーナイトの森 グリーンミニオンの巣右。 2 ヘブンズピーク ブルーミニオンの巣側の沼地。 3 エバーナイトの森 ガイコツの洞窟内。 4 ゴールデンヒルズ タワーゲートからそのまま坂をくだりドワーフの村の突き当たり。 5 ヘブンズピーク 城へかかる橋より左手。壊れた城壁から。 6 ルボリア砂漠 最初のワーム遭遇場所。 引率ミニオン増加 1 序盤 ナールからの指示通り。 2 メローヒルズ ハーフリングの家内。大カボチャのある場所。 3 エバーナイトの森 骸骨イノシシの襲撃後。亡霊エルフの側。 4 メローヒルズ 沼地。要ブルーミニオン。 5 ゴールデンヒルズ 神殿建設地。地母神の像がある場所。 6 ヘブンズピーク 天国まであと少し亭内。 ▲ スペル(Lv3は堕落度によって決まる。またどこから取っても1から覚える) . ファイアースペル 1 ファイアボール 序盤 イベント 2 フレームスロー ヘブンズピーク 城壁内。地下水路を背にして右。 3 インフェルノorコンバスチョン ゴールデンヒルズ アルカニウム鉱山内。レッドビートルがわらわらいる場所。 . シールドスペル 1 シールド エバーナイトの森 最初のオベロンの根がある場所から少し戻った所。 2 ショックシールド エバーナイトの森 オベロン戦後。 インファーナルシールドorサンクチュアリ|ゴールデンヒルズ|醸造所内。裏口側。| . ドミネーションスペル 1 スロー メローヒルズ 村からハーフリングの家へ向かう途中右。※木と崩れかけの壁(円形)に囲まれて見つけ辛い 2 コンフュージョン ヘブンズピーク 地下水路出口側。 3 ビトレイヤルorサブミッション ゴールデンヒルズ 醸造所正門を背にして右側。突き当たり。 . ミニオンスペル 1 アンガー エバーナイトの森 2匹目のユニコーン側。 2 ベルセルク エバーナイトの森 地母神の神殿内。オベロンの最後の根がある場所。 3 テラリージョンorオナーリージョン ゴールデンヒルズ ドワーフの酒場内。 ▲ ゴールド・お城の設備・お宝 ゴールド 1 メローヒルズ ハーフリングの家内。 2 メローヒルズ メルビンの調理場の外右手。要レッドミニオン。 3 エバーナイトの森 グリーンミニオンの巣左の沼地。要ブルーミニオン。 4 ヘブンズピーク ブルーミニオンの巣内。 5 ヘブンズピーク ブルーミニオンの巣裏口から出た沼地。 6 ヘブンズピーク 下水道ワ-ムがいる場所に3つ。 7 ヘブンズピーク 町端の寺院。沈黙の教団から寺院を開放するイベントの場所(カーン討伐後はイベントは起こらない) 8 ゴールデンヒルズ 鉱山でのクエストのゴールドカート4つ。 9 ゴールデンヒルズ 要塞の城壁内。 10 ゴールデンヒルズ ロイヤルホール内。ゴールドー討伐後は入手不可。 11 ゴールデンヒルズ アルカニウム鉱山内。溶鉱炉のキャットウォークの奥。 溶鉱炉 1 スチールの溶鉱炉 メローヒルズ 鍛冶場跡 2 ドリウムの溶鉱炉 ヘブンズピーク 下水道(下水道2) 3 アルカニウムの溶鉱炉 ゴールデンヒルズ アルカニウム鉱山 その他 1 スプリーの食料 メローヒルズ ハーフリングの家内。 2 サキュバスの像 ヘブンズピーク 天国まであと少し亭内。サキュバスの間。 3 ベルベットのベッド ヘブンズピーク ベルベットを女主人にする。 4 ビアーケトル ゴールデンヒルズ 醸造所内。昇降機を降りたところ。 5 ゴールドーの財宝 ゴールデンヒルズ ゴールドー討伐後、財宝を選択。 6 地母神の像 ルボリア砂漠 村中央。ジュエル討伐後。 ▲
https://w.atwiki.jp/shimi/pages/81.html
今まで作成したアイテムとオブジェクトをあげるところです。
https://w.atwiki.jp/yo-kichi/pages/91.html
概要 オブジェクト指向とは? オブジェクト指向とは、世界(プログラム全体)をモノ(オブジェクト)の集合であると考え、オブジェクト単位で部品を作り オブジェクト同士の相互作用により、システムの動きを再現する考え方である。 オブジェクト指向ができた背景 オブジェクト指向ができる以前は、まずソフト全体としての機能を定義し、それを細かい機能に細分化しながら開発を行っていた。(構造化分析) しかしソフトウェアが大規模になったり複雑になると、毎回ほぼ0から開発をしなければならないオブジェクト指向以前のやり方では開発に時間 がかかり、保守性の維持も大変になってしまった。 オブジェクト指向プログラミング オブジェクト指向プログラミングとは、オブジェクト指向の考え方を利用しプログラムを作ることであり データとそれを操作する手続きを一つのオブジェクトとして捉えている。 これ以前のプログラム言語では、毎回1からソースを書いていかなければならないので、大規模なソフトウェア を作る時に時間がかかり、信頼性の確保も大変であった。 オブジェクト指向では機能毎にプログラムを分けることができるので、他のソフトウェアを作るさいにも利用することが でき、機能の再利用ができるのでソフトウェアの開発をより効率よくできるようになる。
https://w.atwiki.jp/aoe2sc/pages/85.html
オブジェクトを治療するっぽい。 詳細不明。
https://w.atwiki.jp/pmvision/pages/2680.html
《イザナギオブジェクト》 No.1792 Command <第十八弾> NODE(5)/COST(0) 効果範囲:その他 発動期間:装備 【装備/場】 (自動α): 〔あなたがプレイするキャラクターカード〕の必要ノードとコストは-3される。 (自動γ): ターン終了時、このターン中にあなたがプレイして場に出たキャラクター全てを破棄する。 「これがイザナギプレートから見つかった人工物、伊弉諾物質よ」 「んー、なんでそう言い切れるの?」 Illustration:葉庭 コメント 収録 第十八弾
https://w.atwiki.jp/robot_surf/pages/40.html
目的 構造化プログラミング オブジェクト指向 目的 このページでは、ある程度プログラミング言語に馴染んできた人を対象として、プログラミング言語にとらわれず、システムを設計する上で必要な考え方の例を提示し、効率的な設計ができるようになることを目的としています。 とりあえずC言語をかじったことがあるひとを対象にしていますが、C#だろうがC++だろうが、Ruby, Java, perl……問わずオブジェクト指向を理解できるように書いたつもりです。 構造化プログラミング オブジェクト指向の前に、オブジェクト指向がはやる前の概念を述べていきます。 CPUは機械語、すなわち0と1の列を読み込んで判断し、実行します。CPUは機械語以外は理解できませんから、CPUにできることは既存の命令を解釈・実行することだけです。さてCPUには大きく分けて、計算とジャンプができます。つまり、多くのプログラミング言語に存在するifやforという命令はないのです。 プログラミングをする際に、goto文を使うことはコンピュータにとって自然なことです。しかし、すべてがgoto文で構成されると、プログラムの量が増えるに従って人間が処理を追い切れなくなってきました。 そこで、gotoだけでなく、処理の流れを分かりやすくするためにC言語ではif文, switch文, for文, while文が存在しています。これらはgoto文を使わなくてもプログラムの流れを、「条件分岐」、「繰り返し」という意味のまとまりとして記述できます。これは構造化プログラミングの1つです。 続いて、これらの構造化手法を使って更に抽象的な処理のまとまりを関数やモジュールとしてまとめ、何らかのデータを機能を通して変換し、変換されたデータを使ってさらに処理を続ける……といった流れを構築できるようになりました。ここで言うデータとは、C言語で言う構造体などに相当し、データ→機能A→データ →機能B→データ と順次処理をしていきます。 このように、処理を意味単位に抽象化し、データをも意味単位に抽象化することで人間が見てわかりやすいようになりました。構造化プログラミングでは、制御とデータをそれぞれ抽象化することを要請しています。 オブジェクト指向 構造化プログラミングは制御とデータのそれぞれの抽象化がポイントです。実際、これを心がけることで多くのプログラムは見やすいものとなります。ところが、これを以てしても複雑な処理を考えると難しくなってきます。 オブジェクト指向では、制御とデータをひとまとまりにしたオブジェクトを考え、オブジェクトとオブジェクトとのつながりを記述するものです。オブジェクトが、他のオブジェクトにどのような影響を及ぼすかを記述していくのです。これによって、構造化プログラミングを更に抽象化できます。 つまり、オブジェクト指向では、抽象化された対象を明確にし、その抽象化された対象の相互の影響を記述していきます。 オブジェクト指向は、構造化手法とは相反するものではなく、より抽象度を高めたものです。オブジェクト指向でも、制御を記述する必要がありますし、その制御は構造化手法に基づいて書かれます。初心者はまずは構造化プログラミングからマスターしていきましょう。
https://w.atwiki.jp/mopsprogramming/pages/171.html
ヘンなタイトルですが(^^;;)。 オブジェクト指向の話は、「プログラムの全体構成を考える」という視点からしたつもりでした。大抵のオブジェクト指向解説は、そういうことを強調しますし、実際、オブジェクト指向という発想自体からして、そういう大きな話から出てきたもののようです。でも、そんな「全体構成」とかいうような大仰な話は、相当上級者になって、長ーいプログラムを書くようになってから問題になるんで、1000行程度のプログラム(慣れる程、一括把握できるコードの長さには耐性がつく)なら、どうやったっていいといえないこともないわけです。いや、まあ、汚いコードを書く癖がつくとまずいのかな。ま、でも、小さいレベルで整理されたコードを書く、ってのは、オブジェクト指向云々よりも、そのプログラミング言語の文法上の特性の方が強烈に影響を及ぼすもんなんですね。Smalltalkなんかみたいに、文法的特性そのものがオブジェクト指向ってなら、短いプログラムに関してもオブジェクト指向の話をせざるをえませんが、C言語系とかだと変数やパラメターの使い分けとか、Mopsだとスタックの使い方、LISPとかなら関数の作り方とか、そういうところのうまさが、小さいレベルでは効いてくるように思われます。 で、なにがいいたいのかというと、その大上段からの抽象的オブジェクト指向論がどーでもよく思われるような小さなプログラムでも、クラスとオブジェクトは使うことはあるだろうと。たとえ、ハイブリッド言語であっても。じゃあ、そういうとき、クラスとかオブジェクトを、どう考えて、どう扱えば、納得がいくかと、そういう話を書いてみようと思うわけです。まあ、自分個人の実感でしかないんですが。 マネージャー で、自分の中では、「マネージャー」というのが、一番しっくりくる感じがしています。つまり、「オブジェクトとはマネージャーである」と。カタカナ英語なのが、アレなんですが。 普通、マネージャーといわれて最初に連想するのは、私なんかの世代(中年)の日本人男性だと、学校の運動部で、雑用とか、記録付けとかしてくれる女の子、なわけです(ひとによるか)。ま、男子の場合も多いんですが、女子のマネージャーって、なんか憧れてたな。縁はありませんでしたが。あ、いや、どうでもいいことですね。これに対して、ここでいうマネージャーは、もっと英語のmanagerに近い意味です。会社とかでマネージャーというと、支配人とか支店長クラスの、かなり役が上の管理職です。「管理職」てのが、そもそもマネージメントの訳じゃないですかね。マネージメント、というと、管理、統治、支配、差配とかで、要は、マネージャーというのは、人とかモノとかを監視して、予定通り動くように上から操作する人、ですね。 もうひとつ、古くからのMacintoshユーザ(プログラマ)なら、マネージャーといって欠かすことができないのは、ツールボックスのAPI群ですね。だいたい、機能のまとまり毎に、ファイルマネージャーとか、ウィンドウマネージャーとか、名前がついていますね。この区分けは「モジュール」ということでしょうね。OSが提供してくれる入力/出力とか、いろいろな機能を、意味のまとまり毎に分類したものが、ナントカマネージャーということです。オブジェクトをマネージャーとみる発想からすると、このツールボックスのいうマネージャーは、マネージメントツールの集合体、という感じで、それ自体がマネージャー(つまり、動作主体っぽい感じ)という感じはありません。操作とか動作とか、要は、実行コードの意味内容で分ける、というのが、伝統的なモジュールの考え方だろうと思われます。Pascal系の、ModulaとかOberonとか、そんな感じですね(よく知らないので、いい加減)。オブジェクト指向ってのは、結局、機能の中心にデータを持ち込んだことで、そのデータに名前をつけて人格化し、そいつが何かをしてくれてる、っていう比喩的な見方が可能になったわけですね。ま、以前からのプログラマの方には、いわずもがなのことでしたか。 OSの方も、メニューとかウィンドウとかボタンとかは、OS側のオブジェクトとして提供します。昔は、これらは、データの構造体(レコード)として中身の定義も公開されていたので、アプリケーションの側で同じ型のデータ構造を作って、適当にデータを詰めた上で、これをシステムオブジェクトと見なしてくださいな、とお願いすることができました(らしい)。全部そうだったわけではないかもしれませんが、ウィンドウは少なくともそうだったようです。個人的には、そういうのの方が透明でいいなと思うんですけど、そうなると、システムのバージョンアップの都合で、データ構造を変更しようとしたとき、そういう自前でシステムオブジェクトを作っている全アプリケーションを書き直さないといけないことになるわけです。それで、今は、中身の構造を隠しておいて、その上に作用する関数を通してのみデータを操作するようになっています。これはオブジェクト指向の情報隠蔽の効用のひとつですね。まとまり(モジュール)毎の内部的変更がしやすくなる、というわけです。 そんなわけで、Mopsオブジェクトは、それ自体、Mopsの中でのオブジェクトであるのですが、システムオブジェクトをも伴う場合は、そのポインタをシステムから受け取って当のMopsオブジェクトの中に保管するようになっています。"NEW "というメソッドは、大抵、そのシステムオブジェクトを獲得するためのメソッドになっています。 こういう風に考えるとき、ウィンドウとかメニューとかファイルとか、そういう対象といわゆるオブジェクトを同一視してしまいがち、ってか、自分は初めそうだったんですが、それは、あまり正確じゃありません。というのは、例えば、ウィンドウオブジェクトは確かに一回に一個のウィンドウしか扱いませんが、いったん壊して(閉じて)もう一回作ると、じつは、同じように見えても、全く異なるウィンドウを今度は扱っているのです。そういう点からいうと、ウィンドウオブジェクトは、一回に1個のウィンドウしか扱えないけれども、ウィンドウそのものというよりも、それを通じてウィンドウを操作するための窓口、あるいは、その操作のエージェント(代理人)のようなものと考える方がいいわけです。 そうすると、オブジェクトにメッセージを送るのは、ウィンドウとかファイルに直接メッセージを送って何かやってもらうってことを意味しているんじゃなくて、そのウィンドウとかファイルのエージェントにメッセージを送って、こういう風にしてくださいな、とお願いする。そうすると、そのエージェントが、ウィンドウとかファイルとかをよしなに生成・加工・廃棄等をしてくれると、そういうことになります。そういう風に、ひとつ媒介があって、その媒介がオブジェクトと呼ばれていると考えると、けっこう全体がすんなり理解できると、私は感じています。すると、オブジェクトは、対外的には、自分の支配下にある対象(システムオブジェクトやデータそのもの、つまり、オブジェクトの内部データ)を代表する地位にあり、対内的にはメッセージに応えて、その支配下の対象を適切に保守・維持・管理・変更すべく気を配っているのであって、マネージャーという感じがうまく当てはまるように思われるのです。 前へ 次へ 目次へ トップページへ
https://w.atwiki.jp/akios/pages/61.html
4. 型と値と変数 4.1. 型と変数の種類 4.2. プリミティブ型と値 4.3. 参照型と値 4.3.1. オブジェクト オブジェクト(object)はクラスインスタンス(class instance)または配列です。 参照値(単に参照(reference))はオブジェクトへのポインターです。どのオブジェクトも参照しない特別なヌル参照もあります。 クラスインスタンスはクラスインスタンス作成式で明示的に作成されます。 配列は配列作成式で明示的に作成されます。 文字列連結演算子+を非定数式の中で使用すると新たなクラスインスタンスが暗黙的に作成され、String型の新たなオブジェクトとなります。 配列初期化式が評価された時に新たな配列オブジェクトが暗黙的に作成されます。これはクラスやインタフェースが初期化される場合や、クラスの新たなインスタンスが作成される場合、局所変数宣言文が実行される場合にあたります。 BooleanやByte、Short、Character、Integer、Long、Float、Double型の新たなオブジェクトはボックス化変換が行われる時に暗黙的に作成されます。 例4.3.1-1. オブジェクト作成 class Point { int x, y; Point() { System.out.println("default"); } Point(int x, int y) { this.x = x; this.y = y; } /* A Point instance is explicitly created at class initialization time */ static Point origin = new Point(0,0); /* A String can be implicitly created by a + operator */ public String toString() { return "(" + x + "," + y + ")"; } } class Test { public static void main(String[] args) { /* A Point is explicitly created using newInstance */ Point p = null; try { p = (Point)Class.forName("Point").newInstance(); } catch (Exception e) { System.out.println(e); } /* An array is implicitly created by an array constructor */ Point a[] = { new Point(0,0), new Point(1,1) }; /* Strings are implicitly created by + operators */ System.out.println("p " + p); System.out.println("a { " + a[0] + ", " + a[1] + " }"); /* An array is explicitly created by an array creation expression */ String sa[] = new String[2]; sa[0] = "he"; sa[1] = "llo"; System.out.println(sa[0] + sa[1]); } } このプログラムは以下を出力します。 default p (0,0) a { (0,0), (1,1) } hello オブジェクトの参照に対する演算子は以下の通りです。 フィールドアクセス、限定名またはフィールドアクセス式 メソッド呼び出し キャスト演算子(5.5.、15.16.) 文字列結合演算子+、Stringオペランドと参照を与えると参照するオブジェクトのtoStringメソッドを呼び出すことによりString表現に参照を変換し(参照もしくはtoStringの結果のいずれかがヌル参照ならば"null"が使用されます)2つの文字列を結合して新たなString型を作成します instanceof演算子 参照等価演算子==と!= 条件演算子? 同一オブジェクトに対し参照は複数存在して構いません。大抵のオブジェクトはステートを持ち、クラスのインスタンスであるオブジェクトのフィールドに保存されたり、配列オブジェクトの構成要素である変数に保存されたりします。2つの変数が同じオブジェクトへの参照を持っているなら、オブジェクトを参照する一方の変数からオブジェクトのステートを変更すると、他方の変数からその変更されたステートを観察することができます。 例4.3.1-2. プリミティブと参照の同一性 class Value { int val; } class Test { public static void main(String[] args) { int i1 = 3; int i2 = i1; i2 = 4; System.out.print("i1==" + i1); System.out.println(" but i2==" + i2); Value v1 = new Value(); v1.val = 5; Value v2 = v1; v2.val = 6; System.out.print("v1.val==" + v1.val); System.out.println(" and v2.val==" + v2.val); } } このプログラムは以下を出力します。 i1==3 but i2==4 v1.val==6 and v2.val==6 v1.valとv2.valはただ1つのnew式で作成された1つのValueオブジェクト内にある同じインスタンス変数を参照しています。一方i1とi2は異なる変数です。 個々のオブジェクトはモニターと関連付けられています。モニターはsynchronizedメソッドやsynchronized文で使用され複数のスレッドがステートへ行う平行アクセスを制御するのに用いられます。 4.3.2. Objectクラス 4.3.3. Stringクラス 4.3.4. 参照型が同じである条件 4.4. 型変数 4.5. 引数付き型 4.6. 型の抹消 4.7. 具象可能型 4.8. 未加工型 4.9. 交差型 4.10. サブタイプ化 4.11. 型の使用箇所 4.12. 変数
https://w.atwiki.jp/k_tech/pages/31.html
オブジェクトの生成 クラスとは、オブジェクトを生成するための雛型で、オブジェクトの状態を保持するフィールドとその状態に応じて何ならかの処理を行うメソッドを定義する。 public class SomeClass { public SomeClass() // new演算子により呼び出されるコンストラクタ { ・・・・ } } クラスはclassキーワードにより定義する。 classキーワードの前に、publicというアクセス修飾子を付けると、クラスの種類(アクセスのスコープ)を指定する事ができる。 ・public すべてのクラスからアクセス可能 ・無指定 同じパッケージ内からのみアクセス可能 オブジェクトを生成するには、クラス型の変数を宣言する。 続いて、new演算子を使ってオブジェクトを生成する。 new演算子はオブジェクトに必要な領域を確保し、クラスのコンストラクタを呼び出す。 クラス型の変数は配列型の変数と同様に参照型。 SomeClass obj; obj = new SomeClass(); // オブジェクトの生成 SomeClass obj = new SomeClass(); オブジェクトの生成方法を示すprogram public class ClassTest { public static void main(String[] args) { SomeClass obj, other; obj = new SomeClass(); other = new SomeClass(); if(obj.equals(other)) System.out.println("代入前-------- 同じobjectを参照"); obj = other; if(obj.equals(other)) System.out.println("代入後-------- 同じobjectを参照"); } } class SomeClass { static int counter = 0; public SomeClass() { counter++; System.out.println(counter + "回目"); } } ※二つのオブジェクトが等しいかどうかを判定するのには、必ずequal()メソッドを使う。 equal()はObjectクラスのメソッドであり、すべてのクラスはObjectを継承するため、anObject.equal(otherObject)という呼び出しが可能。 この場合、anObjectとotherObjectが等しければ、equal()メソッドはtrueを返却する。