タグ

オブジェクト指向に関するpeketaminのブックマーク (70)

  • 契約による設計事始め

    Object-Oriented Conferenceの発表資料です。 https://fortee.jp/object-oriented-conference-2020/proposal/1224f293-8624-4448-866f-5d1b991d377f カンファレンスの感想はこちら。 https://dnskimox.hateblo.jp/entry/2020/02/22/104342

    契約による設計事始め
    peketamin
    peketamin 2020/02/17
    めっちゃ分かりやすかった。感謝!
  • Object-Oriented Conference参加メモ - Qiita

    Object-Oriented Conference概要 ※イベント及びセッションの概要は公式HPから引用しました。 2020.02.16 SUN 10:00 - 17:00 お茶の水女子大学 #ooc_2020 Object-Oriented Conference はオブジェクト指向をテーマに、あれこれ共有したり、セッションを聴講することで、みなさんの知見を深めるためのイベントです。 オブジェクト指向といっても、分析設計から、現場で活かすためのプラクティスなど様々なテーマがあります。セッションやラウンドテーブルなどを通じて、参加者の皆様が新たな発見を持ち帰っていただけるようなイベントを目指しています。 オブジェクト指向についてまったく知らない方やオブジェクト指向を完全に理解した方、そして普段オブジェクト指向以外のパラダイムを利用している方もお気軽にご参加ください! 開会の挨拶 オブジェク

    Object-Oriented Conference参加メモ - Qiita
  • [Object-Oriented Conference] 資料まとめ | Qrunch(クランチ)

    技術ブログをはじめよう Qrunch(クランチ)は、プログラマの技術アプトプットに特化したブログサービスです 駆け出しエンジニアからエキスパートまで全ての方々のアウトプットを歓迎しております!

    [Object-Oriented Conference] 資料まとめ | Qrunch(クランチ)
  • 【本には書いてないオブジェクト指向⑤】小粒クラス | そるでぶろぐ

    ソリューション開発部の田中です。 ここに書いたのは、私が設計・実装したJavaのフレームワーク開発を主に通じて理解したオブジェクト指向の原理原則です。 私は単なるエンジニアであって学者や研究者ではない上に、オブジェクト指向について誰かから教わった経験も無いため、ここに書いてある内容は科学的に吟味されたものではありません。 しかし、普段の仕事の中で気付いた合理性のある内容だと考えています。オブジェクト指向言語を日常使ってはいても、オブジェクト指向そのものをみっちりと学習したことがない人にとって特に役立つ内容だと思います。 前回の記事はこちら。 様々なクラスで再利用可能なのが小粒クラス粒度が非常に小さいクラスのことを小粒(こつぶ)クラスと私は呼んでいます。次のようなものです。 数量金額日付氏名宛先クレジットカード番号電話番号などなど。 これらは、他のクラスの属性として使われることを前提としてい

    【本には書いてないオブジェクト指向⑤】小粒クラス | そるでぶろぐ
  • やってはいけないJavaプログラミング | ウルシステムズ株式会社

    1.これだけはやってはいけない 製品としてプログラムを記述する場合に「決して」やってはいけないのは、ソフトウエアに対する要求仕様を満たさないこと、つまり製品にバグを残すことです(注1)。仕様としてなにがどこまで定義されているかは、それぞれのプロジェクトによって異なるでしょう。シビアな場面では、メソッドの応答速度や使用メモリ量を定義することもあります。そこまでは掘り下げずに、画面仕様書とファイル仕様書、データベース仕様書だけで、「ボタンAが押されると、ファイルBに記述された設定にしたがってユーザの入力値を演算し、データベースのこのテーブルにこういう行を挿入、画面のこの個所に○○というメッセージを表示する」といった条件のみを定義することもあります。 いずれの場合でも、仕様を最終的にブレークダウンした結果である個々のプログラム、ソースコードが、これを満たしていることが最低限の完成条件となります。

    やってはいけないJavaプログラミング | ウルシステムズ株式会社
  • ソシオメディア | OOUI – オブジェクトベースのUIモデリング

    最近、OOUX という言葉を見聞きしました。これはオブジェクト指向の利用者体験(Object-Oriented User Experience)のことで、いくつかの記事を読んだところ、アプリケーション設計において画面とデータを対応づける際にオブジェクトを手掛かりにするという方法論のようです。つまり OOUX は「オブジェクトベースのUIモデリング」と言い換えることができそうです。そうすると実は以前からそのようなデザイン手法はあり、「OOUI(オブジェクト指向ユーザーインターフェース)」と呼ばれていたのです。最近になって OOUX という言葉が使われるのは、OOUI のことを知らなかったか、もしくは流行語である「UX」を用いた方がかっこいいと考えたからではないでしょうか。 「オブジェクトベースのUIモデリング」というデザイン手法は、GUI アプリケーションをデザインする際の基的なテクニック

    ソシオメディア | OOUI – オブジェクトベースのUIモデリング
  • 俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - 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

    俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - Qiita
  • 僕にとってMaybe / Nullable / Optional が、どうしてもしっくりこないわけ。 - 亀岡的プログラマ日記

    はい、ポエムです。自分が正しかろうとは欠片も考えていません。異論や示唆は歓迎ですが、そう考えろと言っているわけではないので、そこはご容赦を。 前置き終わり。 さて、Nullは50億ドルの過ちだそうですね。 null参照の考案は10億ドル単位の過ち? | スラド デベロッパー そして、それを回避するため、Maybe / Nullable / Optional などの言語機能が生まれ、各言語に埋め込まれています。 それは、大変喜ばしいこと、だと思います。 なんですが、どうもどうも、僕はどうしてもしっくりこないのです。これら全てに対して。Nullと同じように。 Nullは何がダメなんだっけ? Nullがダメな理由、ってなんなんでしょう。よく言われる批判として、以下があるのかなぁと思っています。 ①Nullは型ではない Nullと言っていますが、こいつはNullポインタ、でございます。 からの「何

    僕にとってMaybe / Nullable / Optional が、どうしてもしっくりこないわけ。 - 亀岡的プログラマ日記
  • すべてのソースコードが手元にあるのに不要な抽象化を行うのはよくない

    「よい」とされているプログラミング手法のひとつに差分プログラミングがある。クラスを継承して親クラスとの差分だけのコードを書けば、親ですでに実装されている機能はそのまま使えて、かつカスタマイズもできるというやつだ。 たとえばGUIのボタンをカスタマイズしてマウスオーバーするとなにかちょっと特殊なことを行うボタンを作りたいとしたら、ボタンクラスを継承して、マウスオーバーのイベントハンドラをちょいちょいとカスタマイズしてやればよい。差分プログラミングは大変素直でよいプログラミング手法のような感じがする。 よいのはよいと思う。 しかしこういういい例だけをみてそれをどこでも真似しようと思ってしまうと、不必要な抽象化を積み重ねる困ったプログラマになってしまう(そういう人は結構たくさんいる)。自分でプログラムを書く場合には、よくできたクラスライブラリやフレームワークをお手にして抽象化を行うのは、ほとん

  • 【PHPで学ぶデザインパターン入門】第1回 Strategyパターン | 株式会社LIG(リグ)|DX支援・システム開発・Web制作

    こんにちは、エンジニアの王です。 今回はデザインパターンと、デザインパターンの中の「Strategy」について紹介したいと思います。 デザインパターンとは? 端的にいうと、「よくある問題へのよくある解決策」です。 ここでは、あくまでもソフトウェア設計の場合に限定しているのですが、さまざまなコンテキストで活かせる概念です。 「今までの経験上、この手の問題なら、この方法(パターン)でやればうまくいくよ!」という経験則は誰にでもあると思います。それがゲームの場合なら「攻略法」、料理の場合なら「レシピ」、語学の場合なら「定型文」だったりします。 ソフトウェア設計の場合、特にオブジェクト指向プログラミングにおいて言うなら、「デザインパターン」とは、過去のソフトウェア設計者が失敗に失敗を重ね、試行錯誤の中から導き出した再利用しやすいノウハウの集大成のようなものです。 そう、要するに、柔軟性、拡張性、再

    【PHPで学ぶデザインパターン入門】第1回 Strategyパターン | 株式会社LIG(リグ)|DX支援・システム開発・Web制作
  • そのオブジェクト指向入門は間違っている(大げさ) - Webアプリエンジニア養成読本 AdventCalendar2014 25日目最終日! - uzullaがブログ

    はい、Webアプリエンジニア養成読 AdventCalendar2014です。突然トリをやる事になってしまったので、どうしたもんかとおもいます…。 「最終日だぞ…ちゃんとかかないといけない…しかしネタはない…そうだリンク集を作ろう!」とか思ったんですが、そもそもアドベントカレンダーってリンク集だよねって気付いて愕然としているクリスマスの夜です。現在朝の4時、これを書き終えて寝たい。 さて…何を話そう ここまでWebアプリエンジニア養成読アドベントカレンダーということで続けてきました。そして今日は25日、ついに最終日です! Webアプリエンジニア養成読 Advent Calendar 2014 - Qiita Webアプリエンジニア養成読[しくみ、開発、環境構築・運用…全体像を最新知識で最初から! ] (Software Design plus) 作者:和田 裕介,石田 絢一 (uz

    そのオブジェクト指向入門は間違っている(大げさ) - Webアプリエンジニア養成読本 AdventCalendar2014 25日目最終日! - uzullaがブログ
  • 問.Cでオブジェクト指向プログラミングを行なえ - 株式会社CFlatの明後日スタイルのブログ

    問.Cでオブジェクト指向プログラミングを行なえ。ただし「オブジェクト指向プログラミング」とは、次のような特徴を持つプログラミング技法であるものとする: オブジェクトの実装はオブジェクトのユーザーからは隠蔽される(カプセル化/隠蔽) 同一型のオブジェクトと同一メソッドを与えた時、実際のメソッドの動作はオブジェクトの内容により変化する(ポリモーフィズム/多態性) なお、ユーザーが既存のオブジェクトをカスタマイズして新たなオブジェクトを作成する機能は、必要ないものとする。 この問いの狙い よく、「オブジェクト指向プログラミング」と「オブジェクト指向言語」は混同されます。が、前者はプログラムを設計する上での考え方で、後者はその考え方を容易にソースコードに書けるような仕様になっている言語の事で、全く違うものを指しています。 その証拠を示すため、「非オブジェクト指向言語」たるC言語で「オブジェクト指向

    問.Cでオブジェクト指向プログラミングを行なえ - 株式会社CFlatの明後日スタイルのブログ
  • 「オブジェクト指向の価値ってよく分からないですよね」について - manie's blog

    そういえばCORBAとかROSEとかUMLとかやってた気がします。 プログラミング勉強中の人にオブジェクト指向とは何なのかを何となく伝えたい話 - かまずにまるのみ。 「オブジェクト指向の価値ってよく分からないですよね。」 誕生の歴史を知ればよい。環境によっては価値がある。 コンピュータは情報数学と電子回路から誕生した。電子回路は半導体によってハードウェアからソフトウェアとなり、機械語(そしてアセンブリ言語)が必要になった。C言語はアセンブリ言語に配列と構造体を加えたものだ。手続型言語ではデータ構造とアルゴリズムを同時に設計するが別々の保守が必要だった。保守は同時にやるべきだ。データ構造とアルゴリズムを同時に同じ場所で実装し保守出来る仕組みがクラスだ。 情報数学と電子回路 情報数学は乱暴に言えばビット演算学だ。NOTとORとANDを使ってあらゆる命題論理を電子回路で置き換え可能な式に書き下

    「オブジェクト指向の価値ってよく分からないですよね」について - manie's blog
  • 再考: GoF デザインパターン - Qiita

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

    再考: GoF デザインパターン - Qiita
  • おすすめオブジェクト指向練習方法 | サイバーエージェント 公式エンジニアブログ

    はじめに みなさんはじめまして。 アメーバ事業ゲーム部門でJavaエンジニアをやってる朝倉です。

    おすすめオブジェクト指向練習方法 | サイバーエージェント 公式エンジニアブログ
  • オブジェクト指向とは結局メンタルモデルのモデリング手法である - assertInstanceOf('Engineer', $a_suenami)

    きしださんのエントリが話題です。 オブジェクト指向は禁止するべき - きしだのはてな 「禁止するべき」とはまた随分と煽りタイトルですねと思いつつも、内容自体はとても納得のいくものでした。 ただ「オブジェクト指向」というのはいろいろな観点で語られることが多く、多少モヤモヤとはしているので僕の考えを書いてみようと思います。 なお、きしださんご自身は以下の補足エントリで立場は明確にされています。エントリはこれを否定するものではありません。あくまで違った立場からの意見です。*1 オブジェクト指向について - きしだのはてな 参考までに、ぼくの基的な定義は、ランボーの「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」という定義に従っています。そのようなオブジェクトが単体ではなく組織化されるということが重要です。オブジェクト指向を勉強するとはそのような組織

    オブジェクト指向とは結局メンタルモデルのモデリング手法である - assertInstanceOf('Engineer', $a_suenami)
  • オブジェクト指向は禁止すべき!?なのか つれづれ/shi3z:電脳ヒッチハイクガイド:電脳空間カウボーイズZZ(電脳空間カウボーイズ) - ニコニコチャンネル:生活

    麻布十番でひさしぶりに「もや鍋」をべながらボケーっとしていたら、「オブジェクト指向は禁止するべき」という記事がタイムラインにながれてきていて、「なぬ!?」と思ったのだけど、まともな記事だった。 オブジェクト指向がなぜ優れているのか、というかなぜ世の中はオブジェクト指向を必要としたのか、という点について無視すると、たしかに初心者にオブジェクトの概念教えるのは難しいんだよね。 僕は基的にゲームプログラミングから入っているから、オブジェクト指向というのはびっくりするくらい重要というか、当たり前のものの一つになっている。 ゲームだとオブジェクトというのが画面に現れる。 例えば弾とか敵とかね、あれがひとつひとつオブジェクトだよ、と言われれば納得する。 その昔、ナムコの業務用基盤(ギャラクシアンとか)ではスプライトのことをオブジェクトと呼んでいたくらいだからゲーム=オブジェクト指向は揺るぎないと思

    オブジェクト指向は禁止すべき!?なのか つれづれ/shi3z:電脳ヒッチハイクガイド:電脳空間カウボーイズZZ(電脳空間カウボーイズ) - ニコニコチャンネル:生活
    peketamin
    peketamin 2014/07/20
    "8ビットマシンの上にSmalltalkのVMを実装してRPGを作ったり(天外魔境だ)する凄腕の話を聞いてガクブル", "だがこの世代のオジンどもが絶滅すると"
  • オブジェクト指向は禁止するべき - きしだのHatena

    プログラムがまだ不慣れな人が「プログラムちょっとわかるようになったけど、まだぜんぜんオブジェクト指向とかできてません」のように言ったり、ちょっと慣れた人が「このソース、ぜんぜんだめ。オブジェクト指向ができてない」にようなことを言ったり、まるで、オブジェクト指向ができてるかどうかがよいプログラムかどうかを表すことになってるようだ。 Javaのアルゴリズムのに、「Javaなのにオブジェクト指向ができていない」のような書評がついているのを見たときには、お前は何を求めてるんだと思ったりもした。 そのようなオブジェクト指向は、窓から投げ捨てるべきだ。オブジェクト指向はプログラムのよしあしの基準にならない。 むだにHogeインタフェースとHogeImplクラスがあったり、むだにnewするだけのcreateメソッドがあったり、どこで値が設定されてるかわからないオブジェクトがひきまわされてたり、ソースコ

    オブジェクト指向は禁止するべき - きしだのHatena
    peketamin
    peketamin 2014/07/19
    知人が「OOはフレームワークとか基盤作成したい人が使うといいものだと思う」と言ってて膝を打った覚えが
  • オブジェクト指向設計原則 - Strategic Choice

    原則について優れたオブジェクト指向開発のための指針。ただ、、、原則は原則。必ず守らなければならないのではなく、まずそれで考えることが重要。逸脱したとしても正当な理由やトレードオフが説明できればよい。一覧単一責任の原則(SRP)オープン・クローズドの原則(OCP)リスコフの置換原則(LSP)依存関係逆転の原則(DIP)インターフェイス分離の原則(ISP)参考アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技作者: ロバート・C・マーチン, 瀬谷啓介出版社/メーカー: ソフトバンククリエイティブ発売日: 2008/07/01メディア: 大型 Principles Of Object Oriented Designオブジェクト指向設計@Syboos.jpオブジェクト指向設計の原則@それはBooksオブジェクト指向設計原則@ディノオープンラボラトリオブジェクト指向の法則

  • 単一責任の原則(SRP) - Strategic Choice

    単一責任の原則(SRP:the Single Responsibility Principle) クラスを変更する理由は1つ以上存在してはならない。どういうこと?変更理由が2つあるということは、責任(役割)も2つあるということ。そんなジェネラリストなクラスを許さない、という原則。 ところで、「単一責任」って、クラスを作る上で一見当たり前に見える。責任(役割)をそのまま責任ではなく、変更理由としているところがポイント。 この見る角度を変えるところがこの原則の運用の大切な所。なんで?役割を複数もつクラスはもろいクラスだから。 複数の役割を担っているクラスがあって、それをある1つの理由で変更すると、関係のないその他の役割部分にまで影響を及ぼす事になり、その結果予想もしない形でクラスが壊れてしまう。 保守で違う人が修正したら簡単に壊れてしまう。 保守で変更していくと、実装的だけでなく、設計的にもよ