クラス設計の原則 — みんなのウェディングエンジニアリングブログ
みんなのウェディングの高井です。 クラスベースのオブジェクト指向プログラミング言語を利用している人であれば、クラスとは、ありふれていて普段から利用するものです。にもかかわらず、良いクラスをつくるというのは、なかなかに難しいことです。 先日、みんなのウェディングでアルバイトをしてくれている学生さんのコードレビューをしていたときにも、それを強く感じました。 実践的プラグマティックには「ソフトウェアの規模や文脈にあわせて、適切に抽象化していただきたい」という以上のことを言っても仕方がないところなのですが、それだけでは経験の浅いプログラマーにとって、まったく分からないという話になってしまいます。 というわけで、今回はクラス設計の原則についてのお話しです。 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）の記事を転載します
prototype と __proto__ - フリーフォーム フリークアウト
移転しました http://please-sleep.cou929.nu/20100929.html
コードレビュー - hitode909の日記
コードレビュー，慣れるとできるけど，いきなりdiffを渡されて，どうぞ見てくださいと言われてもよくわからないと思う． やりましょうというのはいいけど，ただむやみに読んでもうまくいかない．変更がある程度大きくなるとdiffだけ見てもよくわからないので，いろいろ見ることになる． 僕はいつも以下のようなことを無意識にやってて，うまくいってる気がしてる．GitHubのPull Requestの仕組みを使ってる前提で． Discussionをさらっと眺めてどういう問題を解決したいのか見る Commit Statusを見て，テスト通ってることを確認する Commitsタブで1コミットずつブラウザの新しいタブに開く 全部クリックし終わったら古い順に1コミットずつ読む 気になる点があったらエディタとかにメモしておく．あとで書き直されるかもしれないので，まだコメントしない 全コミット見終わったらFiles
設定のクラスを作るとすっきりしそう - hitode909の日記
設定のテストを書くとよいって言ってる人がいた． 設定の仕様をドキュメントに書くのではなく、テストにしてしまう - $shibayu36->blog; テストされてるのはよいと思う．名前のついてないデータ構造をがんばってテストするよりは，設定のクラスを作るとすっきりしそうと思った． こういう構造のHash，として見るよりかは，設定クラスのインスタンスとして見るほうがイメージしやすい． 個々のブログの設定のURLはユニークであるというのを，どこかのクラスの責任にする．BlogConfigRepositoryというクラスのインスタンスが，設定の集合を持ってるとか． like exception { BlogConfigRepository->new([ { "url" : "http://blog.example.com/", "permission" : "public", "members"
意外と知られていない構造化プログラミング、あるいは構造化プログラミングはデータも手続きと一緒に抽象化する、あるいはストロヴストルップのオブジェクト指向プログラミング史観
意外と知られていない構造化プログラミング、あるいは構造化プログラミングはデータも手続きと一緒に抽象化する、あるいはストロヴストルップのオブジェクト指向プログラミング史観 書いた人: ると 猫型プログラミング言語史観(1) 〜あるいはオブジェクト指向における設計指針のひとつ〜という記事がありました。手続き型からの発展としてのオブジェクト指向という史観を書いた記事です。しかし、そこで次のように述べられている史観は少々単純化しすぎです。 手続き型プログラミングでは手続きを抽象化することで保守性を挙げることに成功したが、データを守ることには失敗してしまった。そこでオブジェクト指向はデータと手続きをひとかたまりにすることでデータを外から守るというコンセプトを打ち出した。 手続き型プログラミングの時代は、少なくとも思想的にはそこまで暗黒的ではありませんでしたし、「データと手続きをひとかたまりにする」の
bless($args, $class) is a bad practice - Islands in the byte stream (legacy)
さいきん散見される以下のようなコードは悪いコードです。 # usage: Foo->new({ age => 42 }) sub new { my($class, $args) = @_; return bless $args, $class; } それは、ハッシュリファレンスと想定される$argsのそのままつかっているため、引数としてハッシュリテラル以外の何かを渡すと予期しない動作を引き起こすという点です。 たとえば、以下のような使い方は問題を引き起こします。 my %args = (age => 20); my $o1 = Foo->new(\%args); my $o2 = Foo->new(\%args); # ここで $o1 と $o2 は同じオブジェクトになってしまう このような場合、$argsはコピーすべきです*1。またついでにハッシュリファレンスではなくkey-value
メルマ！
メルマ！サービス終了のお知らせ いつもメルマ！をご利用いただき誠にありがとうございます。 サービス開始以来、たくさんの皆様にご利用いただきましたメルマ！ですが、 誠に勝手ながら、2020年1月末を持って一部を除きサービスを終了させていただく事となりました。 今までのご愛顧、誠にありがとうございました。 1月末以降のスケジュールは以下となります。 （スケジュールは変更となる可能性があります） 2020年2月14日 マイメルマでの記事ダウンロード機能の停止（マイメルマの停止） 2020年3月2日 全てのデータを削除 記事データのダウンロード機能に関しては、マイメルマよりご利用ください。 今までご利用いただきまして、本当にありがとうございました。 サービス終了に伴うQ&A Q. 読者のメールアドレスは公開されますか？ A. メールアドレスはすべてメルマ！でお預かりしているものとなります。 大変申
Perlオブジェクト指向プログラミング
-> 趣旨と注意書き -> 身近なpackage -> なんのためのpackage ? -> What's `new' ? -> bless ( reference => package ) -> Hello, Module World! -> オブジェクト？ -> main パッケージと関連付けてみる -> クラスとメソッド -> オブジェクト指向 -> オブジェクトがリファレンスなら… -> -> を連続する -> 継承 -> 多重継承 -> 多重継承をやめる -> 多重継承をやめる(もう少し簡単に) -> 情報源(書籍等) <- モドル 趣旨と注意書き これを読んでも、あんまりきちっとした知識は、身に付きません（^^; オブジェクト指向の概念はほんの少ししか説明しません。ここで述べるのは、Perlでどうやるかってのが主です（それも不十分＆嘘まじりかも）。 とりあえず、モジュールを作り
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Object-oriented Programming -- Eloquent JavaScript
Amazon.co.jp: Object Oriented Perl: A Comprehensive Guide to Concepts and Programming Techniques: Conway, Damian (著), Schwartz, Randal L (はしがき): 本