クラス設計の原則 — みんなのウェディングエンジニアリングブログ
みんなのウェディングの高井です。 クラスベースのオブジェクト指向プログラミング言語を利用している人であれば、クラスとは、ありふれていて普段から利用するものです。にもかかわらず、良いクラスをつくるというのは、なかなかに難しいことです。 先日、みんなのウェディングでアルバイトをしてくれている学生さんのコードレビューをしていたときにも、それを強く感じました。 実践的プラグマティックには「ソフトウェアの規模や文脈にあわせて、適切に抽象化していただきたい」という以上のことを言っても仕方がないところなのですが、それだけでは経験の浅いプログラマーにとって、まったく分からないという話になってしまいます。 というわけで、今回はクラス設計の原則についてのお話しです。 Bertrand Meyerのクラス設計の原則 Bertrand Meyerは『オブジェクト指向入門 第2版』の中で、クラス設計について章をひと
オブジェクト指向の法則集 - Qiita
この記事は、故石井勝さんが1999年に書いた記事を Qiita に転載するものです。オブラブ(objectclub.jp)にて記事をホスティングしていましたが、現代でも十分に読める内容なので、たくさんの方に読んでもらいたいと思い、若干の編集（リンクとコンテキスト追加）を平鍋が行い、転載します。今でも、読みやすく、カジュアルな語り口のよい記事です。 オブジェクト指向の法則集（転載元：http://objectclub.jp/community/memorial/homepage3.nifty.com/masarl/article/oo-principles.html ） なお、この記事の他にも石井さんのオブジェクト指向やRubyに関する多くの記事をオブラブの「まさーるのページ」で読むことができます。では、以下に石井勝さん（旧メールアドレス masarl@nifty.com）の記事を転載します
社内勉強会でオブジェクト指向についてLTしました | Nekoya press
毎週定例の社内勉強会でオブジェクト指向の基礎についてLTしました。資料はやや加筆しています。 昨今、オブジェクト指向というとMVCとかデザインパターンみたいな発展的なトピックが目立つような気がしていて、もっと簡単に考えればいいのになーという思いからこういう話をしました。 凝集度を高める設計指針を出来るだけ平易な言葉で語ろうというのがコンセプトでした。 サンプルがいろいろ話をはしょりすぎで、改めて見るとちょっと違和感ありますね… 開発のバイトで来てくれてる学生の子たちに、こういう概念的な話を聞いてもらう機会って積極的に作らないとなかなかないので、そういう場を作っていくのもおっさんの役割なのかなーみたいなことを思ってます。
連載: IBM Watson Workspace #鬼わか アプリケーション開発: 第 7 回: IBM Watson Workspace で AI を利用したアプリ連携の実現 #鬼わか 解説（前編）
Moose vs Mouse and OOP in Perl | Pete Keen
After using Calorific for a month two things have become very clear. First, I need to eat less. Holy crap do I need to eat less. I went on to SparkPeople just to get an idea of what I should be eating, and it told me between 2300 and 2680 kcal. I haven't implemented averaging yet, but a little grep/awk magic tells me I'm averaging 2793 kcal per day. This is too much. So. One thing to work on. Seco
BeInteractive! [ArtisticCoding: オブジェクト指向のそもそも]
先月や先々月は鼻から DisplayObject がパーティクルの如く吹き出そうなぐらいバリバリ実装をしていた反動か、今月は設計やデザインに食指が動く今日この頃です。というか、現実問題として実装前フェーズの案件が沢山あるってだけなんですけどね。 そんで色々考える訳なのですが、ふと、「オブジェクト指向そのもの」についてきちんと勉強したことが無い気がしてきました。これはいけません。なんかバイブル的なものってあるんでしょうか。 で、インターネッツを漂流していたらオージス総研さんの「オブジェクトの広場」にいい感じのまとめをいくつか発見しました。 技術書籍紹介 [オブジェクト指向を学ぶための入門書ガイド] これだけは読んでおきたい！オブジェクト指向関係の文献ガイド オブジェクト本分野別ランキング [デザインパターン] オブジェクトの広場編集員が贈るオススメ書籍 - 今、この本がアツい！ - で、気に
デザインパターン - 自分用メモとか
参考サイト † Code++ http://ameblo.jp/woooh-p/ Yohta's Object World http://www002.upp.so-net.ne.jp/ys_oota/ 結城浩 - The Essence of Programming http://www.hyuki.com/dp/dpinfo.html etc.... ↑ デザインパターンとは？ † プログラム設計時に起こる典型的な問題とそれに対する解決策を整理し、再利用できるようにまとめたもの。 要は、プログラミングのノウハウ集です。 まずは、どのようなパターンがあるのかをおぼろげで良いので覚えておきましょう。 「あ、こんな処理書きたいな」という時に、この状況に合うパターンは無いかな・・・と調べられればとりあえず十分です。 ↑ 何が良いの？ † 優れたパターンを再利用できる 有名なパターン
Class::Accessor::Fast から Mouse へ - bonar note
Class::Accessor::Fast（以下 C::A::F）を使っているクラスで、例えば Role っぽいものを表現したくなったりして、Mouse::Role 使いたい！Mouseに移行しようかな、みたいなことがあったりします。 この2つは機能的にもだいぶ違うものでもちろん簡単には比較できません。Mouse の場合には 単純にアクセサを追加するだけじゃなくて、読み書き権限の制御や方を用いたvalidation等よりきめ細かい制約を持つクラスを作ることが可能になります。 なので、その機能の代償として単純なクラスでも当然遅くなります。ある程度はしょうが ないし、 そのコストを払う価値があれば問題ないのですが、どれくらいのインパクトなのかは知っ ておく 必要があると思います。とても小さなクラスで簡単なベンチマークを取ってみました。 以下の環境で行ないました。 Mac OS X 10.6 C
Exporter を使ったモジュールの継承 - daily dayflower
おまえは何を言っているんだみたいな話だったらすみません。 たとえば，foo() という関数を export している ModA というモジュールがあるとします。 package ModA; use strict; use warnings; use base qw( Exporter ); our @EXPORT = qw( foo ); sub foo { warn sprintf '%s::foo called', __PACKAGE__; } 1; こいつをたとえば #!/usr/bin/perl use strict; use warnings; use ModA; foo(); のように使うと， ModA::foo called at ModA.pm line 12.のように出ます。 ここまでは当たり前。 use ModB したら ModA::foo() を呼び出せるようにしたい
Rolling with Ruby on Rails
Now, next, and beyond: Tracking need-to-know trends at the intersection of business and technology AI/ML Few technologies have the potential to change the nature of work and how we live as artificial intelligence (AI) and machine learning (ML). Future of the Firm Everything from new organizational structures and payment schemes to new expectations, skills, and tools will shape the future of the fi
古くて新しい状態遷移 - ニコニコＣ＋＋入門
状態遷移表 ステートチャート図(UML) 入れ子をどんどん深くしていけばもっと複雑な状態も表せるのですが、あまり深くなりすぎるようならオブジェクトが大きすぎるのかもしれません。 図表を作成することで、各状態における処理を洗い出すことができることが解ったと思います。ところがいざこれをコーディングしようとすると、意外にもなかなか難しいのです。 複数の状態を管理してイベント発生時に適切な関数を呼び出すように管理するために、ややこしいフレームワークを書いて、関数テーブルを作成しなければなりません。こうした手間を軽減するためにCASEツールを用いる方法もあります。状態遷移に対応したCASEツールならば、状態やイベントの追加も簡単ですし、どの状態のどのイベントがテストされていないといったような情報を集めることもできます。 ところで状態遷移とオブジェクト指向の関連性はどうなっているのでしょうか？ オブジ
CGI::Application - 再利用可能なWEBアプリケーションを構築するためのフレームワーク
NAME SYNOPSIS INTRODUCTION USAGE EXAMPLE ABSTRACT DESCRIPTION Instance Script Methods Sub-classing and Override Methods Application Module Methods Testing PLUG-INS Existing plug-ins Writing Plug-ins Writing Advanced Plug-ins - Using callbacks COMMUNITY SEE ALSO AUTHOR CREDITS LICENSE Page Top NAME CGI::Application - 再利用可能なWEBアプリケーションを構築するためのフレームワーク Page Top SYNOPSIS # "WebApp.pm"の内容... package We
perlオブジェクト指向プログラミング /lib/mailmag
Object Oriented Programming w/ Perl melma! を使って発行しているたメールマガジンです。 Perl のオブジェクト指向やテスティング、デザインパターンなどの話題を中心に、2週間に1回程度発行していますした。 Name Last modified Size Description Parent Directory 26-Aug-2005 13:02 - 15/ 09-Mar-2001 16:23 - 16/ 21-Sep-2001 03:43 - 17/ 29-Mar-2001 20:22 - 18/ 13-Apr-2001 03:30 - 19/ 02-May-2001 12:30 - 20/ 17-May-2001 00:08 - 21/ 31-May-2001 11:58 - 22/ 09-Jun-2001 14:49 - 23/ 05-Jul-
Perlオブジェクト指向プログラミング
-> 趣旨と注意書き -> 身近なpackage -> なんのためのpackage ? -> What's `new' ? -> bless ( reference => package ) -> Hello, Module World! -> オブジェクト？ -> main パッケージと関連付けてみる -> クラスとメソッド -> オブジェクト指向 -> オブジェクトがリファレンスなら… -> -> を連続する -> 継承 -> 多重継承 -> 多重継承をやめる -> 多重継承をやめる(もう少し簡単に) -> 情報源(書籍等) <- モドル 趣旨と注意書き これを読んでも、あんまりきちっとした知識は、身に付きません（^^; オブジェクト指向の概念はほんの少ししか説明しません。ここで述べるのは、Perlでどうやるかってのが主です（それも不十分＆嘘まじりかも）。 とりあえず、モジュールを作り
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://blog.8-p.info/2009/02/class-sniff
writing your own dispatcher for fun (profit can come later)
http://www.crew.sfc.keio.ac.jp/lectures/2007s_obpro/ObjectShootingText/index.html
Perlオブジェクト指向プログラミング