タグ

oopに関するlax34のブックマーク (36)

  • 現実世界の事象から学ぶSOLID原則

    # Object-Oriented Conference 2024 https://fortee.jp/oocon-2024/proposal/e1eb34cf-78ef-43f6-8a03-bb26c996cb62 概要 オブジェクト指向プログラミング (OOP) のコーディング慣例として広く採用される、SOLIDの原則。 コードの保守性、拡張性、再利用性を語る上では共通言語としても使用される一方で、初学者にとっては決して理解のしやすいものではありません。 これらの原則が抽象的であり、実際のコードにどのように適用されるか・適用した際に得られるメリットを理解するのが難しいことが理解を困難にする一因です。 しかし一度理解すると、SOLID原則が現実世界のありとあらゆる場所で適用されていることに気が付くはずです。 「clean architecture 達人に学ぶソフトウェアの構造と設計」にお

    現実世界の事象から学ぶSOLID原則
    lax34
    lax34 2024/03/25
  • オブジェクト指向は必要なのか / Is object-oriented needed?

    2024/3/24に開催されたObject-Oriented Conferenceでの登壇資料です。 https://ooc.dev/2024/

    オブジェクト指向は必要なのか / Is object-oriented needed?
  • 値オブジェクトの表明を使って検証を実装する方法 - Qiita

    題に入る前に、値オブジェクトの表明を使って検証を実装する方法に、必要な検証(バリデーション)と表明(アサーション)の違いについて以下にまとめる。 検証(バリデーション) 以下のブログ記事によると、3種類のバリデーションがあるようです バリデーションには3種類のバリデーションがある 〜 セキュアなアプリケーションの構造 〜 が、日常的にはこのあたりは区別せずに「入力値の確認」と認識していると思います。厳密に表現すると「入力値が要件を満たしているか妥当性を確認すること」になります。Error, Defect, Fault, Failureの定義と解釈のエラー(Error)のカテゴリ。 以下は、バリデーションロジックの一例。値が満たすべき要件を確認するロジックを記述しますが、場合によっては複数の検証を組み合わせて一つの検証を行うことがあります。 object Validators { type

    値オブジェクトの表明を使って検証を実装する方法 - Qiita
  • 単一責任原則で無責任な多目的クラスを爆殺する - Qiita

    この記事は クラウドワークスアドベントカレンダー2020 8日目の記事です。 概要 こんにちは、クソコードを爆殺リファクタリングするのが大好きなミノ駆動です。 今回は単一責任原則の話です。 単一責任原則はSOLID原則のひとつとして有名で、2020年のオブジェクト指向カンファレンスのアンケートでも、SOLID原則の中で最も人気がありました。 皆さんは単一責任原則を遵守した設計をしていますか。 どんな構造が単一責任設計で、一方どんな構造が単一責任でない設計か、明確に意識していますか。説明できますでしょうか。 ところで「単一責任原則とはなんぞや」について、少なくとも私の観測範囲では、概念的な話にとどまっているものが多く、コードレベルで具体的に説明しているものは少ないように感じます。 そうした状況からか、単一責任原則の解釈が人によって違っていたりしているように感じます。 記事は、今一度単一責任

    単一責任原則で無責任な多目的クラスを爆殺する - Qiita
  • 個人的なアプリケーション設計のバイブル3選 - Runner in the High

    自分が格的に設計を意識するようになったのは、2015年の夏に現職であるFringe81株式会社で開催されていたサマーインターンに参加してからだ。 インターンではDDDとクリーン・アーキテクチャ*1を一から勉強してAPIサーバーに実装する、というカリキュラムであったが、いま思うと2週間という比較的長いインターンで僕が学べたことと言えば当に微々たるものだった。つまるところ、それくらいには設計というものは奥が深い。常になんらか特定のデザイン・パターンなりアーキテクチャ・パターンを適用することでアプリケーション開発がうまくいくということはなく、それらの様々な知識から少しづつ応用されたものが最終的なアプリケーションの設計に対して真の洞察を与えてくれるものというのが、僕自身のいまの認識である。 設計はまさに Connecting the dots そのものだ。多くを知れば知るほど、アプリケーション

    個人的なアプリケーション設計のバイブル3選 - Runner in the High
  • オブジェクト指向プログラミングを学ぶための推薦図書 - ソフトウェア設計を考える

    オブジェクト指向プログラミングを学ぶ オブジェクト指向プログラミングという言葉は、広い意味で使われている。 オブジェクト指向プログラミングをキーワードにすべての情報をかき集めて理解するというアプローチは現実には無理。 目に付いた重要そうなところを見繕って集めてみても、たぶん混乱するだけ。 この記事では、オブジェクト指向プログラミングのいろいろなアプローチの中で、 クラスを使って独自の「型」を定義するプログラミングスタイル 関連するデータとロジックをまとめて、小さな入れ物に格納する「カプセル化」を重視するプログラミングスタイル を学ぶための参考図書を紹介したい。 型とカプセル化に重点を置く設計スタイルがわかってくると、それとは異なるスタイル、異なる力点を置くアプローチとの違いが具体的にわかるようになってくる。*1 *2 まずは、オブジェクト指向プログラミングの中で、型・クラス・カプセル化に力

    オブジェクト指向プログラミングを学ぶための推薦図書 - ソフトウェア設計を考える
  • DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien - Digital Romanticism

    この記事はartima developerに掲載されている、Trygve Reenskaug氏とJames O. Coplien氏による記事「The DCI Architecture: A New Vision of Object-Oriented Programming」を、著作権者であるBill Bennrs氏の許可を得て翻訳したものです。文内の図の著作権はArtima, Inc.に帰属します。(原文公開日:2009年3月20日) 要約 オブジェクト指向プログラミングはプログラマとエンドユーザの視点をコンピュータコードにおいて統一するものと考えられていた。この恩恵はユーザビリティとプログラムの分かりやすさの両面にわたる。しかし、オブジェクトは構造をとらえるのに長けている一方で、システムの動作をとらえることができていない。DCIはエンドユーザのロールに関する認識モデルとロール間の関係を

    DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien - Digital Romanticism
  • オブジェクト指向のいろは - Qiita

    ※追記しました 2018/11/10 サンプルコードの言語について、この記事で触れなかったものとその理由について 2018/11/11 諸注意補足 2018/11/12 コードフォーマット、タイポ修正 2018/11/13 ポリモーフィズムのサンプルが弱いとの指摘を頂き追記 はじめに この記事はオブジェクト指向プログラミング初学者向けの記事です。 記事の内容はオブジェクト指向プログラミングの入り口までを解説しているつもりです。 またオブジェクト指向分析やオブジェクト指向設計については取り扱いません。 オブジェクト指向についてを完全に理解するにはこの記事だけでは足りないと思いますのでその点ご留意願います。 サンプルコードは C# です。 スライドが元ネタになっていて、以下の url がそのスライドです。 もし興味が湧いたらどうぞ。 https://nrslib.com/oop-slide-1

    オブジェクト指向のいろは - Qiita
  • 自己流オブジェクト指向プログラミング&Javaお奨め本2007年版 - カレーなる辛口Javaな転職日記

    http://d.hatena.ne.jp/JavaBlack/20050909/p1の改訂.*1基的に改訂版への差し替えと一部の新刊の追加程度になっている. お奨めのJava&オブジェクト指向プログラミング関連の書籍/参考文献リスト.初心者向け入門書や参考書から上級者向けの専門書まで,オブジェクト指向だとかJava言語とかの初心者〜中級者が学習をすすめる上での参考にすることを想定して作っている. 初心者向け勉強の手引き:http://d.hatena.ne.jp/JavaBlack/20070825/p1 オブジェクト指向プログラミング とりあえず初心者なら「オブジェクト指向プログラミング入門」「オブジェクト指向における再利用のためのデザインパターン」と,あと「リファクタリング―プログラムの体質改善テクニック (Object Technology Series)」くらいかな.ただしリフ

    自己流オブジェクト指向プログラミング&Javaお奨め本2007年版 - カレーなる辛口Javaな転職日記
  • オブジェクト指向プログラミングとは結局なんなのか | 黒曜の吹き溜まり

    この記事は第2のドワンゴ Advent Calendar 2015の5日目です。 ちなみに前日は@deflisさんでした。 先日の記事で分かる通りドワンゴ社員()なのですが、まぁ@mesoさんが「厳格な管理とかめんどくさいので、元社員も参加すればいいんじゃないかな。」とか言ってるしお目こぼし頂きたく… 去年のアドベントカレンダー記事は「関数型プログラミングとは結局なんなのか」というタイトルで、関数型プログラミングという語が何を指していて何を指していないのか、みたいなことをなるべく平易にまとめました。 なので今年は「オブジェクト指向プログラミング(以下OOP)とは結局なんなのか」という記事にしてみた…のですが、なにぶん語の指す範囲が広く、また自分も理解しきっているわけではないので、多少不正確な点があるかもしれません。 「関数型は流行りだけど、今更OOPかよ」とか思われるかもしれませんが、お付

  • Martin Fowler's Bliki in Japanese - ドメインモデル貧血症

    http://martinfowler.com/bliki/AnemicDomainModel.html これはずいぶん昔からあるアンチパターンのひとつですが、今になって台頭してきているようです。 Eric Evans と話したのですが、彼も、それがだんだんポピュラーになってきていることに気づいていました。 私たちほど大の「真Domain Model」推進者としてみれば、ちょっとうれしくありません。 ドメインモデル貧血症の基的な症状は、一見、それが物のドメインモデルに見えるという点です。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。それから、オブジェクト同士がしっかりとしたリレーションで結びついており、物のドメインモデルと同じような構造を持っているのです。 ただし、オブジェクトの振る舞いを見れば違いが分かります。それらのオブジェクトにはわずかな

  • 再考: GoF デザインパターン - Qiita

    投稿は私の主観によって書かれています。コメントは大歓迎です。もし長くなるようでしたら別途記事に投稿し、リンクを張っていただけると嬉しいです。 概要 GoFのデザインパターンは適当すぎるから、いい加減、修正されるべき。 参考までに各パターンに対するコメントを書く。 GoFのデザインパターン GoFのデザインパターンは適当であり、教科書通りに学ぶべきものではないように思う。 以下がGoFのデザインパターンの良くない原因だろう。 が出版されたのは1994年であり、Java(1995)が出てくるよりも前だった オブジェクト指向が未成熟な時代にカタログ化された 現代のプログラミングと合致しないものが多い 「オブジェクト指向における~」と断っている以上、OOPに絡める必要があった パターンのいくつかに「多態性を用いると便利」という蛇足がついている 挙げたパターンに根拠がない 「とりあえず、23個ほ

    再考: GoF デザインパターン - Qiita
  • if文の条件式の書き方あれこれ | GuildWorks Blog

    if文の条件式の書き方あれこれ | GuildWorks Blog
  • オブジェクト指向の法則集 - Qiita

    この記事は、故石井勝さんが1999年に書いた記事を Qiita に転載するものです。オブラブ(objectclub.jp)にて記事をホスティングしていましたが、現代でも十分に読める内容なので、たくさんの方に読んでもらいたいと思い、若干の編集(リンクとコンテキスト追加)を平鍋が行い、転載します。今でも、読みやすく、カジュアルな語り口のよい記事です。 オブジェクト指向の法則集(転載元:http://objectclub.jp/community/memorial/homepage3.nifty.com/masarl/article/oo-principles.html ) なお、この記事の他にも石井さんのオブジェクト指向やRubyに関する多くの記事をオブラブの「まさーるのページ」で読むことができます。では、以下に石井勝さん(旧メールアドレス masarl@nifty.com)の記事を転載します

    オブジェクト指向の法則集 - Qiita
  • いまさら聞けない「オブジェクト指向設計の3つのコツ」~オブジェクト指向設計問題解説 #objectoriented - CodeIQ Blog

    CodeIQ中の人、millionsmileです。 いろいろ経歴を積むと、「いまさら聞けない」ことが増えてきます。「オブジェクト指向」というのもそんないまさら聞けないものの一つでしょうか。 そんなわけで、いまさら聞けないことをイマサラ問題として出題してみました。 問題は、日ITエンジニアの父と言いたくなるくらい温かみのあるフィードバックをしてくれることで好評な有限会社システム設計の増田亨さんからの出題です。オブジェクト指向設計について2問出題していただきました。総計65名もの方に挑戦いただきました! 問題の解説記事は、オブジェクト指向設計の3つのコツを中心に説明してくれていますので、読みやすいですし、頭にすっと入ってきます。 ではでは、増田亨さんによる解説記事をお楽しみください。 https://codeiq.jp/ace/toru_masuda/ ◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇

    いまさら聞けない「オブジェクト指向設計の3つのコツ」~オブジェクト指向設計問題解説 #objectoriented - CodeIQ Blog
  • オブジェクト指向プログラミングの教え方? | システム設計日記

    技術者仲間で話していたら、4月入社の新人に、オブジェクト指向プログラミングをどうやって教えたらよいか?、という話になった。 想定している言語は Java。 ■動物・犬・モデルの説明から ■基用語の説明から:「カプセル化とは」「継承とは」... ■サンプルコードから: System.out.println( "hello world" ) ... どのパターンでもうまくいかなかったので、今度の新人研修では何か工夫したいね、という話。 結論から言うと「これだ」というアイデアがでたわけではないが、話の内容は、いろいろ興味深かったのでメモ書き。 Java はオブジェクト指向の言語なの? Java は、ある意味 C言語の仲間。ある側面はほとんど同じ言語。 ・int, long (プリミティブなデータ型) ・配列操作 ・if/for/return ここだけ見れば、C言語のまま。つまり命令型、手続き

  • PHP製DIコンテナ"yadif"をZend_Applicationと共に使う - noopな日々

    Zend_Applicationはフレームワークの設定と主要インスタンスの管理に使いますが、今のところモデル用のリソースがありません。 PHP製のシンプルなDIコンテナ"yadif"は設定によるオブジェクトの生成と管理が可能で、モデルの管理にも適します。ここでは、yadifを利用してサービスリソースを作成し、アプリケーションからモデルにシンボル名でアクセスできるようにします。 Zend_Applicationでのリソースの作成その他については、公式マニュアルに十分な解説がありますが、こちら(Zend_Application (5) 実戦的使い方 - noopな日々)でも書きました。 Yadif - Yet Another Dependency Injection Framework を使う GitHub - tsmckelvey/yadif: Yet Another (PHP) Depen

    PHP製DIコンテナ"yadif"をZend_Applicationと共に使う - noopな日々
  • IBM Developer

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    IBM Developer
  • オブジェクト指向の設計と実装の学び方のコツ

    1. 学習パターンを実践する オブジェクト指向の設計と実装の 学び方のコツ 2012年9月12日 有限会社 システム設計 増田 masuda@system-sekkei.com Twitter : @masuda220

    オブジェクト指向の設計と実装の学び方のコツ
  • プロとしての行為 Act as Proffesional

    オブジェクト指向エクササイズ下記のルールで、1000行程度のソフトウェアを書いてください。 1. 1つのメソッドにつきインデントは1段階までにすること 2. else句を使用しないこと 3. すべてのプリミティブ型と文字列型をラップすること 4. 1行につきドットは1つまでにすること 5. 名前を省略しないこと 6. すべてのエンティティを小さくすること 7. 1つのクラスにつきインスタンス変数は2つまでにすること 8. ファーストクラスコレクションを使用すること 9. Getter、Setter、プロパティを使用しないこと というルールが適応できない場合は優先すべきルールを選択し、どのルールを適応するのか判断して欲しいとの旨が記載されています。 9つのうち 7つがデータのカプセル化 1つポリモフィズの適切な利用(else句をつかわない) 1つが明確でわかりやすい命名標準 オブジェクト指向

    プロとしての行為 Act as Proffesional