Ruby のココがダメ - Qiita
タイトルは釣りです。Ruby に盲目的に惚れている迂生には Ruby の痘痕（あばた）はエクボです。 それはともかく。 メソッド名の別名がありすぎ 「あなたは map 派？ それとも collect 派？」っていう問いがまず嫌い。 いや，別名にも意義があるとは思うんだけど，記憶の負担が大きい。 自分では map しか使わなくても，他人のコード読むんだったら collect を知っていなくちゃならない。 しばらく前に reduce っていうメソッド見て，そんなのあったっけ？と思ったら inject の別名だった。 map/collect と inject/reduce の名前とその背景にある発想については，Rubyist Magazine に良い記事がある： そうかと思えば，Array#delete_if と Array#reject! みたいに，働きは基本的に同じだけど，削除が行われなかっ
単一責任の原則（SRP） - Strategic Choice
単一責任の原則（SRP:the Single Responsibility Principle） クラスを変更する理由は1つ以上存在してはならない。どういうこと？変更理由が2つあるということは、責任（役割）も2つあるということ。そんなジェネラリストなクラスを許さない、という原則。 ところで、「単一責任」って、クラスを作る上で一見当たり前に見える。責任（役割）をそのまま責任ではなく、変更理由としているところがポイント。 この見る角度を変えるところがこの原則の運用の大切な所。なんで？役割を複数もつクラスはもろいクラスだから。 複数の役割を担っているクラスがあって、それをある1つの理由で変更すると、関係のないその他の役割部分にまで影響を及ぼす事になり、その結果予想もしない形でクラスが壊れてしまう。 保守で違う人が修正したら簡単に壊れてしまう。 保守で変更していくと、実装的だけでなく、設計的にもよ
Strategic Choice
Problemこのクラスは大きすぎて、もうこれ以上大きくしたくありません。「単一責務の原則」を適用してクラスを分割しようと思います。分割の具体的な方法がわかりません。Strategy「クラスの抽出」を適用します。どんなとき？「単一責務の原則」を適用してクラスを分割しようと思います。責務を把握したので、分割の実装を行いますが、具体的な方法がわかりません。どうする？「クラスの抽出」リファクタリングを適用します。ほとんどのレガシーシステムにおいて、最初にできることは、「実装レベル」で単一責務の原則を適用することです。つまり、大きなクラスから「クラスの抽出」をして、抽出クラスに委譲することです。「インタフェースレベル」で単一責務の原則を導入するには、より多くの作業が必要です。クラスの呼び出し側を変更しなければならず、テストも必要になります。まず、実装レベルで単一責務の原則を導入しておくと、将来イン
そのオブジェクト指向入門は間違っている（大げさ） - Webアプリエンジニア養成読本 AdventCalendar2014 25日目最終日！ - uzullaがブログ
はい、Webアプリエンジニア養成読本 AdventCalendar2014です。突然トリをやる事になってしまったので、どうしたもんかとおもいます…。 「最終日だぞ…ちゃんとかかないといけない…しかしネタはない…そうだリンク集を作ろう！」とか思ったんですが、そもそもアドベントカレンダーってリンク集だよねって気付いて愕然としているクリスマスの夜です。現在朝の4時、これを書き終えて寝たい。 さて…何を話そう ここまでWebアプリエンジニア養成読本アドベントカレンダーということで続けてきました。そして今日は25日、ついに最終日です！ Webアプリエンジニア養成読本 Advent Calendar 2014 - Qiita Webアプリエンジニア養成読本[しくみ、開発、環境構築・運用…全体像を最新知識で最初から! ] (Software Design plus) 作者:和田 裕介,石田 絢一 (uz
再考: GoF デザインパターン - Qiita
本投稿は私の主観によって書かれています。コメントは大歓迎です。もし長くなるようでしたら別途記事に投稿し、リンクを張っていただけると嬉しいです。 概要 GoFのデザインパターンは適当すぎるから、いい加減、修正されるべき。 参考までに各パターンに対するコメントを書く。 GoFのデザインパターン GoFのデザインパターンは適当であり、教科書通りに学ぶべきものではないように思う。 以下がGoFのデザインパターンの良くない原因だろう。 本が出版されたのは1994年であり、Java(1995)が出てくるよりも前だった オブジェクト指向が未成熟な時代にカタログ化された 現代のプログラミングと合致しないものが多い 「オブジェクト指向における～」と断っている以上、OOPに絡める必要があった パターンのいくつかに「多態性を用いると便利」という蛇足がついている 挙げたパターンに根拠がない 「とりあえず、23個ほ
オブジェクト指向の法則集 - Qiita
この記事は、故石井勝さんが1999年に書いた記事を Qiita に転載するものです。オブラブ(objectclub.jp)にて記事をホスティングしていましたが、現代でも十分に読める内容なので、たくさんの方に読んでもらいたいと思い、若干の編集（リンクとコンテキスト追加）を平鍋が行い、転載します。今でも、読みやすく、カジュアルな語り口のよい記事です。 オブジェクト指向の法則集（転載元：http://objectclub.jp/community/memorial/homepage3.nifty.com/masarl/article/oo-principles.html ） なお、この記事の他にも石井さんのオブジェクト指向やRubyに関する多くの記事をオブラブの「まさーるのページ」で読むことができます。では、以下に石井勝さん（旧メールアドレス masarl@nifty.com）の記事を転載します
オブジェクト指向は禁止するべき - きしだのHatena
プログラムがまだ不慣れな人が「プログラムちょっとわかるようになったけど、まだぜんぜんオブジェクト指向とかできてません」のように言ったり、ちょっと慣れた人が「このソース、ぜんぜんだめ。オブジェクト指向ができてない」にようなことを言ったり、まるで、オブジェクト指向ができてるかどうかがよいプログラムかどうかを表すことになってるようだ。 Javaのアルゴリズムの本に、「Javaなのにオブジェクト指向ができていない」のような書評がついているのを見たときには、お前は何を求めてるんだと思ったりもした。 そのようなオブジェクト指向は、窓から投げ捨てるべきだ。オブジェクト指向はプログラムのよしあしの基準にならない。 むだにHogeインタフェースとHogeImplクラスがあったり、むだにnewするだけのcreateメソッドがあったり、どこで値が設定されてるかわからないオブジェクトがひきまわされてたり、ソースコ
より安全なJavaScriptを書くために、あったらいいよねという機能 - mizchi's blog
こんな記事があった。 My ECMAScript 7 wishlist | NCZOnline 大雑把にいうと、制限されたgetterがほしいという意見に記事のほとんどが割かれてる。 JavaScriptのデバッグ中、一番つらいものの一つに、未定義値にアクセスしたときにundefinedが代入されており、その結果が次のアクセスにならないとわからないという点だと思う。 o = { a: () => 1, b: () => 2, c: () => 3, d: () => 4 } f = o.e // ここでエラーにならない // 30行ぐらいのコードがあって忘れるとする f() // エラー これが辛い。これを回避するためにどんな仕様が必要か。 というわけで、自分がほしいものはなんだろうと考えてみた。(注意：この記事は上の記事の翻訳記事ではない) 僕自身があんまりES harmonyの議論追っ
オブジェクト指向プログラミングの教え方？ | システム設計日記
技術者仲間で話していたら、4月入社の新人に、オブジェクト指向プログラミングをどうやって教えたらよいか？、という話になった。 想定している言語は Java。 ■動物・犬・猫モデルの説明から ■基本用語の説明から：「カプセル化とは」「継承とは」．．． ■サンプルコードから： System.out.println( "hello world" ) ．．． どのパターンでもうまくいかなかったので、今度の新人研修では何か工夫したいね、という話。 結論から言うと「これだ」というアイデアがでたわけではないが、話の内容は、いろいろ興味深かったのでメモ書き。 Java はオブジェクト指向の言語なの？ Java は、ある意味 C言語の仲間。ある側面はほとんど同じ言語。 ・int, long （プリミティブなデータ型） ・配列操作 ・if/for/return ここだけ見れば、C言語のまま。つまり命令型、手続き
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
