オブジェクト指向と10年戦ってわかったこと - Qiita
この記事の内容 オブジェクト指向は難しい！わかった気になって実践すると詰みます... ｳｷﾞｬｰ この記事は10年以上オブジェクト指向と戦った筆者が、通常とは異なるアプローチでオブジェクト指向を解説したものです。 筆者はJavaを使って本格的なシステム開発をしたことがありませんが、オブジェクト指向言語として最もポピュラーなJavaをベースにオブジェクト指向について解説させていただきました。 また、この記事の続編にあたります「なぜオブジェクト指向は難しいのか」を更に2年の時を経て執筆させて頂きました！是非こちらも一読していただけると嬉しいです。 オブジェクト指向三大要素の謎 オブジェクト指向三大要素ってありますよね。オブジェクト指向は「カプセル化」「継承」「ポリモーフィズム」の3つの要素で成り立つと言われています。最近では、この三大要素が語られる傾向は薄いようですが、一度は耳にしたことがある
開発者が知っておくべきSOLIDの原則 | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) オブジェクト指向プログラミングが、ソフトウェア開発に新しい設計を持ち込みました。 その結果、開発者は単一の目的を処理するために、全体のアプリケーションに関係なく、1つのクラスの中で、同じ目的や機能を持つデータを結び付けることができるようになりました。 しかし、このオブジェクト指向プログラミングで、分かりにくいプログラムやメンテナンスができないプログラムを防ぐことはできません。 そこで、5つのガイドラインがRobert C. Martinによって作り出されました。これら5つのガイドラインすなわち原則により、開発者にとって読みやすく、メンテナンスが可能なプログラムを作成しやすくなりました。 5つの原則は、S.O.L.I.Dの原則と呼ばれています（頭字語はMichael Feathereによって名付けられま
オブジェクト指向プログラミングを学ぶための推薦図書 - ソフトウェア設計を考える
オブジェクト指向プログラミングを学ぶ オブジェクト指向プログラミングという言葉は、広い意味で使われている。 オブジェクト指向プログラミングをキーワードにすべての情報をかき集めて理解するというアプローチは現実には無理。 目に付いた重要そうなところを見繕って集めてみても、たぶん混乱するだけ。 この記事では、オブジェクト指向プログラミングのいろいろなアプローチの中で、 クラスを使って独自の「型」を定義するプログラミングスタイル 関連するデータとロジックをまとめて、小さな入れ物に格納する「カプセル化」を重視するプログラミングスタイル を学ぶための参考図書を紹介したい。 型とカプセル化に重点を置く設計スタイルがわかってくると、それとは異なるスタイル、異なる力点を置くアプローチとの違いが具体的にわかるようになってくる。*1 *2 まずは、オブジェクト指向プログラミングの中で、型・クラス・カプセル化に力
PHPの現場#27を聴いた / interfaceについて - iakioの日記
面白かった。最近ぜんぜんPHPは書いてないんですが。 php-genba.shin1x1.com 感想書かなきゃとおもいながらダラダラしてたらもう次のエピソードが出ていたんだけど、1つ前のエピソードの感想です。 "長谷川さんのところのコードリファクタリングしにいきたい" 新原さんkonmari感ある #phpgenba— ISHIDA Akio (@iakio) 2019年2月26日 いろんな過程を経て、@shin1x1 さんの伝えたいことが熟成されてきている感じがして良い。 途中、interfaceを書くかという話で意見が分かれていた。僕も @shin1x1 さんと同じで、interfaceを使うことに特別な感情はない。 僕も昔はinterfaceを何のために書くのかわからなかったけど、今は「とりあえずinterfaceにしておいて、classでもいいかと思ったらclassにしよう」くら
「オブジェクト指向とは、現実世界を正しく捉えること」という理解はデメリットのほうが大きい
これは「オブジェクト指向」がよくわかってない人の書いたポエムである。 そういうのが嫌いな人はお帰りください。 はじめに リンクは貼らないが「オブジェクト指向の本質とは現実を正しく捉えること」と書かれている記事（以下、元記事）がバズった。 私は正直「オブジェクト指向」の何たるかを理解しているとは言い難い。 しかし、そんな私でも元記事がいくつかの点でおかしい、もっと厳しくいうと開発現場に混乱をもたらす可能性を持っていることは理解できる。そこでこの記事では「オブジェクト指向とは〇〇である」という言及は行わずに、元記事の問題点を指摘するに留める。 長方形と正方形の例 オブジェクト指向プログラミングと現実世界の話というとBobおじさんが『アジャイルソフトウェア開発の奥義』に書いた正方形と長方形の話が有名だ。 話は簡単だ。「正方形クラスは長方形クラスを継承するべきか？」というものだ。 少しだけ詳しく見
どんな時にクラスを final と宣言するのか
Ocramius さんの記事、When to declare classes final を、ご本人の許可を得て翻訳してみました。 Ocramius さんありがとー。 誤訳等にお気付きの際は、コメントや編集リクエストをもらえると助かります。 まとめ：インタフェースを実装していて他のパブリックメソッドが定義されていない場合、いつもクラスを final にしてください。 この 1 ヶ月で、私は PHP クラスへの finalの使い方について何度か議論をしました。 そして以下のような流れが繰り返されました。 私が新しく作られたクラスへ final を宣言するよう頼む コードを書いた人は嫌がり final は柔軟性を損なうと主張 柔軟性は良い抽象化から生まれるのであって、継承から生まれるのではないという説明が必要となる この流れから明らかなのは、コードを書く人達にどんな時に final を使うのか
どこに何を書くのか?
13. type User struct { Attack int //攻撃力 } func main() { u := User{ Attack: 100, } //攻撃力は int の Attack に乱数を加算したものになる rand.Seed(time.Now().UnixNano()) u.Attack = u.Attack + rand.Intn(10) fmt.Println(u.Attack) } 14. type User struct { Attack int //攻撃力 } func main() { u := User{ Attack: 100, } //攻撃力は int の Attack に乱数を加算したものになる rand.Seed(time.Now().UnixNano()) u.Attack = u.Attack + rand.Intn(10) fmt.Pr
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向では、モデリング（分析）、設計、実装は、切れ目のない一体の活動。初期の分析は初期の設計であり、初期の実装。毎日分析し、毎日設計し、毎日実装しながら、一歩一歩、モデルも実装も進化させていく。Read less
俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - Qiita
ちなみに、最初に結論だけ言っておくと、まずSandi Metzの「オブジェクト指向設計実践ガイド」を読め、という話です それだけで終わってしまいたい気持ちはあるが、不親切過ぎるしもうちょっとRails向けの話を書こうと思う。 ただ言いたいことは、よく分かってないのに使うのは止めろということ。 自分も本で書いたりした手前、それが参考にされた結果なのかもしれないが、世の中には本当に酷いクラスが存在するもので、雑にサンプルで書くと以下の様な感じのコードが存在したりする。 class HogehogeService # Hogehogeはモデル名まんま def process(hogehoge, option_a: nil, option_b: nil, option_c: false) history = hogehoge.histories.last unless hogehoge.activ
オブジェクト指向と20年戦ってわかったこと - Qiita
この記事の内容 オブジェクト指向と10年戦ってわかったこと Twitterやはてブコメントを見たら、「わかりやすかった」というコメントもあったのですが、どちらかというとネガティブ方面なコメントが多く目につきました。マサカリという用語で忌憚なく意見を言う風潮については別にいいんですが、「わかりにくい」「間違っている」「古い」みたいなコメントは何も生み出さないし、みんなでニコニコポエムを投稿しあうやさしいインターネッツになったらいいなって思ったので、僕もオブジェクト指向について投稿しようと思います。 何原則？ ３原則じゃなくて4では？みたいなコメントもあったのですが、別に3でも4でも5でも重要ではないかなって思います。この4原則の出どころがどこかは知らないですが、C++かSmalltalkあたり(このあたりの話を見かけたのはJava登場前だった気がする)をターゲットとしている気がします。Jav
ORMは不快なアンチパターン | To Be Decided
このエントリでは、Yegor Bugayenkoによる記事、ORM Is an Offensive Anti-Patternを紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 結論から言えば、ORMはオブジェクト指向プログラミングの原則の全てに違反するひどいアンチパターンだ。オブジェクトをバラバラに引き裂き、もの言わぬ受身なデータ入れに変えてしまう。 小さいWebアプリケーションから、数千のテーブルをCRUD操作するエンタープライズシステムまで、どんなアプリケーションにもORMが存在することはゆるせない。 代わりになるものは? SQLを話すオブジェクトだ。 ORMの仕組み オブジェクト関係マッピング (Object-relatinal mapping、ORM
オ・ト・ナのカプセル化再入門 - Qiita
よく、初心者向けの教科書に「とりあえずprivateを指定し、必要な物はpublicにしましょう。」と書いてありますが、これは大きな間違いです。 最初にアクセス修飾子を熟知しておかなければ、Java という言語を扱う上で最良の設計を行なうことは難しいでしょう。 そんな教科書は今すぐ窓から投げ捨てるか、ちり紙代わりに使いましょう。 Package パッケージは Java のクラス郡をまとめるための仕組みです。主に利用する目的として、以下の 2 点ががあります。 名前の衝突を避ける事が出来る。 パッケージによるアクセス制御を行なえる。 これらを利用する事で Facade デザインパターンを忠実に実現することができます。 Java のカプセル化においてこの仕組みは必要不可欠でしょう。 Design patterns 次に、ソフトウェア設計において基本的な 2 パターンを紹介します。 Facade
クラス設計の原則 — みんなのウェディングエンジニアリングブログ
みんなのウェディングの高井です。 クラスベースのオブジェクト指向プログラミング言語を利用している人であれば、クラスとは、ありふれていて普段から利用するものです。にもかかわらず、良いクラスをつくるというのは、なかなかに難しいことです。 先日、みんなのウェディングでアルバイトをしてくれている学生さんのコードレビューをしていたときにも、それを強く感じました。 実践的プラグマティックには「ソフトウェアの規模や文脈にあわせて、適切に抽象化していただきたい」という以上のことを言っても仕方がないところなのですが、それだけでは経験の浅いプログラマーにとって、まったく分からないという話になってしまいます。 というわけで、今回はクラス設計の原則についてのお話しです。 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）の記事を転載します
JavaScriptでの継承の基本パターン４つ - Qiita
はじめに JavaScriptでオブジェクト指向言語の継承に相当する概念を実装する方法は、大きく分けて4つあります。実務上はライブラリを使ったり、TypeScriptを使ったりと、直接意識する必要があることは少ないわけですが、それだといつまでたっても「JavaScriptにおける継承」を理解できません。ES6で、シンタックスシュガーとしてのclass / extendも導入される可能性も高そうですが、そんな今だからこそ「本来はどう書くのか？」を整理してみることにしました。 1) コンストラクタを使いprototypeチェーンを使って継承する 2) コンストラクタは使うが、prototypeチェーンは使わず、prototypeを直接拡張する 3) コンストラクタは使わず、prototypeチェーンを使って継承する 4) コンストラクタもprototypeも使わず、直接オブジェクトを拡張する
[JavaScript] そんな継承はイヤだ - クラス定義 - オブジェクト作成 - Qiita
JavaScript のオブジェクト作成においてクラス定義で継承を実装する方法はいくつかあります。 正しい継承はどうあるべきか、基本から検証しながら考えてみたいと思います。 ※正しくクラス定義がエコ楽にできる様に追加記事書きました。 [JavaScript] getter/setterも使えるエコ楽なクラス定義 - もちろん継承も - private変数も 一番簡単なオブジェクトの作成方法 典型的な JavaScript のオブジェクトを簡単に作成してみて、それらを確認してみましょう。 var obj1 = {x: 12, y: "ab"}; var obj2 = new Object; // または new Object() obj2.x = 34; obj2.y = "cd"; // obj < Object var obj3 = [12, "ab"]; var obj4 = new
![[JavaScript] そんな継承はイヤだ - クラス定義 - オブジェクト作成 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/41f59c9a4c5233d80d36d92d499f0102af401195/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCSmF2YVNjcmlwdCU1RCUyMCVFMyU4MSU5RCVFMyU4MiU5MyVFMyU4MSVBQSVFNyVCNiU5OSVFNiU4OSVCRiVFMyU4MSVBRiVFMyU4MiVBNCVFMyU4MyVBNCVFMyU4MSVBMCUyMC0lMjAlRTMlODIlQUYlRTMlODMlQTklRTMlODIlQjklRTUlQUUlOUElRTclQkUlQTklMjAtJTIwJUUzJTgyJUFBJUUzJTgzJTk2JUUzJTgyJUI4JUUzJTgyJUE3JUUzJTgyJUFGJUUzJTgzJTg4JUU0JUJEJTlDJUU2JTg4JTkwJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz05YmU1OWFiZTFhMWQ5OGU4YzNjNDEyZTcxZmZmZWM1NA%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwTGlnaHRTcGVlZEMmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTYzYzc5NWFkZTZlZDJmZTFhY2Q1MGM0Zjk0OTA4YzFm%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3De3ed084b4388f1f96f451ecce07646e4)
オブジェクト指向とは結局メンタルモデルのモデリング手法である - assertInstanceOf('Engineer', $a_suenami)
きしださんのエントリが話題です。 オブジェクト指向は禁止するべき - きしだのはてな 「禁止するべき」とはまた随分と煽りタイトルですねと思いつつも、内容自体はとても納得のいくものでした。 ただ「オブジェクト指向」というのはいろいろな観点で語られることが多く、多少モヤモヤとはしているので僕の考えを書いてみようと思います。 なお、きしださんご自身は以下の補足エントリで立場は明確にされています。本エントリはこれを否定するものではありません。あくまで違った立場からの意見です。*1 オブジェクト指向について - きしだのはてな 参考までに、ぼくの基本的な定義は、ランボーの「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」という定義に従っています。そのようなオブジェクトが単体ではなく組織化されるということが重要です。オブジェクト指向を勉強するとはそのような組織
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
オブジェクト指向のその前に-凝集度と結合度/Coheision-Coupling
ダブル・ディスパッチ～ 典型的なオブジェクト指向プログラミング・イディオム ～
オブジェクト指向の設計と実装の学び方のコツ
