タグ

oopとprogrammingに関するclavierのブックマーク (21)

  • オブジェクト指向は必要なのか / Is object-oriented needed?

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

    オブジェクト指向は必要なのか / Is object-oriented needed?
  • クラス設計本格入門 JJUGナイトセミナー 2021-6-16

    イベントの動画 : https://www.youtube.com/watch?v=2Z1CJhPk-f8 オブジェクト指向プログラミングはクラス設計。 クラス設計はプログラムの分割。 クラス設計の焦点は、ビジネスルールを表現するクラスと、ビジネスアクションを表現するクラス。 クラス設計やパッケージ設計の実証済の形を覚えると、出発地点の設計が楽になる。 リファクタリングを積み重ねて設計を改善していく。

    クラス設計本格入門 JJUGナイトセミナー 2021-6-16
  • オブジェクト指向のその前に-凝集度と結合度/Coheision-Coupling

    Jetpack ComposeとGraphQLによるServer Driven UI/jetpackcompose-grahpql-serverdrivernui

    オブジェクト指向のその前に-凝集度と結合度/Coheision-Coupling
  • Getter/Setterは悪だ。以上。 | To Be Decided

    このエントリでは、Yegor Bugayenkoによる記事、Getters/Setters. Evil. Period.を紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 2003年にAllen Holubが書いたWhy getter and setter methods are evilという有名な記事に端を発する古い議論がある。それは、getter/setterはアンチパターンで避けるべきものなのか、 もしくはオブジェクト指向プログラミングに必須なものなのかというもの。 この議論に少しだけ私の意見を加えたいと思う。 上記記事の要旨はこうだ。 getterやsetterはひどい慣習で、これらを使うやつらはゆるせん。誤解の無いようもう一度言うが、 私はget

  • 設計要件をギッチギチに詰めたValueObjectで低凝集クラスを爆殺する - Qiita

    /// <summary>契約金額</summary> public class ContractAmount { public int AmountIncludingTax; public decimal SalesTaxRate; } 当然データの入れ物(以後データクラスと呼称)だけでなく、税込み金額を計算するロジックが必要です。ここであまり設計を考えないと、この手の演算ロジックはデータクラスとは別のクラスに実装されることが多いです。以下のようにControllerに実装されることが多いのではないでしょうか。 /// <summary>契約コントローラー</summary> public class ContractController { private ContractAmount _contractAmount; /// <summary>税込金額を計算する。</summary>

    設計要件をギッチギチに詰めたValueObjectで低凝集クラスを爆殺する - Qiita
  • 社内勉強会で『オブジェクト指向設計実践ガイド』いいぞっていう話をした - TMD45'β'LOG!!!

    いま Ruby をやってるひとなら、オブジェクト指向設計を学ぶ・復習するのに最適なだと思う。まさに実践ガイド。一度身につけておくと、言語問わずに使える知識。すぐに仕事に活かせてとても役に立ったと感じた。 こんなひとにおすすめ 自分がそうでしたという意味で。 オブジェクト指向設計はなんとなく知ってるけど実践のイメージが湧いてない オブジェクト指向設計というと継承の親子関係のイメージしか浮かばない 実装をしながら「いいと思って書いてるけど、これは当にいいのかな…」と迷うことが多い とくに Rails を使っていて設計や実装に迷うことが多い 「Rails における良い設計」の表面的な部分に振り回されている気がする オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方 作者: Sandi Metz,?山泰基出版社/メーカー: 技術評論社発売日: 20

    社内勉強会で『オブジェクト指向設計実践ガイド』いいぞっていう話をした - TMD45'β'LOG!!!
  • オブジェクト指向入門読み終わった - はこべにっき ♨

    ちまちま読んでたオブジェクト指向入門を読み終わった。だいたい入門と言っているが、原題は"Object-Oriented Software Construction"で入門感はないし、上下巻あわせて2000ページくらいあって読みきるのが大変だった。 原著は18年前に発売されただが、内容のほとんどは今でも有益で、全体を通してためになる。オブジェクト指向が解決しようとしている課題や、背景にある理論や考え方について解説してくれるだけではなく、実際にソフトウェアを設計する際にどのようにクラスを見つけ、どんな場面で継承を使い、ソフトウェア全体をどのように形作っていくのかという実践的な議論も充実している。 の序盤では、ソフトウェアの品質の様々な側面についての解説や、オブジェクト指向以前から使われていたモジュールや型の概念のがもつ諸課題について詳しく解説してくれる。それらの問題をふまえ、次に、ソフトウ

    オブジェクト指向入門読み終わった - はこべにっき ♨
  • fam.cx

    This domain may be for sale!

  • インスタンスメソッドとクラスメソッドはどのようにして使い分けるべきか?(Rubyの場合) | mah365

    Rubyといったオブジェクト指向言語を学ぶと、メソッドの定義方法としてインスタンスメソッドとクラスメソッドという2通りの定義方法があることを学ぶと思います。しかし、言語自体のガイドブックには「定義方法にインスタンスメソッドとクラスメソッドがある」と書いてあるだけで、大抵その使い分けについては書かれていません。 そういう訳で、このエントリではその使い分けについて少し考えてみたいと思います。理論的に厳密な使い分けを目指すというよりは、そもそも使い分けの検討が全くつかない!という方に向けて、その指針の一助となることを目指します。 インスタンスメソッドとクラスメソッドとはそもそものところ、Rubyといった「オブジェクト指向の考え方」を実装した言語の機能です。その機能がなぜあるのか?というそもそものところは、オブジェクト指向の考え方にさかのぼることになります。 そこで、インスタンスメソッドとクラスメ

    インスタンスメソッドとクラスメソッドはどのようにして使い分けるべきか?(Rubyの場合) | mah365
  • デザインパターンの話 - Qiita

    irxground 君が再考: GoF デザインパターンといふ記事を書いてゐるので自分もちょっとコメントしてみます。 基的に irxground 君と同意見のところは省略します。 あと、GoF の自体は私は読んでゐません。 (GoF のパターン以外のパターンに関する意見の方が長くなってますね……。) GoF のデザインパターン 生成に関するパターン Builder そもそも builder パターンは Java の String と StringBuilder の様に可変オブジェクトと不変オブジェクトを別のクラスに設計しなければならない言語でしか基的に役に立たないパターンであり、C++ の様にキャストだけで可変オブジェクトを不変オブジェクトに変換できる言語ではこのパターンは無用なはずである。 Java が出る前のでこれがパターンとして挙げられてゐたといふのが俺には不思議に感じられる

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

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

    再考: GoF デザインパターン - Qiita
  • 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い あきらめるにはまだ早い!ソースコードの品質向上に効果的なアプローチ 2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 この記事について この記事は新人向けの研修内容を再編集してお送りいたします。 ここで述べる内容はどのようにして現在のプログラミングスタイルが生まれてきたかを

    新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 - Qiita
  • https://qiita.com/tokomakoma123/items/fb7530232912dc4176c4

  • 設計におけるオブジェクトの責務分配に有効なものさし -凝集度と結合度- | オブジェクトの広場

    1. はじめに 皆さん、こんにちは。私はオージス総研でオブジェクト指向技術を用いたSI、コンサルティングを業務とする、プロの仕事を目指す、一介のUMLシルバーレベル1のプログラマ2です。ソフトウェア業界では、オブジェクト指向も、もはや普通の技術として認知されています。有名なマイクロソフトのVB、VC++をはじめ、現在使用している開発環境のほとんどは、すべてオブジェクト指向をサポートしているといってもよいでしょう。オブジェクト指向を知らない人でも、気が付かないうちにオブジェクト指向している、なんてこともあるようです。 でもオブジェクト指向は、単にソフトウェアをより良く作るための手段のひとつですから、上手く利用しないと、そうするつもりはなくても、とんでもないソフトウェアを作ってしまうことになりかねません。悲しいことに、オブジェクト指向は結構敷居が高いと思います。オブジェクト指向のメリットである

    設計におけるオブジェクトの責務分配に有効なものさし -凝集度と結合度- | オブジェクトの広場
  • ドメイン駆動設計入門

    6. ドメインモデル • 業務のデータと業務の機能をコードで表現 – ビジネス層に集約する – 関係するデータと機能をクラスにまとめる • ハイブリットなアプローチ – データの視点と機能の視点 • 両方からアプローチする • 二つの視点をいったりきたりする – データと機能の結びつき強める • クラスにカプセル化 • データ保持クラスと機能クラス(データ操作クラス) に分けるのはアンチパターン

    ドメイン駆動設計入門
  • class based OOPとprototype based OOPの違いについて

    methane @methane オブジェクトはクラスじゃないと言われると、クラスオブジェクト作るだけの Python はクラスが無いな/ 最強オブジェクト指向言語 JavaScript 再入門! on @slideshare #javascript http://t.co/aA53uLvN4k methane @methane var Hoge = new Function() を class Hoge: と書いたらほぼ Python. だが obj.meth はメソッドをオブジェクトにバインドするのでその点使いやすい。

    class based OOPとprototype based OOPの違いについて
  • じゃんけんごときにクラスなんて要るのか - yarbの日記

    CodeIQというプログラミング課題に挑戦するサイトに、Rubyでジャンケンクラスを作れという問題があったのでやってみた。すでに問題は読めなくなっているけど、こんな感じのJankenクラスを作れという。 $ irb > require './janken.rb' > left = Janken.new > right = Janken.new > left.versus(right) 左の人が勝ました。右「チョキ」左「グー」 > left.versus(right) 右の人が勝ちました。右「チョキ」左「パー」 : :繰り返しirbで実行できるように、とある。 問題を見た瞬間、これは問題自体がおかしいのではないかと思ったけど、やってみた。 # -*- coding: utf-8 -*- class Janken attr_reader :hand NAME = { goo: "グー", ch

    じゃんけんごときにクラスなんて要るのか - yarbの日記
  • オブジェクト指向できていますか?

    3. 自己紹介 1992年~1997年 某ゲーム会社 プログラマ SFC,GB,PS1,N64のゲーム開発経験 1998年~現在 日工学院八王子専門学校 @mozmoz1972 専任講師 プログラミング教育を中心に担当 twitterもfacebookも実名です。よかったらフォローしてください。

    オブジェクト指向できていますか?
  • Open-Closed Principle とデザインパターン

    1999/09/03 更新 石井 勝 さて,このセクションではデザインパターンを統一的に理解するために,「 Open-Closed Principle (OCP) 」 という設計ルールに基づいてパターンを眺めてみることにします.まず OCP の意味と解説を行い,その後デザインパターンを OCP の観点から見てみます.実は,デザインパターンのうちの多くは OCP を満たすために用意されたものと考えることができるのです.このセクションでは, OCP を理解し,数あるデザインパターンの中からどういう場合にどのパターンを使うのが一番効果的なのかを考えます. GoF のデザインパターンは,全部で 23 個ものパターンがあります.このデザインパターンは,多くの局面で繰り返し現れる設計を抽出したものですから,オブジェクト指向のエッセンスを集めたものだと言えるでしょう.オブジェクト指向には,カプセル化

  • 今風の型理論入門(本編) - 檜山正幸のキマイラ飼育記 (はてなBlog)

    前ふりは「型→代数→…それから:型理論入門(の前半)」にあります。これは編(後半)。1回読み切り(長いけど)で、比較的新しい*1型理論を紹介します。「入門(門に入る)」というよりは門の外から中を覗いてみる程度。 説明用コードはJavaの構文を使います。ただし、パッケージ宣言は書かないし、publicはなるべく省略。 内容: インターフェースなんて、所詮こんなもの 心理的効果とか、人間-人間コミュニケーションとかは、別問題 わけわからんインターフェースに制約を付加する もっと制約を足してみる 謎のインターフェースに意図されたもの で、それが型理論にどうつながるの? インターフェースなんて、所詮こんなもの まず、次のインターフェースを見てください。 interface AB { int a(); void b(); } これスゴイでしょ。何がスゴイって、これを見てもなんのことやらサッパリわか

    今風の型理論入門(本編) - 檜山正幸のキマイラ飼育記 (はてなBlog)