タグ

関連タグで絞り込む (277)

タグの絞り込みを解除

oopに関するkiyo_hikoのブックマーク (216)

  • ステートマシン図を用いたプログラムの自動生成支援 | CiNii Research

    kiyo_hiko
    kiyo_hiko 2011/12/08
    そのうち読む
  • Iterator Interface

    Iteratorインタフェースはコレクションの要素を先頭から1つづつ、シーケンシャルにアクセスするためのインタフェースです。GoFのデザインパターンのイテレータパターンに対応しており、その特徴は コレクションの内部表現を公開せずに、要素にアクセスできる ことにあります。このため、Iteratorインタフェースをインプリメントしたクラスやその要素数、要素の保持方法などによらずに統一したインタフェースで要素にアクセスすることができます。 Iteratorインタフェースなので、そのまま生成することはできません。生成にはCollectionインタフェースのiteratorメソッドを使用します。 CollectionインタフェースはListインタフェースやSetインタフェースのスーパーインタフェースなので、これらのインタフェースでも使用することができます。 コレクションのシーケンシャルアクセス It

    kiyo_hiko
    kiyo_hiko 2011/12/06
    Perlでシーケンシャルアクセスさせるためのクラスを発明するので参考に
  • 小人閑居して: 「ぐへへお姉ちゃんパンツ何色」から始めるクラス解説

    2011年12月6日火曜日 「ぐへへお姉ちゃんパンツ何色」から始めるクラス解説 「ぐへへお姉ちゃんパンツ何色」はこれ以上ないほどオブジェクト指向であり、しかも理想的な実装をしていることに気づきました。これを用いてオブジェクト指向を説明してみようと思います。 ある人が「ぐへへお姉ちゃんパンツ何色」と質問するのは、お姉ちゃんオブジェクトの保持するpants_color変数を取得しようとする手続きと見ることが出来ます。つまり oneechan.pants_color を取得しようとしているわけです。 ではどうすればいいのでしょうか? 考えてみましょう。直接パンツを見ればpants_colorを取得することができますね。 クラスを使わないとすればこんな書き方が考えられます。 struct oneechan{      int pants_color; }; 構造体でひな形を宣言します。

    kiyo_hiko
    kiyo_hiko 2011/12/06
    姉、ちゃんと(メソッドでアクセス)しようよっ!、っていうお話
  • IBM Developer

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    IBM Developer
  • 2011年度生物情報科学演習 リファクタリングとデザインパターン

    コードのリファクタリングとデザインパターン C++, Javaなどオブジェクト指向の考え方、クラスを上手に使うとコードをよみやすく整理できる場合が多くあります。 プログラムの動作を変えずにコードを整理することをリファクタリングと呼びます。 最初からコードを上手に設計するのは、熟練のプログラマでも難しいものです。少人数で開発する場合は、むしろ積極的にコードをリファクタリングし、アルゴリズムの見通しをよくするとよいでしょう。コードを修正する際にはversion管理ツールを使えるようにしておくと安心です。以前のソースコードの状態にいつでも戻せます。 ソースコードの版管理ツール Mercurialの使い方 http://www.xerial.org/wiki/lecture/2010/Mercurial デザインパターンに関しては、GoFや結城浩さんのなどを読むと理解はできると思いますが、

  • はてなブログ | 無料ブログを作成しよう

    異国の友人たちへ、また会う日まで 2024年ゴールデンウィーク。5年ぶりにウズベキスタン旅行に行ってきたので、旅の模様をデイリーポータルZに綴りました。ウズベク旅行記はこれが3目。 dailyportalz.jp dailyportalz.jp dailyportalz.jp (↑New!) おかげさまでどの記事も多くの方にお読みいただき、…

    はてなブログ | 無料ブログを作成しよう
    kiyo_hiko
    kiyo_hiko 2011/11/30
    クソワロタwwww
  • Strategy パターン - Wikipedia

    Strategy パターン(ストラテジー - )は、コンピュータープログラミングの領域において、アルゴリズムを実行時に選択することができるデザインパターンである。 Strategyパターンはアルゴリズムを記述するサブルーチンへの参照をデータ構造の内部に保持する。このパターンの実現には、関数ポインタや関数オブジェクト、デリゲートのほか、オーソドックスなオブジェクト指向言語におけるポリモーフィズムと委譲、あるいはリフレクションによる動的ダック・タイピングなどが利用される。 このパターンは、関数が第一級オブジェクトである言語では暗黙のうちに使用されている。例として後述のPythonコード例を参照のこと。 Strategy パターンは、アプリケーションで使用されるアルゴリズムを動的に切り替える必要がある際に有用である。Strategy パターンはアルゴリズムのセットを定義する方法を提供し、これらを

    Strategy パターン - Wikipedia
    kiyo_hiko
    kiyo_hiko 2011/11/29
    「このパターンは、関数が第一級オブジェクトである言語では暗黙のうちに使用されている。例として Python コード を参照」・・・おお、見落としてた。コンストラクターに関数オブジェクトをバンバン渡してる感じ?
  • 詳細設計 - 技術情報Wiki

    設計・デザイン一般† 抽象化レイヤーを活用したソフトウェア設計 | ジコログ 2024.5 フロントエンドのデザインパターン 2022.10 どうしてあなたの共通化は間違っているのか:目次 #デザインパターン - Qiita 2024.3 詳細設計の書き方 #初心者 - Qiita 2024.2 オブジェクト指向の複雑性を軽減する、データ指向プログラミング入門 2023.10 概念モデリングや設計原則は進化しているのか: プログラマの思索 2023.10 概念モデリングや設計原則は以前よりも変化していないように思う。 Iframeを使いこなそう。~ EC決済のセキュリティ対策に関連して ~ - GMOインターネットグループ グループ研究開発2023.10 クレカ決済にみる外部システム連携する際の堅牢な設計 - GMOインターネットグループ グループ研究開発2023.10 今さら

    kiyo_hiko
    kiyo_hiko 2011/11/29
    会社で見るオブジェクト設計が常々クソだと思ってたが、ここのヒントで何故ダメかが1つわかった。感謝 / 「フローチャートがダメな3つの理由」に付け足したいのは、レイヤーや、分割統治する方針を表現できないこと
  • アラン・ケイのオブジェクト指向(Smalltalk)を誤解していたようです — ありえるえりあ

    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 「プ

    kiyo_hiko
    kiyo_hiko 2011/11/27
    「現在主流のC++的オブジェクト指向は、分割統治の上に立つ技法です。~この目的を達成できないのなら、データと手続きの一体化にこだわる必要はありません」
  • Clojure - Multimethods and Hierarchies

    kiyo_hiko
    kiyo_hiko 2011/11/21
    Clojureでマルチメソッドらしい。そのうち読む
  • Rolling with Ruby on Rails

    kiyo_hiko
    kiyo_hiko 2011/11/21
    Pythonでマルチメソッドらしい。後で読む
  • 関数型言語が普及しない理由 - 偏見プログラマの語り!

    えーとですね...。 関数型言語が普及しない理由:俺が分からないから 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についてはよく知りませんので、決して真に受ける事無く、オブジェクト

    kiyo_hiko
    kiyo_hiko 2011/11/14
    関数型プログラミングは難しすぎてよくわからない。とにかく何でも式であること、高階関数便利だよねとか、小さい仕事を小さく書ける、ぐらいの印象しかない。副作用(世界の変更)はOO言語でも恐れるべきだとは思う。
  • 4.4. すべてはオブジェクトの中にある - Common Lisp クックブック

    kiyo_hiko
    kiyo_hiko 2011/11/13
    「メソッドは必ずしもクラスに所属する必要がない」
  • 戻り値の異なるメソッドの多重定義はできないのですか?

    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 という名前のクラスで定義されて

    戻り値の異なるメソッドの多重定義はできないのですか?
    kiyo_hiko
    kiyo_hiko 2011/11/13
    多重定義というかオーバーライド風味の話。無理やりやるならメンバーに持っておいて委譲だろうか。少なくとも継承でできたらI/Fや抽象クラスはその意味を失っちゃうな http://sundome.cocolog-nifty.com/blog/2009/03/post-b181.html
  • Common LispでFizz-Buzz問題・総称関数を使って | へびにっき

    総称関数の練習のために、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

    kiyo_hiko
    kiyo_hiko 2011/11/11
    「総称関数の使い勝手はHaskellやErlangのパターンマッチと似たところがあるが、マッチするメソッドが一度に全部手に入り、それらを結合できるところが決定的に違う。」…なるほど
  • 総称関数

    kiyo_hiko
    kiyo_hiko 2011/11/11
    CLOSはまだあまりわかってないのであとで精読しよう
  • オブジェクト指向について語った時に使ったメモ

    今日、オブジェクト指向について1時間ほど語りました。整理するため自分用に書いたメモを公開します。大まかな構成はメモどおりに話しましたが、メモに書いていないこともたくさん話していますし、書いていても話さなかったこともあります。 前提として自分自身のオブジェクト指向へのスタンスを書いておきます。 自分のプログラマとしてのキャリアとオブジェクト指向の隆盛の重なりを考えると客観的に見て自分はオブジェクト指向世代のプログラマなんだと思います。一方で、世間で過剰にもてはやされる技術には反発してきました。オブジェクト指向も例外ではありません。オブジェクト指向を否定はしませんが、金科玉条のように扱う人の前では、オブジェクト指向なんて技法のひとつに過ぎないと、冷たく突き放してきました。 ただここ数年、かつてに比べてオブジェクト指向の威光は下がっている気がします。関数型プログラミング支持者から、オブジェクト指

    kiyo_hiko
    kiyo_hiko 2011/11/09
    「早すぎる不変の作り込みをすると、ラッパーコードや無駄なフラグを持ち込む羽目になります。インターフェースを使った固いコードで美しいのに、現実的には足かせにしかならないコードができあがります」
  • List Of Pornstars - Porn Models - SloppyKnees

    SloppyKnees.com is the best and most amazing website for free porn sex videos. With daily updates, you can always find the newest and hottest movies for online watching!

    kiyo_hiko
    kiyo_hiko 2011/10/31
    Perlでflyweight
  • Amazon.co.jp: C言語によるオブジェクト指向プログラミング入門: 坂井弘亮: 本

    Amazon.co.jp: C言語によるオブジェクト指向プログラミング入門: 坂井弘亮: 本
    kiyo_hiko
    kiyo_hiko 2011/10/19
    CでクラスベースのOOPを再発明するというコンセプトだろうかな?買ってみたので読んでみる。再発明の本だったら「何故オブジェクト指向か?」というのが今よりうまく説明できるようになりそうな気がする。
  • クラス設計に関するメモ

    経験的にこのようにした方がよいと思った点についての記録です。 仕事で大規模(2000クラス超)かつ製品寿命がながいパッケージソフトを作っていた関係で、 ちょっとした設計の間違いが、 あとあとで大変な苦労する羽目になったりすることを経験してきました。 このような規模が大きいアプリケーションを作ることはなかなかないかもしれませんが、 なにかの参考になれば、と思います。 継承する前に委譲を検討する Singleton パターンを使うときの注意 Template Method パターンを使うときの注意 クラス間の依存に関する注意 クラスの粒度 Singleton の問題を回避できるか? 継承する前に委譲を検討する 継承はスーパークラスの仕様をよく理解しておかないと、 バグを作りこみやすいので十分注意する必要があります。 メソッドのオーバーライドをするときも、 public void foo(){

    kiyo_hiko
    kiyo_hiko 2011/10/19
    なるほど:Singletonは「Java のコア API のソースを検索してみれば、 ほとんど使われていない」「継承による機能追加ができなくなります。 つまり、その唯一のクラスに次々に新しいメソッドを追加していくしかない」