2024/3/24に開催されたObject-Oriented Conferenceでの登壇資料です。 https://ooc.dev/2024/
設計原則はよい設計をするための指針です。 では、よい設計とはなんでしょうか? もっとも重要なソフトウェア品質は発展性 ソフトウェアの発展性がビジネス価値を生む 発展性をうみだす7つの設計原則 モジュール化 モジュール化の2つのアプローチ 型によるモジュール化 手続き的なモジュール化 関心の分離 関心の4象限 入出力と計算・判断の分離 業務の関心と実装の詳細の分離 もっとも複雑な関心事(ビジネスロジック)の分離を徹底する カプセル化と抽象化 カプセル化 ビジネスロジックのカプセル化 抽象化 データ抽象 ビジネスロジックとデータ抽象 高凝集と疎結合 凝集度 結合度 隠された結合性の問題 定義の一点性 見た目が同じコード 7つの設計原則の学び方 コードの実装例 ドメインオブジェクト設計のガイドライン 実践ガイドとして使える本 設計の考え方を理解するための本 もっとも重要なソフトウェア品質は発展性
クラス 「クラス」と一言にいってもさまざまであるため、ここでは構造、動作、状態を定義できるものを指すことにします。 また、この章では概念を示す場合はクラスと呼び、クラスに関する構文(記述するコード)のことをclass構文と呼びます。 クラスとは動作や状態を定義した構造です。 クラスからはインスタンスと呼ばれるオブジェクトを作成でき、インスタンスはクラスに定義した動作を継承し、状態は動作によって変化します。 とても抽象的なことに思えますが、これは今までオブジェクトや関数を使って表現してきたものです。 JavaScriptではES2015より前まではclass構文はなく、関数を使ってクラスのようなものを表現して扱っていました。 ES2015でクラスを表現するためのclass構文が導入されましたが、このclass構文で定義したクラスは関数オブジェクトの一種です。 class構文ではプロトタイプベ
似たような話の繰り返しで恐縮ですが、現時点での自分の理解の整理のためのメモ。 前後しますが、こうして改めてまとめてみると、純粋な抽象データ型のオブジェクト指向プログラミングは、メッセージングのオブジェクト指向の影響も多分に受けている OOAD(分析・設計)のテコ入れ無しには、ちょっと弱っちく&古くさい感じが否めませんね(何をいまさら…ですが)。^^; とはいえ、OOAD は OOP とはまた別のものなので、同じ「抽象データ型の〜」あるいは「メッセージングの〜」だからといって対応する OOP とひとくくりにしてよいかというとそういうわけでもないので(整理・分類上は)難しいところです。 ▼ 抽象データ型のオブジェクト指向プログラミング 端的には、「ユーザー定義型(抽象データ型)」を、当初は「クラス」、今はそれに加えて「インタフェース」に準ずる言語機能によるサポートを前提として実践するプログラミ
OOP is considered by many to be the crown jewel of computer science. The ultimate solution to code organization. The end to all our problems. The only true way to write our programs. Bestowed upon us by the one true God of programming himself… Until…it’s not, and people start succumbing under the weight of abstractions, and the complex graph of promiscuously shared mutable objects. Precious time a
きっかけ たまたま?最近よくオブジェクト指向の理解方法について、続けていくつかの言及を読んだ。 オブジェクト指向が5000%理解できる記事 - Qiita オブジェクト指向を「わからなく」する三つの方法。 1. 現実世界の「物」をオブジェクト指向の「オブジェクト」だと説明する。自動車、犬猫、炊飯器に電子レンジ... 2. 継承、ポリモーフィズム、カプセル化をオブジェクト指向の三点セットと説明する 3. UMLクラス図ではデータモデリングする— 増田 亨. (@masuda220) 2018年9月26日 1つ目はまさに。 結局自分は4,5年迷走したのち習うより慣れろで自分の回答はある程度出た。 https://t.co/FDHWm83iU0— 🤓k.bigwheel🤓 (@k_bigwheel) 2018年9月26日 2つ目についてはカプセル化が一番重要でそのほかはかなり劣ると思う。 継
(編注:2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) オブジェクト指向プログラミングが、ソフトウェア開発に新しい設計を持ち込みました。 その結果、開発者は単一の目的を処理するために、全体のアプリケーションに関係なく、1つのクラスの中で、同じ目的や機能を持つデータを結び付けることができるようになりました。 しかし、このオブジェクト指向プログラミングで、分かりにくいプログラムやメンテナンスができないプログラムを防ぐことはできません。 そこで、5つのガイドラインがRobert C. Martinによって作り出されました。これら5つのガイドラインすなわち原則により、開発者にとって読みやすく、メンテナンスが可能なプログラムを作成しやすくなりました。 5つの原則は、S.O.L.I.Dの原則と呼ばれています(頭字語はMichael Feathereによって名付けられま
Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んでます。モデリングに関しては成分薄めですが、よい本だと思います。はい。 Clean Architecture 達人に学ぶソフトウェアの構造と設計 作者: Robert C.Martin,角征典,高木正弘出版社/メーカー: KADOKAWA発売日: 2018/07/27メディア: 単行本この商品を含むブログを見る 本書の大筋から少し逸れるが、「5章 オブジェクト指向プログラミング」の「カプセル化」が面白かったので、これを切り口にモデリングについて考えてみる。 OO言語のカプセル化はすでに弱体化している オブジェクト指向の三大要素の一つである、カプセル化について、以下のようなことが書いてあります。 「カプセル化」がOOの定義の一部となっているのは、OO言語がデータと関数のカプセル化を簡単かつ効果的なものにしているから
このテーマで書く前に、まず、最初に自分に多少の偏りがあることを認めておかなくてはなりません。 オブジェクト指向より、関数指向寄り オブジェクト指向のアプローチは有用だが、ただしそれを実現する手段はクラスと継承ではない。 階層化されたツリー構造(GUI/リレーショナルな参照構造)に埋め込まれる状態はコード品質を悪化させるので、できるだけ出現するべきではない。 ただし、状態は確実に存在する。だからこそ慎重に扱うべきだ、という派閥です アンチパターン: 特に理由もないクラスメソッドへの所属 何かのバリデータを実装したいとします。 その関数がどこに所属するかについて、よく見るこれらの実装は全部アンチパターンといっていいと思います export class Validator { static validate() {...} } export class Validator { validate(
@joker1007さんが激推ししてたのでオブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方を読んだ。 なんかすんませんw Sandi Metz本はここ数年でトップクラスに良い本だったのでオススメです。 #railsdm— ジョーカー (onkさんに返済完了) (@joker1007) 2017年12月9日 内容としては、オブジェクト指向設計の核となるものを初めての人でもわかりやすく理解できるように書かれた本という感じ。 この手の本は静的型付け言語でかかれたものが多いがRubyで書かれてるのでゆるふわなwebエンジニアにも読みやすそう。 流行りのDDDをやるにもまずオブジェクト指向がしっかり理解できてないと厳しいし、まずはしっかり土台を固めようぜみたいな。 オブジェクト指向を理解した気になっている人とか、新卒で入社してきたwebエンジニア諸氏に
ちなみに、最初に結論だけ言っておくと、まず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
技術者仲間で話していたら、4月入社の新人に、オブジェクト指向プログラミングをどうやって教えたらよいか?、という話になった。 想定している言語は Java。 ■動物・犬・猫モデルの説明から ■基本用語の説明から:「カプセル化とは」「継承とは」... ■サンプルコードから: System.out.println( "hello world" ) ... どのパターンでもうまくいかなかったので、今度の新人研修では何か工夫したいね、という話。 結論から言うと「これだ」というアイデアがでたわけではないが、話の内容は、いろいろ興味深かったのでメモ書き。 Java はオブジェクト指向の言語なの? Java は、ある意味 C言語の仲間。ある側面はほとんど同じ言語。 ・int, long (プリミティブなデータ型) ・配列操作 ・if/for/return ここだけ見れば、C言語のまま。つまり命令型、手続き
みんなのウェディングの高井です。 クラスベースのオブジェクト指向プログラミング言語を利用している人であれば、クラスとは、ありふれていて普段から利用するものです。にもかかわらず、良いクラスをつくるというのは、なかなかに難しいことです。 先日、みんなのウェディングでアルバイトをしてくれている学生さんのコードレビューをしていたときにも、それを強く感じました。 実践的プラグマティックには「ソフトウェアの規模や文脈にあわせて、適切に抽象化していただきたい」という以上のことを言っても仕方がないところなのですが、それだけでは経験の浅いプログラマーにとって、まったく分からないという話になってしまいます。 というわけで、今回はクラス設計の原則についてのお話しです。 Bertrand Meyerのクラス設計の原則 Bertrand Meyerは『オブジェクト指向入門 第2版』の中で、クラス設計について章をひと
April 01, 201323:55 カテゴリプログラム 継承か委譲か、それが問題だ この記事は新ブログに引っ越しました。 Where is the mate to the Sock! 「プログラム」カテゴリの最新記事 タグ :#委譲#継承#delegate#inheritance#多重継承#菱形継承#オブジェクト指向
Googleで適当に検索すると とズラリと出てくる。 オブジェクト指向 v.s. 関数型プログラミング 関数型とオブジェクト指向という一見相反するプログラミングパラダイムの併用について理解した プログラマが知るべき97のこと/関数型プログラミングを学ぶことの重要性 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 関数型プログラミングとオブジェクト指向の抜き差しならない関係について整理して考える とそれなりに参考になりそうな情報はあるものの、無駄に複雑化されたオブジェクト指向をストローマンにするような記事ばかり(それだけ今までのオブジェクト指向にみんなうんざりさせられているのだろう)で、そろそろきちんと自分自身「関数型プログラミングとオブジェクト指向の切り離され方」についてはっきりさせておきたい、と考え、概念整理した結論を書きます。 まず端的な結論 結論を
Very roughly speaking, functional programming (“FP”) and object-oriented programming (“OOP”) have similar levels of expressive power and similar abilities to encapsulate programs into smaller parts that can be combined and recombined. The biggest difference between the two “schools of thought” concerns the relationship between data and operations on the data. The central tenet of OOP is that data
基本的にオブジェクトと関数はおんなじもので、Javaのラムダ式では記述は関数だけど扱いはオブジェクトになってたりします。逆に、関数でオブジェクトを実現することもできます。 なので、オブジェクトと関数が、モノとしてどう違うかっていう話にはあまり意味がなくて、問題は表現としてどう違うかってことになると思います。 表現として、オブジェクトはフィールドとかプロパティとかで状態をもって、その状態をもとにいろいろ動いて、状態を変えます。 関数は引数をとって、その引数をもとにいろいろ動いて、戻り値を返します。 オブジェクトは状態が大事、関数はデータの流れが大事、って感じになります。 アプリケーションの中では、ユーザーインタフェースとデータ構造・ストレージは状態が大事です。処理に関してはデータの流れが大事です。 ここで、ユーザーインタフェースやデータ構造はプラットフォームごとに一揃えあれば充分です。ストレ
プログラムがまだ不慣れな人が「プログラムちょっとわかるようになったけど、まだぜんぜんオブジェクト指向とかできてません」のように言ったり、ちょっと慣れた人が「このソース、ぜんぜんだめ。オブジェクト指向ができてない」にようなことを言ったり、まるで、オブジェクト指向ができてるかどうかがよいプログラムかどうかを表すことになってるようだ。 Javaのアルゴリズムの本に、「Javaなのにオブジェクト指向ができていない」のような書評がついているのを見たときには、お前は何を求めてるんだと思ったりもした。 そのようなオブジェクト指向は、窓から投げ捨てるべきだ。オブジェクト指向はプログラムのよしあしの基準にならない。 むだにHogeインタフェースとHogeImplクラスがあったり、むだにnewするだけのcreateメソッドがあったり、どこで値が設定されてるかわからないオブジェクトがひきまわされてたり、ソースコ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く