Ruby on Rails를 사용한 적이 있다면 관심사라는 개념을 만날 수 있습니다.새로운 Rails 프로젝트를 시작할 때마다 디렉터리app/controllers/concerns 및 app/models/concerns가 제공됩니다.그런데 사람들이 뭘 걱정하지?왜 Rails 커뮤니티 사람들은 때때로 그들의 험담을 합니까?

빠른 개요

Rails는 확장ActiveSupport::Concern 모듈의 모든 모듈을 주목합니다.그대
물어보실 수도 있어요. - 관심사가 모듈과 뭐가 달라요?주요 차이점은 다음과 같은 몇 가지 마술을 수행할 수 있는 Rails 시점입니다.

# app/models/concerns/trashable.rb

module Trashable
  extend ActiveSupport::Concern

  included do
    scope :existing, -> { where(trashed: false) }
    scope :trashed, -> { where(trashed: true) }
  end

  def trash
    update_attribute :trashed, true
  end
end

이 단어가 안에 포함되어 있는 것을 봐라.Ruby 모듈에 뿌리는 Rails 탄수화물입니다.ActiveSupport::Concern 계산할 코드를 포함하는 블록에 넣을 수 있도록 합니다.예를 들어 모델에서 쓰레기 논리를 추출하기를 원합니다.included Dell이 수행하는 작업을 완료하고 모델에 대한 질문을 포함할 수 있습니다.

class Song < ApplicationRecord
  include Trashable

  has_many :authors

  # ...
end

이 점에서 매우 편리하고 천진하다, 그렇지?모형이 약간의 무게를 줄였다
쓰레기는 현재 우리의 노래 모델만이 아니라 다른 모델에서 다시 사용할 수 있다.
응, 일이 복잡해질 수도 있어.우리 깊이 이해합시다.

Mixin의 대표적인 예

우리가 이 문제들을 더욱 깊이 토론하기 전에, 우리는 그것에 대해 또 다른 해석을 진행할 것이다.include SomeModule 또는 extend AnotherModule 을 보면 mixins 라고 합니다.
mixin은 다른 종류에 추가할 수 있는 코드입니다.우리가 Ruby documentation 에서 알고 있는 바와 같이 하나의 모듈은
방법과 상량의 집합.따라서 우리가 여기서 하는 일은 방법과 상량을 가진 모듈을 서로 다른 종류에 포함시켜 사용할 수 있도록 하는 것이다.
이것이 바로 우리가 Trashable 문제에 대해 한 것이다.우리는 모델 대상을 모듈로 끌어당기는 흔한 논리를 추출했다.이 모듈은 나중에 에 포함될 수 있습니다.
다른 곳.따라서 mixin은 루비와 레일스뿐만 아니라 디자인 모델이다.그러나 어디에서 사용하든지 사람들은 그것을 좋아하거나 좋다고 생각하거나 싫어한다
그리고 통제력을 잃기 쉽다고 생각한다.
이 점을 더욱 잘 이해하기 위해서, 우리는 그것들을 사용하는 몇 가지 장단점을 토론할 것이다.이렇게 함으로써 우리는 언제 관심사를 사용할지 알 수 있기를 바란다.

나 다 있어.

예를 들어 Trashable 관심사를 추출하기로 결정했을 때, Trashable 을 포함하는 모든 기능에 접근할 수 있습니다.이것
강력한 힘을 가져왔지만 리처드 슈니만(Richard Schneeman)이 his blog post의 주제에서 말한 것처럼 "강력한 힘은 복잡한 코드를 만드는 강력한 능력을 가져왔다."그가 가리키는 것은 네가 의존할 수 있는 코드를 복잡하게 하는 것이다. 이것이 바로
너의 걱정 속에 있어야 한다.
만약 우리가 다시 한 번 보게 된다면Trashable:

module Trashable
  extend ActiveSupport::Concern

  included do
    scope :existing, -> { where(trashed: false) }
    scope :trashed, -> { where(trashed: true) }
  end

  def trash
    update_attribute :trashed, true
  end
end

관심사의 논리는 trashed 필드가 관심사가 있는 위치에 존재하는 것에 달려 있다.정당하다별거 아니야, 이게 우리가 원하는 거야.
전부그러나 내가 본 상황은 사람들이 모델에서 다른 내용을 도입하기 쉽다는 것이다.이러한 상황이 어떻게 발생했는지 설명하기 위해 우리는 Song 모델에 또 다른 방법이 있다고 가정한다featured_authors.

