Iteratorインタフェースはコレクションの要素を先頭から1つづつ、シーケンシャルにアクセスするためのインタフェースです。GoFのデザインパターンのイテレータパターンに対応しており、その特徴は コレクションの内部表現を公開せずに、要素にアクセスできる ことにあります。このため、Iteratorインタフェースをインプリメントしたクラスやその要素数、要素の保持方法などによらずに統一したインタフェースで要素にアクセスすることができます。 Iteratorインタフェースなので、そのまま生成することはできません。生成にはCollectionインタフェースのiteratorメソッドを使用します。 CollectionインタフェースはListインタフェースやSetインタフェースのスーパーインタフェースなので、これらのインタフェースでも使用することができます。 コレクションのシーケンシャルアクセス It
2011年12月6日火曜日 「ぐへへお姉ちゃんパンツ何色」から始めるクラス解説 「ぐへへお姉ちゃんパンツ何色」はこれ以上ないほどオブジェクト指向であり、しかも理想的な実装をしていることに気づきました。これを用いてオブジェクト指向を説明してみようと思います。 ある人が「ぐへへお姉ちゃんパンツ何色」と質問するのは、お姉ちゃんオブジェクトの保持するpants_color変数を取得しようとする手続きと見ることが出来ます。つまり oneechan.pants_color を取得しようとしているわけです。 ではどうすればいいのでしょうか? 考えてみましょう。直接パンツを見ればpants_colorを取得することができますね。 クラスを使わないとすればこんな書き方が考えられます。 struct oneechan{ int pants_color; }; 構造体でひな形を宣言します。
コードのリファクタリングとデザインパターン C++, Javaなどオブジェクト指向の考え方、クラスを上手に使うとコードをよみやすく整理できる場合が多くあります。 プログラムの動作を変えずにコードを整理することをリファクタリングと呼びます。 最初からコードを上手に設計するのは、熟練のプログラマでも難しいものです。少人数で開発する場合は、むしろ積極的にコードをリファクタリングし、アルゴリズムの見通しをよくするとよいでしょう。コードを修正する際にはversion管理ツールを使えるようにしておくと安心です。以前のソースコードの状態にいつでも戻せます。 ソースコードの版管理ツール Mercurialの使い方 http://www.xerial.org/wiki/lecture/2010/Mercurial デザインパターンに関しては、GoF本や結城浩さんの本などを読むと理解はできると思いますが、
Strategy パターン(ストラテジー - )は、コンピュータープログラミングの領域において、アルゴリズムを実行時に選択することができるデザインパターンである。 Strategyパターンはアルゴリズムを記述するサブルーチンへの参照をデータ構造の内部に保持する。このパターンの実現には、関数ポインタや関数オブジェクト、デリゲートのほか、オーソドックスなオブジェクト指向言語におけるポリモーフィズムと委譲、あるいはリフレクションによる動的ダック・タイピングなどが利用される。 このパターンは、関数が第一級オブジェクトである言語では暗黙のうちに使用されている。例として後述のPythonコード例を参照のこと。 Strategy パターンは、アプリケーションで使用されるアルゴリズムを動的に切り替える必要がある際に有用である。Strategy パターンはアルゴリズムのセットを定義する方法を提供し、これらを
設計・デザイン一般† 抽象化レイヤーを活用したソフトウェア設計 | ジコログ 2024.5 フロントエンドのデザインパターン 2022.10 どうしてあなたの共通化は間違っているのか:目次 #デザインパターン - Qiita 2024.3 詳細設計の書き方 #初心者 - Qiita 2024.2 オブジェクト指向の複雑性を軽減する、データ指向プログラミング入門 2023.10 概念モデリングや設計原則は進化しているのか: プログラマの思索 2023.10 概念モデリングや設計原則は以前よりも変化していないように思う。 Iframeを使いこなそう。~ EC決済のセキュリティ対策に関連して ~ - GMOインターネットグループ グループ研究開発本部 2023.10 クレカ決済にみる外部システム連携する際の堅牢な設計 - GMOインターネットグループ グループ研究開発本部 2023.10 今さら
Recent entries Apache2.4のリリース予定は来年(2011年)初め(あくまで予定) inoue 2010-12-23 Herokuの発音 inoue 2010-12-20 雑誌記事「ソフトウェア・テストPRESS Vol.9」の原稿公開 inoue 2010-12-18 IPA未踏のニュース inoue 2010-12-15 労基法とチキンゲーム inoue 2010-12-06 フロントエンドエンジニア inoue 2010-12-03 ASCII.technologies誌にMapReduceの記事を書きました inoue 2010-11-25 技術評論社パーフェクトシリーズ絶賛発売中 inoue 2010-11-24 雑誌連載「Emacsのトラノマキ」の原稿(part8)公開 inoue 2010-11-22 RESTの当惑 inoue 2010-11-22 「プ
えーとですね...。 関数型言語が普及しない理由:俺が分からないから 2011-11-12 13:04:14 via Tween 関数型言語が普及しない理由:「関数型言語が普及しない理由」という記事をみんなが書くから 2011-11-12 13:04:43 via TweetDeck ようし僕も「関数型言語が普及しない理由」という記事を書こうか。 2011-11-12 13:05:22 via Krile2 期待age RT @PG_kura: ようし僕も「関数型言語が普及しない理由」という記事を書こうか。 2011-11-12 13:07:55 via web 犬ェ... 2011-11-12 13:10:18 via Krile2 というわけで本稿を書くわけですが(ヤメテ!そんな冷たい目で僕を見ないで!)、関数型言語*1についてはよく知りませんので、決して真に受ける事無く、オブジェクト
class Adapter extends Stack { public void push(int a) { ・ ・ } public int pop() { ・ ・ } } ということはできない(※戻り値だけが異なるメソッドを多重定義できない) ので、別の方法を考えよう。 --- ところで、2つのメソッド名(名前) public void push(int) public int pop() を定義しているクラス(またはInterface)は、 何という名前のクラス(またはInterface)だろう? (言い換えると、電卓クラス側からは、 これらメソッドは何というクラス(またはInterface)に 属しているように見えるのか、ということ) adapterパターンを使うというならば、 この点は重要ではないかな? --- 仮に上記2つのメソッドが Name という名前のクラスで定義されて
総称関数の練習のために、Fizz-Buzz問題を総称関数を使って解いてみた。独自のメソッド結合まで使った、無駄に大掛かりな物になっている。 (defun strcat (&rest strings) (apply 'concatenate `(string ,@strings))) (define-method-combination strcat :identity-with-one-argument t) (defgeneric fizz-buzz-method (mod3 mod5) (:documentation "mod3が0ならFizz, mod5が0ならBuzz") (:method-combination strcat)) (defmethod fizz-buzz-method strcat ((mod3 (eql 0)) mod5) "Fizz") (defmethod
今日、オブジェクト指向について1時間ほど語りました。整理するため自分用に書いたメモを公開します。大まかな構成はメモどおりに話しましたが、メモに書いていないこともたくさん話していますし、書いていても話さなかったこともあります。 前提として自分自身のオブジェクト指向へのスタンスを書いておきます。 自分のプログラマとしてのキャリアとオブジェクト指向の隆盛の重なりを考えると客観的に見て自分はオブジェクト指向世代のプログラマなんだと思います。一方で、世間で過剰にもてはやされる技術には反発してきました。オブジェクト指向も例外ではありません。オブジェクト指向を否定はしませんが、金科玉条のように扱う人の前では、オブジェクト指向なんて技法のひとつに過ぎないと、冷たく突き放してきました。 ただここ数年、かつてに比べてオブジェクト指向の威光は下がっている気がします。関数型プログラミング支持者から、オブジェクト指
経験的にこのようにした方がよいと思った点についての記録です。 仕事で大規模(2000クラス超)かつ製品寿命がながいパッケージソフトを作っていた関係で、 ちょっとした設計の間違いが、 あとあとで大変な苦労する羽目になったりすることを経験してきました。 このような規模が大きいアプリケーションを作ることはなかなかないかもしれませんが、 なにかの参考になれば、と思います。 継承する前に委譲を検討する Singleton パターンを使うときの注意 Template Method パターンを使うときの注意 クラス間の依存に関する注意 クラスの粒度 Singleton の問題を回避できるか? 継承する前に委譲を検討する 継承はスーパークラスの仕様をよく理解しておかないと、 バグを作りこみやすいので十分注意する必要があります。 メソッドのオーバーライドをするときも、 public void foo(){
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く