タグ

オブジェクト指向に関するryoasaiのブックマーク (55)

  • 「Design Patterns: Elements of Reusable Object-Oriented Software」の私的レビュー - zyake_mk2の日記

    今更ながら、有名な「Design Patterns: Elements of Reusable Object-Oriented Software」をひと通り読んだのでレビューを書いてみます。 いいところデザインパターンの位置づけについて記述されている第一章では、そもそもデザインパターンとはどういう世界観の中で、どういった位置づけで使われるものなのかを解説しており、ここが後半のデザインパターンと同じくらい重要で非常にためになった。また、自分が今まで頭の中に思い描いていた世界観とは違う使い方が主に想定されているようで、カルチャーショックを受けた(うわ、そうだったのかよ、的な)自分のOOPに対する理解が根的に足りないことを実感・・・。 簡潔で読みやすい非常に簡潔で、さらさら読める。特に後半のカタログは、全てのパターンで同じフォーマットで、簡単な概要が説明してから詳細に入っていくという書き方なの

    「Design Patterns: Elements of Reusable Object-Oriented Software」の私的レビュー - zyake_mk2の日記
  • 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 - Qiita

    あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い あきらめるにはまだ早い!ソースコードの品質向上に効果的なアプローチ 2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 この記事について この記事は新人向けの研修内容を再編集してお送りいたします。 ここで述べる内容はどのようにして現在のプログラミングスタイルが生まれてきたかを理解することで、よりよいプログラムを書くためのもので、正確なソフトウェア工学の歴史を学ぶためのものではありません。正確な歴史を把握したい場合は、原典をあたるようにしてください。 また、想定している読者は「よくあるオブジェクト指向プログラミングの学習」を既にし

    新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 - Qiita
    ryoasai
    ryoasai 2014/05/14
    いろいろな言語の例が書かれている
  • ソースコードを見よう

    ある技術について初心者向けに説明するときに、喩え(たとえ)を使うことがある。確かに、初めて聞く技術を、知っている身近なものに喩えて説明されると、なんだか分かったような気になる。ただし、こうした喩えによる説明の理解度は、説明する側、される側の両者が思っている以上に浅い。 筆者の経験では、オブジェクト指向を説明する際に用いられる喩えがそうだった。例えば、クラスとインスタンスを説明するのにしばしば用いられる、クッキー(菓子)の型とそこから作られるクッキーの喩え。クラス間の階層関係を表す継承の説明では、動物クラスの子クラスに哺乳類や鳥類のクラスがあり、哺乳類クラスの子クラスに犬やのクラスがある、といった喩えをよく聞く。ポリモーフィズム(多態性)の説明は、犬インスタンスに「鳴け」と言うと「ワン」と鳴き、クラスに「鳴け」と言うと「ニャー」と鳴きます、と言った具合だ。 オブジェクト指向についてのこう

    ソースコードを見よう
  • Javaのオブジェクト指向入門

    RSS1.0です。ページ追加・更新の情報をお知らせいたします。 このRSSはKAB-studio全体のものです。かぶろぐ。の記事も含まれるためご注意ください。 「Javaのオブジェクト指向入門」は、Javaを使用したオブジェクト指向プログラミングの解説を掲載しているコンテンツです。 クラスがよくわからない、オブジェクト指向って難しい、Javaとオブジェクト指向の関係が分からない、Javaに挫折しちゃった、という方。ぜひお読みください!

  • オブジェクトは難しくない。難しいのはクラス

    オブジェクト指向はしばしば,とっつきづらく難しい技術と言われます。その理由の一つには,対象とする分野が広く,それぞれに深みがあることが挙げられます。しかし,それ以上にこの技術を難しくしている落とし穴とも言うべき原因が二つあると筆者は考えています。それは比喩を乱用する説明の仕方の問題と,「もの中心」を意味するコンセプト自体の問題です。 事実、オブジェクト指向というのは最初は子供向けだったのだ。 このことを、現在「オブジェクトとはなんぞや」という大人たちは忘れてしまっている。 それで、オブジェクトとは何か、といえば、「自分が何が出来るのかを知っているデータ」ということになる。それ以上でもそれ以下でもない。犬は吠えることはできても話すことは出来ない。URLからホスト名やパスを取り出すことは出来ても、URLどおしを足すことは出来ない。犬が哺乳類で、URLが文字列でというのはその後でかまわない。 人

    オブジェクトは難しくない。難しいのはクラス
  • もう一度身につけたい変態で学ぶオブジェクト指向 - Happy Programming!!

    コンニチハ! 変態アドベントカレンダーです。 http://atnd.org/events/22020 ※ アドベントカレンダーとは、クリスマスまでに毎日日替わりで窓を開けていくカレンダーのこと。 それにちなんで、日替わりでblogエントリを書くのがアドベントカレンダーです。 オブジェクト指向 ってよく聞きますし、実際のところ何がすごいの?? って思ったりしてる人も多いでしょう。 抽象クラスって何よ!? インタフェースとかどうやって使う? とか そういう初心者向けアーンドもう一度学びたい人達に変態を例に説明してみましょう。 うだうだですけど、最後まで読んでいただければ幸いです。。。 まず、オブジェクト指向は何が嬉しいのか?ってところですけど、 処理を共通化し、生産性をあげる!! ということではありません。 もちろんそういう一面もありますが、これぐらいならオブジェクト指向を使わなくても十分で

    もう一度身につけたい変態で学ぶオブジェクト指向 - Happy Programming!!
  • オブジェクト指向言語が与えた開発手法への変化 - Programmer’s Log

    前記事で「しかしオブジェクト指向言語の流行によって、なんでこんな上流から下流に至るまで全部に影響が出てきたのだろう?」というわざとらしい問いをしました。 この問いに対する答えは、いつも通りの僕のトンデモ理論で恐縮ですが プログラム言語で文が書けるようになったことで、数学的完全世界だったプログラミング世界に文学という答えが一つとは限らない不完全要素が混じるようになったから だと思っています。「はぁ? なにが文学なの?」と思うかもしれません。たしかに subject.verb() という表記方法になっただけでは「文学になった」とはいえないと思います。しかし大抵のオブジェクト指向言語の場合、この表記法と同時に「抽象化」という概念を扱います。 この抽象化という概念がやっかいで「どう抽象化するのか?」「どの位抽象化するのか?」という答えのない問いを常に発し続けます。この問いには、質的に答えがな

    オブジェクト指向言語が与えた開発手法への変化 - Programmer’s Log
  • オブジェクト指向言語が流行した必然性について考える(2) - Programmer’s Log

    構造化言語ではできなくて、オブジェクト指向言語で出来るようになったこととは何か? 結論から言ってしまうと、構造化言語では 主語が書けなかった いや、そんなことはないだろう。構造体とか主語っぽいじゃない? と思われるかもしれません。(構造体何それ?という人は適当にググッて下さい。実は僕もよく知りませんw) 確かに構造体は主語にできそうですが、主語になるにはある能力が足りません。 ではある能力とは何か? ちょっとWikipediaの「主語」から少し引用してみましょう アリストテレス以来の伝統的な論理学における「述語」(katēgoroumenon) の対概念である hypokeimenon に由来し、それが中世以降のヨーロッパ伝統文法にとりいれられて成立した概念である。その後のデカルト派言語学から生成文法などに至る近現代の言語学にも受け継がれ... … … なんか、心を病みそうw これはわけわ

    オブジェクト指向言語が流行した必然性について考える(2) - Programmer’s Log
  • オブジェクト指向を理解したければRubyを使え! - 是非に及ばず

    普通の構造化プログラマーがオブジェクト指向の存在意義を理解するコツ を読んで脊髄反射してみる。 自分自身がRuby信者(笑)なので、Rubyをおすすめするわけなんだけども、中途半端にオブジェクト指向機能が入っている言語で学習したところで構造化プログラミングから抜け出せないんじゃないかなと思う。 環境が人を作るという事もあるので、まずは全てがオブジェクトであるRubyでしばらくプログラムしていれば、オブジェクトの世界で自分がどう歩くべきか自然と分かるんじゃないかな。 なにしろ、Rubyの世界にはオブジェクトしかないわけで、int型とかなくて1とか2とかの数字は実はFixnumクラスのインスタンスだったりする。だから、1.to_sだとか、1.absなんてのが実行できるし、1.methodsで1が持つメソッド一覧を取得できたりする。 なにそれ、すげー!と感じたら、あなたは分かっている、または分か

    オブジェクト指向を理解したければRubyを使え! - 是非に及ばず
  • 2011-09-25 - オブジェクト指向言語が生まれた必然性を考える(1) - プログラマ―ズログ

    さて、4月からこのBLOGを書いていますが、プログラマーズログと銘打っているのにこの記事が初めての技術系の記事ですw なぜ唐突に技術系の記事を書き始めたのかというと、ダジャレクラウドの使用技術が JAX-RS(RestEasy) Google App Engine/Java Slim3 Twitter4J jQuery という技術を使っているので、これら周辺の技術を身につけたいIT技術者も結構いるんじゃないかと考え、ダジャレクラウドの実装で得た知識をベースにした実践的な勉強会を開こうかと企画しているからです。 とりあえずは、技術者向けでなく自分でWebサービスを立ち上げたいが、フロントエンドはともかくとしてバックエンドがよくわからないWebデザイナーやイラストレータだけどWeb系の知識をつけたい人のようなグラフィック系のスキルを持った人を対象に基礎的な講座を開こうかと思っています。グラフィ

    2011-09-25 - オブジェクト指向言語が生まれた必然性を考える(1) - プログラマ―ズログ
  • 高慢と偏見(1)隣は何をする人ぞ:Press Enter■:エンジニアライフ

    ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。 高学歴で長い経験に自信を持つエンジニアは他人の話を聞かなくなる、というのは広く世に知られた真理の1つである。 K自動車ICTシステム部の三浦技術担当マネージャは、そのようなエンジニアの生き見のような人だった。初めに言葉ありき。私が聞いた三浦マネージャーの最初の言葉はこうだ。 「オブジェクト指向など、実業務では使いものにならない!」 私の名前は川嶋ミナコ。横浜市内の某所にオフィスを構えるシステム開発会社――いわゆるベンチャー企業というやつ――に勤務しているエンジニアだ。社員数は20人前後。最近は受託開発の案件はほとんどなく、大手ベンダやエンドユーザーのシステム部門に常駐して開発を行うことが多い。 K自動車への常駐もその1つだった。部品調達システムの大規模なリニューアル中で、あちこ

    高慢と偏見(1)隣は何をする人ぞ:Press Enter■:エンジニアライフ
    ryoasai
    ryoasai 2011/07/02
    staticおじさんを題材にした物語
  • Strategic Choice

    Problemこのクラスは大きすぎて、もうこれ以上大きくしたくありません。「単一責務の原則」を適用してクラスを分割しようと思います。分割の具体的な方法がわかりません。Strategy「クラスの抽出」を適用します。どんなとき?「単一責務の原則」を適用してクラスを分割しようと思います。責務を把握したので、分割の実装を行いますが、具体的な方法がわかりません。どうする?「クラスの抽出」リファクタリングを適用します。ほとんどのレガシーシステムにおいて、最初にできることは、「実装レベル」で単一責務の原則を適用することです。つまり、大きなクラスから「クラスの抽出」をして、抽出クラスに委譲することです。「インタフェースレベル」で単一責務の原則を導入するには、より多くの作業が必要です。クラスの呼び出し側を変更しなければならず、テストも必要になります。まず、実装レベルで単一責務の原則を導入しておくと、将来イン

  • 疑りぶかいあなたのためのオブジェクト指向再入門

    このページは、「オブジェクト指向再入門」とあるように、 オブジェクト指向を勉強しようとして挫折した人向けの文書です。 タイトルに「疑り深いあなたのための」とありますが、 これは決して揶揄して言っているわけではありません。 現在世間に蔓延しているオブジェクト指向の説明では、 むしろ納得しない方がまともだとさえ思えます。 「オブジェクト指向を使えば、生産性が飛躍的に上がり、 プログラムの見通しがよくなり、再利用性も高まる」と聞かされて、 「ホントかあ?」と思える人は、一度読んでみてください。 稿の対象読者は「既に他の手続き型言語を習得しているが、 オブジェクト指向が理解しがたいと感じている人」です。 言語としてはJavaを使用します。 手続き指向型の言語の例としては、C言語を使用します。 特にCに習熟している必要はないようにしたいのですが、 Cで言うところの「構造体」「ポインタ」「動的メモリ

  • Groovy + オブジェクト指向物理シミュレーション - 倭算数理研究所

    書店で Java の書籍を見ていると、『Java で物理シミュレーション』みたいなのが何冊か目に付きます。 Java も物理も大好きッ子な拙者としてはこれを見ないわけにはいかないのでパラパラと中身を見てみると、 一応 Java は使っているものの、Java の根思想である『オブジェクト指向』なんてのは見る影もないほどコードをベタ書きしてるのばかり。 これではイカン!と思い立ち、もっと『オブジェクト指向』な物理シミュレーション・フレームワークを作成することにしました。 その名も『Groops』。 Groops は「GRoovy + Object-Oriented Physics Simulation」の頭文字です。 とはいっても『オブジェクト指向物理シミュレーション』とはどんなものか?というのも少々悩ましいところ。 で、立ち読みする前にもこういったことは考えていて、だいたい次のようなものが

    Groovy + オブジェクト指向物理シミュレーション - 倭算数理研究所
  • アナリシスパターンを読もう|オブジェクトの広場

    アナリシスパターン。さまざまなところで「難解」、「難読」、「現場と無関係」とさまざまな憶測を呼んでいるようですね。でも、ツボにはまればわりと簡単に読めるし、非常に有用であることもわかってもらえると思っています。なにせ、私は、これなしで生きていけない体になってしまいました。まあ、肩の力を抜いてお話に付き合ってください。「なーんだ、簡単」と思っていただければ幸いです。 1.なにするものぞ まず、この先の話を読んでもらえるように、何の役に立つかから説明しましょう。アナリシスパターンの最大の御利益。まず、これを最大限に感じてもらうために、少し遠回りですが、要求獲得から設計初期に行われることについて少し触れます。 最初のかぎは、要求獲得にあります。要求獲得といえばユースケースですね。さて、ユースケースは、システムが達成すべき目標を「変化」の視点で表します。そこでは、「目的」として、現状のシステムを「

    アナリシスパターンを読もう|オブジェクトの広場
  • 「実はオブジェクト指向ってしっくりこなんです!」から一年 - システムエンジニア日記

    トップページ 2018年3月19日 Twitter上に以下のコメントを発見。 https://twitter.com/saegusa01/status/974877413996818433 三枝零一‏ @saegusa01staticおじさんがまだ健在で普通にブログやってて、しかも1ミリも成長していないどころか退化しているという感動。 http://ameblo.jp/kenchaz 14:17 - 2018年3月17日 この三枝さんというかたはライトノベル作家だそうですが、プログラミングに関する知識をどの程度お持ちなのでしょうか?名誉毀損に値する発言で謝罪してもらいたいものです。 私についてディスることを楽しみにしている人達がいますが、その人たちの意見が正しいというわけではないです。 2017年1月6日 ブログ始めましたよ! SE WORLDブログ 2016年11月10日 アメリカ大統領

    ryoasai
    ryoasai 2011/05/12
    ここまでstatic関数を愛せるというのはさすがですね。
  • COBOLによるオブジェクト指向プログラミング-OOCOBOL-COBOL2002

    目次 第1章 COBOLによるオブジェクト指向プログラミングの概要 1-1     COBOL2002 1-2     オブジェクト指向プログラミングの前に 1-3     クラス 1-4     ファクトリオブジェクト 1-5     インスタンスオブジェクト 1-6     メソッド 1-7     プロパティ 1-8     カプセル化 1-9     コンストラクタ 1-10 継承 1-11 オブジェクト参照と型 1-12 多態性 1-13 インタフェース 第2章 COBOLによるオブジェクト指向プログラミング実践 2-1 クラスを利用する 2-2 インスタンスオブジェクトを生成する 2-3 インスタンスオブジェクトを複数生成する 2-4 インスタンスオブジェクトをテーブルで操作する 2-5 最初のクラスを作る 2-6 ファクトリオブジェクトを作る 2-7 プロパティを使う 2-8

    ryoasai
    ryoasai 2011/05/08
    [プログラミング言語]
  • 僕と地豆とDDD - 都元ダイスケ IT-PRESS

    Domain-Driven Design: Tackling Complexity in the Heart of Software 作者: Eric Evans出版社/メーカー: Addison-Wesley Professional発売日: 2003/08/22メディア: ハードカバー購入: 4人 クリック: 113回この商品を含むブログ (89件) を見る Domain-Driven Design: Tackling Complexity in the Heart of Software というソフトウェア設計に関するがある。 この設計の考え方は、略してDDDと呼ばれたが、同時に「DDD難民」という言葉さえも生み出したらしい。ハードカバーによる560ページ、6000円を超える、洋書である。今思えば怖い物知らずだった。知らなかったとは言え、よくもまぁこのを手にとったものだ…。 この

    僕と地豆とDDD - 都元ダイスケ IT-PRESS
  • 閑話 −僕と契約して魔法少女に・・・ その2− - rikitoroの日記

    僕と契約して魔法少女に 「さて、君はソウルジェムの質、それがなんだかわかるかい?」 「ソウルジェムの質・・・魔法の、魔力の源、かな。」 「確かにソウルジェムは魔法少女に特別な力を、魔法を与えてくれる。でもね、それは質とは言えない。その質はね、"契約"なんだ。」 「契約・・・」 「僕はね、魔法少女、彼女たちの願いをかなえ、そして彼女たちは魔法少女となり魔女と戦うことを誓う。この契約が形として現れているのがソウルジェムなんだ。いわば契約書だね。重要なのはソウルジェムそのもの自体じゃない、契約なんだ。」 「そんな。」 「そしてね、魔女、これも契約として表現できる。さらに言わせてもらうと、今の僕と君の関係、これも契約としてとらえることができるんだ。」 「えっ?でも、私そんな契約した覚えなんか・・・」 「確かにね。でも、君はこうやって僕の姿を見て話をすることができるだろ。これもいわば、魔法少

    閑話 −僕と契約して魔法少女に・・・ その2− - rikitoroの日記
  • 閑話 −僕と契約して魔法少女に・・・ その1− - rikitoroの日記

    魔法少女とインキュベーターと責任関係 始まりは@ryoasai74 氏の ということで、魔法少女とインキュベータ―との契約関係、ちょっと考えてみました。 魔法少女クラスと魔女クラスと 「さて、君たちは僕たちインキュベーターとの契約によって魔法少女となり、そしてやがて魔女となりこの世界に厄災を振りまくことになるんだけれども、うん、君はこの運命をどうモデル化するつもりなんだい。」 「えぇっ?!えっと、魔法少女がいて、それから魔女もいるんだよね。こ、こうかな?」 「うん、悪くない。最初にしてはね。{incomplete}とあるのは君のように魔法少女でも魔女でもない、いわば普通の人もいるってことだね。」 「うん」 「じゃあ、オブジェクト図で書くと次のようになるね。」 「そうだけど。」 「うん、悪くない、悪くないよ。でもね、例えば美樹さやか、彼女は魔女になる前は魔法少女だったわけだし、さらにその前は

    閑話 −僕と契約して魔法少女に・・・ その1− - rikitoroの日記