class Song < ApplicationRecord
  include Trashable

  has_many :authors

  def featured_authors
    authors.where(featured: true)
  end

  # ...
end

class Album < ApplicationRecord
  include Trashable

  has_many :authors

  def featured_authors
    authors.where(featured: true)
  end

  # ...
end

더 잘 설명하기 위해서, 나는 Album 모델을 추가했는데, 그중에도 Trashable 모델이 포함되었다.
만약 우리가 노래와 앨범의 클로즈업 작가에게 그들이 버려질 때 통지하고 싶다고 가정하자.사람들은 이런 논리를 걱정하는 경향이 있다. 예를 들어

module Trashable
  extend ActiveSupport::Concern

  included do
    scope :existing, -> { where(trashed: false) }
    scope :trashed, -> { where(trashed: true) }
  end

  def trash
    update_attribute :trashed, true

    notify(featured_authors)
  end

  def notify(authors)
    # ...
  end
end

바로 이곳에서 일이 좀 복잡해지기 시작했다.우리는 노래 모델 외에 쓰레기 논리가 있기 때문에, notifying을 Trashable 관심사에 놓을 수 있다.그곳에서 약간의 오류가 발생했다.featured_authors모델에서 추출.예, 요청 검토 및 CI 검토를 통과했다고 가정하십시오.
그리고 다음 몇 달 동안 새로운 요구가 설정되었다. 개발자는 우리가 노래를 보여주는 방식을 바꿔야 한다Song.예를 들어 새로운 요구는 유럽에서 온 클로즈업 작가만 표시하는 것이다.물론 개발자는 특색 있는 작가의 정의를 찾아 편집할 수 있다.

class Song < ApplicationRecord
  include Trashable

  has_many :authors

  def featured_authors
    authors.where(featured: true).where(region: 'Europe')
  end

  # ...
end

class Album < ApplicationRecord
  include Trashable

  has_many :authors

  # ...
end

이것은 우리가 작가에게 보여준 어느 곳에서든 잘 일할 수 있지만, 우리가 생산 환경에 배치된 후에
세계 다른 곳에서 오신 분들은 더 이상 받지 않을 거예요.
그들의 노래.관심사를 사용할 때 이런 실수를 범하기 쉽다.이것
위의 예는 간단하고 인위적인 예이지만, 이러한 예들은'재
야외는 매우 까다로울 수 있다.
이곳의 위험은 관심점(mixin)이 얻은 모델에 대해 많이 알고 있다는 데 있다
에 포함됩니다.이른바 순환 의존이다.featured_authors 및 SongAlbum에 의존하여 쓰레기 처리, Trashable에 의존하여 쓰레기 처리Trashable 정의.featured_authors 필드의 경우
두 모델 모두 trashed 관심사가 있어야 작동할 수 있다.
이것이 바로 왜 무관심 클럽이 반대할 수도 있고 직업이 걱정할 수도 있는가 하는 것이다
클럽내가 말하고자 하는 것은, Trashable의 첫 번째 버전은 내가 갈 것이다
내 코드 라이브러리에 있습니다.어떻게 쓰는지 보여드릴게요.
더 잘 통지하다.

어디서 오셨어요?

Notify를 통해 무엇을 해야 하는지 살펴보십시오.
관심사를 사용할 때 발생하는 또 다른 일은 우리가 지나치게 건조한 경향이 있다는 것이다.
프레젠테이션의 목적을 위해 우리는 창설을 통해
다른 질문(참고):

module Authorable
  has_many :authors

  def featured_authors
    authors.where(featured: true)
  end
end

그리고 우리의 Trashable 및 Trashable 은 다음과 같습니다.

class Song < ApplicationRecord
  include Trashable
  include Authorable

  # ...
end

class Album < ApplicationRecord
  include Trashable
  include Authorable

  # ...
end

우리는 모든 것을 말렸지만, 지금은 클로즈업 작가에 대한 요구가 있다
유럽은 실현되지 않았다.더 심각한 것은 현재Song의 관심과
모델은 Album에 따라 달라집니다.내가 졸라갈까?제 질문은 언제죠?
얼마 전에 나는 약간의 걱정을 처리하고 있었다.어디 있는지 찾기 힘들어요.
방법
내가 이 모든 문제를 해결하는 방법은 Trashable 가능한 한 접근하는 것이다
모형.Authorable 방법은 featured_authors의 일부분이어서는 안 된다
전혀 걱정하지 않는다.각 모델은 특히 다음과 같은 상황에서 자체적으로 처리해야 합니다.
그들은 서로 다른 그룹에 통지하는 경향이 있다.고통을 줄이는 방법을 살펴보자.

