IBM DeveloperIBM 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.
まつもと直伝 プログラミングのオキテ---目次 - まつもと直伝 プログラミングのオキテ：ITpro
第0回 あらためてRuby入門 まつもとゆきひろ氏自身による「Ruby入門」をお届けします。日経Linuxの連載開始前の特別企画（2005年4月号）として，Rubyが他のスクリプト言語やオブジェクト指向言語とどこが違うのか，なぜ便利なのかを中心に解説してもらったものです。 ● 基本と他言語との違い ● 実装とRuby誕生の秘密 第1回 プログラミングとオブジェクト指向の関係 プログラマを目指す人々の中にも，「オブジェクト指向は難しい」とか，「なかなか分からない」という印象を持つ方が多いようです。そこで，Rubyを題材にオブジェクト指向という考え方について説明していきます。 ● その1 ● その2 ● その3 第2回 抽象データと継承 オブジェクト指向プログラミングを構成する3原則のうち，前回は「ポリモーフィズム」を学びました。今回はオブジェクト指向の歴史を復習した後，残りの「データ抽象」と
第4回 オブジェクト指向の本質 | gihyo.jp
エンジニアとして良い仕事をするために必要なこと ソフトウェア業界で日米を往復しながら仕事をしていると、世界中のさまざまなエンジニアに会う。私のように「プログラミングを心底楽しんでいる」人から、「新3K」（きつい・厳しい・帰れない）を身をもって体験している人までさまざまだが、共通して言えることは、エンジニアとしての基礎がしっかりできている人とできていない人では、その生産効率に大きな開きがあり、それが結果的には、会社での労働環境や待遇に、そして結果として自分自身にとっての「仕事の充実度」に、大きな影響を与えているということである。 いつも締め切りに追われている、毎回バグで苦しんでいる、徹夜の連続で体力に限界がきているなど、「仕事がきつい」理由はいろいろとあると思うが、会社や上司の悪口を言う前に、自分自身がプロフェッショナルなエンジニアとしてこの業界で勝負をするうえで必要な最低限の基礎がで
Life is beautiful: 日本語とオブジェクト指向
先日、日経BPの出版局の方と話をする機会があったのだが、私がマイクロソフトでウィンドウズ９５の開発に関わったことに触れた際、「ユーザーインターフェイスの設計において、日本人であることで何か役に立ったことはありますか？」と聞かれた。日本人であることがプラスになったとは思わないが、ふと思い出したことがある。当時、「日本語はオブジェクト指向な言語だな」と思ったことである。 その当時（９０年代初頭）、アップルの方が使い勝手に関しては一歩も二歩もマイクロソフトより進んでおり、そのためには、もともとゼロックスが提案しアップルが商品化した、「オブジェクト指向ユーザーインターフェイス」の考え方を、より推し進めるしかないという戦略で、ウィンドウズ９５のユーザーインターフェイス（当時は Object-Oriented Shell と呼ばれていた）の開発をしていた。 「オブジェクト指向ユーザーインターフェイス」
羽生田栄一の「オブジェクト論」---目次 | 日経 xTECH（クロステック）
オブジェクト指向の考え方を適用する最大のメリットは概念操作という高水準での記述を可能にする点にあります。概念を抽出するということはシステムや業務に対する考え方も規定します。いかにシステムを認識すればよいか。コトバへの着目が重要です。 また，オブジェクトの識別とその関係整理は，オブジェクト指向に基づくシステム開発の第一歩であり，最も難しいステップです。現場のエキスパートが使う言葉に着目して候補を切り出し，適切かどうかを検証します。修飾語の関係や適用する比喩などから日常的で曖昧な認識の枠組みを整合的な体系へ変換し整理しなければなりません。 ・羽生田栄一の「オブジェクト論」【前編】（上） ・羽生田栄一の「オブジェクト論」【前編】（中） ・羽生田栄一の「オブジェクト論」【前編】（下） ・羽生田栄一の「オブジェクト論」【後編】（上） ・羽生田栄一の「オブジェクト論」【後編】（中） ・羽生田栄一の「オ
デザインパターンとOpen-Closed Principle
1999/06/11 石井 勝 概要 この記事では，まずOpen-Closed Principleの意味と解説を行い，その後デザインパターンをOpen-Closed Principleの観点から眺めます．デザインパターンのうちの多くはOpen-Closed Principleを満たすために用意されたものとみなすことができます．Open-Closed Principleを理解し，数あるデザインパターンの中から，どういう場合にどのパターンを使うのが一番効果的なのかを考えます． 目次 はじめに ソフトウェアと連続性 仮想仕事の原理 修正と追加 Open-Closed Principle Open-Closed Principleの例 Open-Closed Principleの反例 オブジェクト指向とOpen-Closed Principle デザインパターンとOpen-
無題ドキュメント
オブジェクト指向再考、あるいは初心者を卒業した技術者のためのオブジェクト指向再入門 今回は再入門らしく、B. Meyerの『オブジェクト指向入門』を中心として、基本中の基本のその要とでも言える部分をまとめてみたいと思います． メイヤーは、ソフトウェアの品質要素として 正確さ Correctness 頑丈さ Robustness 拡張性 Extendibility 再利用性 Reusability 互換性 Compatibility をあげています． 正確さと頑丈さは言うまでもないでしょう．オブジェクト指向の最大のメリットを考えるなら、それは、上記の拡張性と再利用性によってもたらされるといえます．それに付け足して互換性というところでしょうか． 拡張性とは、「ソフトウェアが仕様の変更に容易に対応できる能力」であり、特に、今日的なAgile開発プロセスを考えるときに重要です.「Emb
perl - Class vs. Closure : 404 Blog Not Found
2008年07月13日03:30 カテゴリLightweight Languages perl - Class vs. Closure PERL HACKS(日本語版) [英語版] うーん、さすがにそれはいいすぎでしょうか。 クロージャの概念をクラスとの対比でわかりやすく説明する。 - サンプルコードによる Perl 入門 ここで気づいてほしいことは、クラスとクロージャは、実は同じものだということです。たしかにオブジェクトの定義から行くと、 404 Blog Not Found:オブジェクトは難しくない。難しいのはクラス それで、オブジェクトとは何か、といえば、「自分が何が出来るのか[コード]を知っているデータ」ということになる。 であり、クロージャー(closure)は「自分が何を持っているか[データ]を知っているコード」なので、等価ではある。実際、 package Class; sub
perl - no accessor; # だって遅いんだもん : 404 Blog Not Found
2008年07月08日15:30 カテゴリLightweight Languages perl - no accessor; # だって遅いんだもん まずはDCONWAY先生のお言葉から。 Perl Best Practices Damian Conway [邦訳:Perlベストプラクティス] Always use fully encapsulated objects. オブジェクトは常にカプセル化して用いよ これはperlの常識というより、OOの常識であるのだけど、これがperlの実装と重なることにより、perlにおいては他の言語よりも作法を破りたくなるインセンティヴが大きいのは否めない。 カプセル化のコストが、あまりに大きいのだ。 以下は、ハッシュ、ハッシュリファレンス、そしてハッシュリファレンスによるオブジェクトの性能をベンチマークしたものだ。最初が初期化、次が accessor と
結論：結局、Javaはクロージャを使えるの？ - lethevert is a programmer
【追記 2008/7/2】とても昔のClosureについて書いた記事が注目を集めてしまったみたいですが、ぜひ、もっと後で書いた次の記事とその関連スレッドの方も確認してみてください。このときよりも、もう少し事情が分かってから書いたものなので、より正確に状況を理解できると思います。それに、私自身、この言葉にはまだ混乱しています・・・ http://d.hatena.ne.jp/lethevert/20070524/p2 - という問いに対して、そろそろ私の結論を整理しておきます。 これは、将来の自分に対する参照の便のための整理です。 前提知識 前提知識として、こちらの内容を読んで理解しておきます。 Closure (computer programming) - Wikipedia [id:lethevert:20060119:p1] [id:lethevert:20060121:p2] また
いまさらきけない「ドメインモデル」と「トランザクションスクリプト」 - ひがやすを技術ブログ
このネタは、私自身も何度も書いてきたけど、結局意味のある結論になったためしがありませんが、再度考え直してみたいと思います。 「ドメインモデル」と「トランザクションスクリプト」をすごく簡単に説明すると、トランザクションスクリプトとは「アクションより起動される一連の手続き」、ドメインモデルとは「ドメイン内の名詞によって体系化されたモデル」です。 トランザクションスクリプト派は、「トランザクションスクリプトの方が書くのが簡単だし、業務アプリケーションにオブジェクト指向は、ほとんど必要ない」といいます。 それに対し、ドメインモデル派は、「ドメインモデルはオブジェクト指向を生かすことができるのでメンテナンス性が良い」と主張します。 ずっと平行線のままですね。 私は一番最初に「ユースケースと一対一にサービスクラスを設け、ビジネスロジックはサービスクラスに記述する」という主張をしてました。 記念すべき(
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
�$B%=%U%H9)3X$N%K%e!<%9%0%k!<%W�(B