Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
英語版はこちら。 OOCSSとは異なり、CSSでちゃんとオブジェクト指向を実現するための方法について解説します。 0. まず「オブジェクト指向」とは 「オブジェクト指向」はIT業界を支えている重要なパラダイムのひとつで、JavaScriptを含む様々なプログラミング言語でサポートされています。特徴としては「型」や「クラス」といった雛形を持ち、雛形から生成された「インスタンス」とクラスとを区別します。 クラスとインスタンスとを区別することで、長期的にメンテナンスしやすいプログラムにすることができます。クラスを修正したり、インスタンスに変更を加えたり、それぞれ自由に拡張できます。 こういったオブジェクト指向プログラム言語（OOPL）に共通の特徴は、CSSでは見られることがありませんでした。2008年にOOCSSという手法が登場した後もです。 それも今日でお終いです。さっそく見ていきましょう。
7 Patterns to Refactor Fat ActiveRecord Models という記事があり、読もう読もうと思いつつ1年くらい経ってしまった。 ようやく読んだので理解した内容を書いておく。 コード例は元記事のもの。 Rails で thin controller, fat model を心がけていると、model がマジで激太りしてヤバくなる。 実際に自分が仕事で書いている rails アプリも激太りしててヤバい。 この blog の筆者が作っている CodeClimate で C 判定をもらう程度には肥満体型になっている。 Mixinに抜き出さない! Model が太ってきた時に考えるのは ActiveSupport::Concern を使って感心事を抜き出して、Mixin にすることだと思う。 実際に手元のアプリでも models/concerns/ なんていうディレ
記念すべき「Rails Tips」第1回は、Decorator と Presenter について書きます。 Rails で Decorator/Presenter というと draper や active_decorator などの実績のある有名な gem パッケージが存在していて、それらを導入すれば話は簡単なのですが、本稿ではあえて Rails 標準の機能を用いて Decorator/Presenter を実現する方法を説明します。「車輪の再発明！」と言わないでください。自分で作ってみることによって Ruby や Rails の知識が深まり、様々な応用が利くようになります。実際のところ、そんなに複雑なものではありません。 Decorator とは 「Decorator」はソフトウェアデザインパターンの1つで、継承（inheritance）に代わるクラスの拡張手段です。 具体例で説明しまし
更新情報: 2013/11/19: 初版公開 2021/01/08: 訳文見直し、追記 こんにちは、hachi8833です。今回は、自分が知りたかった、Active Recordモデルのリファクタリングに関する記事を翻訳いたしました。1年前の記事なのでRails 3が前提ですが、Rails 4以降でも基本的には変わらないと思います。リンクは可能なものについては日本語のものに置き換えています。 なお、ここでご紹介したオブジェクトは、app以下にそれぞれ以下のようにフォルダを追加してそこに配置します。 注記: 以下は使われそうなフォルダを列挙しただけであり、実際にはこの一部しか使いません。 Value Object Service Object Form Object Query Object View Object Policy Object Decorator ⚓ 肥大化したActive
In this guide, you will learn how controllers work and how they fit into the request cycle in your application. After reading this guide, you will know how to: Follow the flow of a request through a controller. Access parameters passed to your controller. Use Strong Parameters and permit values. Store data in the cookie, the session, and the flash. Work with action callbacks to execute code during
Java/Spring Boot/MyBatis/Thymeleafを使った、ドメイン駆動設計のサンプルコード。ビジネスルールに焦点を合わせ、計算モデルで複雑さを整理し、型指向のプログラミングで実装する、その具体例。
この記事はRuby on Rails Advent Calendar 2013の6日目の記事です。 前日は @tkawa さんの「Favoriteの設計実装はパターンとして使える」でした。 Railsで適切に責務を分割するということ RailsはいわゆるMVCと呼ばれるアーキテクチャパターンにのっとったフレームワークであり、プロジェクトを作成するとデフォルトでmodels/、views/、controllers/などのディレクトリが作成されます。 基本的にロジックを記述する場所はモデルであり、ビューには表示処理だけを、コントローラにはアプリケーション上必要な手続きだけを記述するべきであると一般的には言われています。*1 ただ、それを忠実に実践していった結果、モデルが肥大化しメンテナンシビリティやテスタビリティが低下するという問題も多く指摘されています。 これについては4日目に @joker
ちょっと煽り気味のタイトルにしてみましたが、Railsで開発する時は意識的にOOPに寄せないとオブジェクトの力が活かせなくなるよってことと、Railsが提供しているクラスの責務を分割することを支援してくれる機能について話をします。 ActiveRecordの性質 Rails開発においては、モデル層にロジックを書いてコントローラーは薄くしろ、というのはしつこく言われているので、概ね浸透してきていると思います。 それに加えて、最近私が結構しつこく主張しておきたいのが、モデル = ActiveRecordでは無いよ、ということです。 ActiveRecordは成り立ちから言うと、ロジックとDBへの永続化をまとめてカプセル化するアーキテクチャパターンから来ています。(詳しくはエンタープライズアプリケーションアーキテクチャパターンという書籍を読むと良いです) この方法はロジックが複雑でない場合、つま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
