2024/3/24に開催されたObject-Oriented Conferenceでの登壇資料です。 https://ooc.dev/2024/
2024/3/24に開催されたObject-Oriented Conferenceでの登壇資料です。 https://ooc.dev/2024/
イベントの動画 : https://www.youtube.com/watch?v=2Z1CJhPk-f8 オブジェクト指向プログラミングはクラス設計。 クラス設計はプログラムの分割。 クラス設計の焦点は、ビジネスルールを表現するクラスと、ビジネスアクションを表現するクラス。 クラス設計やパッケージ設計の実証済の形を覚えると、出発地点の設計が楽になる。 リファクタリングを積み重ねて設計を改善していく。
このエントリでは、Yegor Bugayenkoによる記事、Getters/Setters. Evil. Period.を紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 2003年にAllen Holubが書いたWhy getter and setter methods are evilという有名な記事に端を発する古い議論がある。それは、getter/setterはアンチパターンで避けるべきものなのか、 もしくはオブジェクト指向プログラミングに必須なものなのかというもの。 この議論に少しだけ私の意見を加えたいと思う。 上記記事の要旨はこうだ。 getterやsetterはひどい慣習で、これらを使うやつらはゆるせん。誤解の無いようもう一度言うが、 私はget
/// <summary>契約金額</summary> public class ContractAmount { public int AmountIncludingTax; public decimal SalesTaxRate; } 当然データの入れ物(以後データクラスと呼称)だけでなく、税込み金額を計算するロジックが必要です。ここであまり設計を考えないと、この手の演算ロジックはデータクラスとは別のクラスに実装されることが多いです。以下のようにControllerに実装されることが多いのではないでしょうか。 /// <summary>契約コントローラー</summary> public class ContractController { private ContractAmount _contractAmount; /// <summary>税込金額を計算する。</summary>
いま Ruby をやってるひとなら、オブジェクト指向設計を学ぶ・復習するのに最適な本だと思う。まさに実践ガイド。一度身につけておくと、言語問わずに使える知識。すぐに仕事に活かせてとても役に立ったと感じた。 こんなひとにおすすめ 自分がそうでしたという意味で。 オブジェクト指向設計はなんとなく知ってるけど実践のイメージが湧いてない オブジェクト指向設計というと継承の親子関係のイメージしか浮かばない 実装をしながら「いいと思って書いてるけど、これは本当にいいのかな…」と迷うことが多い とくに Rails を使っていて設計や実装に迷うことが多い 「Rails における良い設計」の表面的な部分に振り回されている気がする オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方 作者: Sandi Metz,?山泰基出版社/メーカー: 技術評論社発売日: 20
ちまちま読んでたオブジェクト指向入門を読み終わった。だいたい入門と言っているが、原題は"Object-Oriented Software Construction"で入門感はないし、上下巻あわせて2000ページくらいあって読みきるのが大変だった。 原著は18年前に発売された本だが、内容のほとんどは今でも有益で、全体を通してためになる。オブジェクト指向が解決しようとしている課題や、背景にある理論や考え方について解説してくれるだけではなく、実際にソフトウェアを設計する際にどのようにクラスを見つけ、どんな場面で継承を使い、ソフトウェア全体をどのように形作っていくのかという実践的な議論も充実している。 本の序盤では、ソフトウェアの品質の様々な側面についての解説や、オブジェクト指向以前から使われていたモジュールや型の概念のがもつ諸課題について詳しく解説してくれる。それらの問題をふまえ、次に、ソフトウ
Rubyといったオブジェクト指向言語を学ぶと、メソッドの定義方法としてインスタンスメソッドとクラスメソッドという2通りの定義方法があることを学ぶと思います。しかし、言語自体のガイドブックには「定義方法にインスタンスメソッドとクラスメソッドがある」と書いてあるだけで、大抵その使い分けについては書かれていません。 そういう訳で、このエントリではその使い分けについて少し考えてみたいと思います。理論的に厳密な使い分けを目指すというよりは、そもそも使い分けの検討が全くつかない！という方に向けて、その指針の一助となることを目指します。 インスタンスメソッドとクラスメソッドとはそもそものところ、Rubyといった「オブジェクト指向の考え方」を実装した言語の機能です。その機能がなぜあるのか？というそもそものところは、オブジェクト指向の考え方にさかのぼることになります。 そこで、インスタンスメソッドとクラスメ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? irxground 君が再考: GoF デザインパターンといふ記事を書いてゐるので自分もちょっとコメントしてみます。 基本的に irxground 君と同意見のところは省略します。 あと、GoF の本自体は私は読んでゐません。 (GoF のパターン以外のパターンに関する意見の方が長くなってますね……。) GoF のデザインパターン 生成に関するパターン Builder そもそも builder パターンは Java の String と StringBuilder の様に可変オブジェクトと不変オブジェクトを別のクラスに設計しなければなら
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 本投稿は私の主観によって書かれています。コメントは大歓迎です。もし長くなるようでしたら別途記事に投稿し、リンクを張っていただけると嬉しいです。 概要 GoFのデザインパターンは適当すぎるから、いい加減、修正されるべき。 参考までに各パターンに対するコメントを書く。 GoFのデザインパターン GoFのデザインパターンは適当であり、教科書通りに学ぶべきものではないように思う。 以下がGoFのデザインパターンの良くない原因だろう。 本が出版されたのは1994年であり、Java(1995)が出てくるよりも前だった オブジェクト指向が未成熟な時代
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 この記事について この記事は新人向けの研修内容を再編集してお送りいたします。 ここで述べる内容はどのようにして現在のプログラミングスタイルが生まれてきたかを
1. はじめに 皆さん、こんにちは。私はオージス総研でオブジェクト指向技術を用いたSI、コンサルティングを業務とする、プロの仕事を目指す、一介のUMLシルバーレベル1のプログラマ2です。ソフトウェア業界では、オブジェクト指向も、もはや普通の技術として認知されています。有名なマイクロソフトのVB、VC++をはじめ、現在使用している開発環境のほとんどは、すべてオブジェクト指向をサポートしているといってもよいでしょう。オブジェクト指向を知らない人でも、気が付かないうちにオブジェクト指向している、なんてこともあるようです。 でもオブジェクト指向は、単にソフトウェアをより良く作るための手段のひとつですから、上手く利用しないと、そうするつもりはなくても、とんでもないソフトウェアを作ってしまうことになりかねません。悲しいことに、オブジェクト指向は結構敷居が高いと思います。オブジェクト指向のメリットである
6. ドメインモデル • 業務のデータと業務の機能をコードで表現 – ビジネス層に集約する – 関係するデータと機能をクラスにまとめる • ハイブリットなアプローチ – データの視点と機能の視点 • 両方からアプローチする • 二つの視点をいったりきたりする – データと機能の結びつき強める • クラスにカプセル化 • データ保持クラスと機能クラス（データ操作クラス） に分けるのはアンチパターン
methane @methane オブジェクトはクラスじゃないと言われると、クラスオブジェクト作るだけの Python はクラスが無いな/ 最強オブジェクト指向言語 JavaScript 再入門！ on @slideshare #javascript http://t.co/aA53uLvN4k 2013-07-05 12:46:47 methane @methane var Hoge = new Function() を class Hoge: と書いたらほぼ Python. だが obj.meth はメソッドをオブジェクトにバインドするのでその点使いやすい。 2013-07-05 12:48:33
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
前ふりは「型→代数→…それから：型理論入門（の前半）」にあります。これは本編（後半）。1回読み切り（長いけど）で、比較的新しい*1型理論を紹介します。「入門（門に入る）」というよりは門の外から中を覗いてみる程度。 説明用コードはJavaの構文を使います。ただし、パッケージ宣言は書かないし、publicはなるべく省略。 内容： インターフェースなんて、所詮こんなもの 心理的効果とか、人間-人間コミュニケーションとかは、別問題 わけわからんインターフェースに制約を付加する もっと制約を足してみる 謎のインターフェースに意図されたもの で、それが型理論にどうつながるの？ インターフェースなんて、所詮こんなもの まず、次のインターフェースを見てください。 interface AB { int a(); void b(); } これスゴイでしょ。何がスゴイって、これを見てもなんのことやらサッパリわか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