# Concerns
module Trashable
  extend ActiveSupport::Concern

  included do
    scope :existing, -> { where(trashed: false) }
    scope :trashed, -> { where(trashed: true) }
  end

  def trash
    update_attribute :trashed, true
  end
end

module Authorable
  has_many :authors

  # Other useful methods that relate to authors across models.
  # If there are none, ditch the concern.
end

# Models
class Song < ApplicationRecord
  include Trashable
  include Authorable

  def featured_authors
    authors.where(featured: true).where(region: 'Europe')
  end

  # ...
end

class Album < ApplicationRecord
  include Trashable
  include Authorable

  def featured_authors
    authors.where(featured: true)
  end

  # ...
end

이런 걱정은 통제할 수도 있고 복잡하지도 않다.넘어갈게요 notify내가 전에 묘사한 기능은 다른 날의 주제일 수도 있기 때문이다.

최종 사장

Basecamp, Rails의 창립자에게 있어서 다른 관심사를 인용하는 것은 일종의 우려인 것 같다
아주 좋다
얼마 전:

코드 캡처를 보거나
경외하거나 놀라다.나는 이곳에 중간자가 없다고 생각한다.하면, 만약, 만약...
이 코드를 나는 그것을'마지막 사장 대전'이라고 상상할 것이다.하지만 농담
그 외에 재미있는 것은 여기에 어떤 문제를 지적한 평론이 있다
어느 것에 달려 있느냐.다음을 참조하십시오.

  # ...

  include Subscribable # Depends on Readable
  include Eventable    # Depends on Recordables

  # ...

이런 평론은 도움이 될 수 있지만, 그것은 여전히 이렇게 할 수 있다
특히 당신이 새로운 코드 라이브러리라면, 대략적인 것들.새것
코드 속의 모든 함정이 틀림없이 너를 실망시킬 것이라는 것을 깨닫다
나선형 하강에 주목하다.
여기 DH가 있어요.
.
내부의 답장 트윗은 이 코드 라이브러리를 사용하는 사람들이 어떻게 일해야 하는지 물었다
이 문제들과 상호작용하다.DHH는 별로 없다고 대답했어요.
그들은 서면 문서를 거의 고용하지 않기 때문에 그들의 팀은 이 문서들을 매우 잘 안다.
그런데 코드 라이브러리에 익숙한 경험이 풍부한 팀이 있어요.
그것들을 사용하는 것은 이상하고 튼튼하지 않다.이게 더 느낌인 것 같아요.
사용 여부.모듈화된 여러 계승에 만족하십니까?
제공, 아니면 당신은 구도를 더 좋아합니까?니 전화.

결론

우리가 본 바와 같이, 관심점은 단지 유용한 문법을 제공하는 모듈에 불과하다
설탕은 당신의 코드를 추출하고 건조합니다.하면, 만약, 만약...
belt, 아마도 너는 즉시 관심을 가져서는 안 될 것이다.행동이 유사하다
파일 첨부 파일과 예시에서 보여준 쓰레기 논리 처리
추출 모듈(주목점)에 좋은 사람일 수도 있습니다.
문제를 처리할 때 가능한 좋은 일과 나쁜 일을 볼 수 있기를 바란다
일반 관심사와 모듈.완벽한 코드가 없다는 것을 명심하세요.그리고
마지막으로, 너에게 좋은 것이 무엇인지, 너에게 나쁜 것이 무엇인지 모르면, 너는 어떻게 알겠니
시도하면 실패하거나 성공할 수 있습니까?
완벽한 솔루션이 없으므로 Rails 방식을 이해하시기 바랍니다.
블로그 게시물에서 일을 하다.예전과 같이 당신의 판단력을 활용하여 깨닫다
이해득실
다음까지 건배!
P, 루비 매직의 게시물이 출판된 후 바로 읽고 싶다면subscribe to our Ruby Magic newsletter and never miss a single post!
Nikola는 엔지니어와 작가로 노비사드에서 생활하고 일하며 블로그와 대화를 통해 사람들에게 지식을 전파한다.그는 자바스크립트와 루비로 훌륭한 것을 구축하는 것을 좋아한다.