루비 소프트웨어 개발: Bang 메서드 및 생성 방법

우리는 종종 뱅 방법이 어떤 의미에서 위험한 방법이며 정의 끝에 느낌표는이 방법을 사용할 때 조심해야한다는 진술을 접할 수 있습니다. 이러한 방법과 관련하여 이러한 위협은 정확히 무엇이며 그 특징은 무엇인지 살펴 보겠습니다.

뱅 방법의 특징

1. 뱅 메서드는 수신자를 변경합니다.

이러한 유형의 방법의 가장 인기 있는 특징 중 하나는 일반적으로 대상을 변경한다는 것입니다. map! 메서드를 예로 들어 보겠습니다. 문서에 따르면 map! 메서드는 self의 각 요소에 대해 주어진 블록을 한 번씩 호출하여 요소를 블록이 반환한 값으로 대체하고, 블록이 지정되지 않은 경우 열거자가 대신 반환됩니다.

 arry = [1, 2, 3, 4, 5]
 arry.object_id => 280
 arry.map! {|num| num**num } => [1, 4, 27, 256, 3125]
 arry.map!                       => # [1, 4, 27, 256, 3125]
 arry.object_id => 280

보시다시피 object_id는 변경되지 않습니다. 따라서 이러한 메서드 사용의 위험성은 분명해 보입니다. 만약 우리의 코드 변수를 다른 곳에서 사용하면 맵! 이로 인해 프로그램이 바람직하지 않은 방식으로 작동하거나 심지어 충돌이 발생할 수도 있습니다.

에 개체가 있습니다. Ruby 정수, 플로트 및 심볼 클래스의 인스턴스와 같이 변경할 수 없는 인스턴스입니다. 작업하는 동안 프로젝트를 클릭하면 다음과 같은 마법의 댓글을 만날 수도 있습니다:

냉동 문자열문자: true

이러한 주석이 사용된 코드에서 문자열 수신자를 변경하려고 시도하면 다음과 같은 오류가 발생합니다:

 'abc'.upcase!
 FrozenError(고정된 문자열을 수정할 수 없음)

흥미로운 점은 변경 불가능한 문자열을 Ruby 3.0하지만 변경하지 않기로 결정했습니다.. 그러나 모든 강타 방법이 수신자를 변경하는 것은 아니므로 특정 방법의 경우 어떤 종류의 위험을 예상해야 하는지 항상 문서에서 확인해야 합니다.

2. 뱅 메서드는 예외를 발생시킵니다.

이러한 메서드의 또 다른 특징은 대부분의 경우 예외가 발생한다는 것입니다. 이러한 메서드의 예로는 ActiveRecord::FinderMethods#first! 문서에 따르면 first! 메서드는 첫 번째 메서드와 동일하지만 레코드를 찾을 수 없는 경우 ActiveRecord::RecordNotFound를 발생시킵니다. first! 메서드는 인수를 받지 않는다는 점에 유의하세요.

파일 activerecord/lib/activerecord/relation/findermethods.rb, 128줄

def first!
first || raiserecordnotfoundexception!
end

그러나 위에 사용된 ActiveRecord::FinderMethods#first 메서드는 다음과 같이 보입니다:

파일 activerecord/lib/activerecord/relation/findermethods.rb, 116줄

def first(limit = nil)
로드되지 않으면 재순서를 확인하나요?

if limit
findnthwithlimit(0, limit)
else
findnth 0
end
end

위의 예제를 통해 전자를 사용할 때의 위험성을 알 수 있습니다. ActiveRecord::FinderMethods#find! 를 사용했는데 데이터베이스에서 적합한 레코드를 찾지 못하면 ActiveRecord::RecordNotFound가 반환되어 프로그램이 작동을 멈출 수 있습니다.

그러나 메서드 끝에 느낌표가 없다고 해서 안전하며 예외가 발생하거나 수신자가 변경되지 않는다는 의미는 아니라는 점을 기억해야 합니다.

Ruby on Rails 6.0에 새로운 메서드 쌍이 도입되었습니다: ActiveRecord::지속성::클래스 메서드#insert_all 그리고 ActiveRecord::Persistence::ClassMethods#insert_all!

이 방법 중 첫 번째 방법은 이미 어느 정도의 위험을 보여줍니다. 문서에 따르면는 모두 단일 SQL INSERT 문으로 데이터베이스에 여러 레코드를 삽입합니다. 이 문은 모델을 인스턴스화하지 않으며 ActiveRecord 콜백이나 유효성 검사를 트리거하지도 않습니다. 그러나 삽입모두! 는 테이블의 고유 인덱스를 위반하는 행이 있는 경우 추가로 ActiveRecord::RecordNotUnique를 발생시킵니다. 이 경우 행이 삽입되지 않습니다. 즉, 첫 번째 메서드는 고유 인덱스를 위반하는 레코드를 제외한 모든 레코드를 저장하는 반면 두 번째(더 위험한) 메서드는 예외를 발생시키고 데이터베이스에 어떤 레코드도 저장하지 않습니다.

3. 뱅 방식은 느낌표가 없는 것과 동일합니다.

많은 메서드는 끝에 느낌표가 없더라도 사용하기에 위험합니다. 예를 들어, ActiveRecord::FinderMethods#find. 문서에 따르면 요청된 ID에 대해 하나 이상의 레코드를 찾을 수 없는 경우 ActiveRecord::RecordNotFound가 발생합니다.

이 메서드는 ActiveRecord::FinderMethods#first!와 위험도가 동일하지만 느낌표가 없다는 것을 알 수 있습니다.

수신자를 수정할 때도 마찬가지입니다. 예를 들어 문서에 설명된 대로 Array.delete는 객체와 동일한 모든 항목을 자체에서 삭제하고 마지막으로 삭제된 항목을 반환하거나 일치하는 항목을 찾을 수 없는 경우 nil을 반환합니다.

 a = [1, 2, 3, 4, 5]
 a.object_id #=> 320
 a.delete(2) #=> 2
 a #=> [1, 3, 4, 5]
 a.delete(6) #=> nil
 a.object_id #=> 320

객체가 수정되었음을 명확하게 알 수 있습니다. 두 메서드의 공통점은 느낌표에 해당하는 것이 없다는 것입니다. 따라서 우리가 만들고자 하는 메서드에 위에서 언급한 종류의 위험성이 있는 경우 끝에 느낌표를 바로 넣을 필요는 없습니다. 또한 만들고자 하는 메소드보다 덜 위험한 같은 이름의 메소드가 이미 있는 경우 강타 메소드를 만드는 것이 좋습니다.

뱅 메서드를 사용해야 하는 경우

일반적으로 덜 위험한 방법이 있는데 왜 굳이 이런 위험한 방법을 사용해야 하는지 의아해할 수 있습니다. 장점 중 하나는 예를 들어 생성되는 객체 수를 줄여 코드 성능을 개선할 수 있다는 점입니다. 여기에서 Rails 성능 향상에 대한 자세한 내용을 확인할 수 있습니다..

예외를 발생시킬 때 위험한 create! 대신 create 메서드를 사용하면 레코드가 데이터베이스에 기록되지 않기 때문에 애플리케이션에서 오류를 감지하기 어려운 상황이 발생할 수 있습니다. 따라서 이 메서드에 전달한 매개변수가 올바른지 확인했다면 어떤 이유로 레코드가 데이터베이스에 저장되지 않는 경우 예외를 발생시키는 create! 메서드를 사용해야 합니다.

결론은 간단합니다. 이러한 방법을 신중하게 사용하면 코드의 성능과 품질을 향상시킬 수 있다는 것입니다. 그러나 부적절하게 사용하면 코드가 제대로 실행되지 않을 수 있다는 점을 항상 기억해야 합니다.

나만의 뱅 메서드를 만들어야 할 때

자신만의 위험한 메소드를 만들려면 일정한 의사 결정 과정을 거쳐야 합니다. 먼저, 만들고자 하는 메서드와 이름은 같지만 덜 위험한 메서드가 이미 존재하는지 확인해야 합니다. 한 메소드가 다른 메소드와 동등하지만 더 위험한 한 쌍의 메소드를 만드는 것도 고려할 수 있습니다.

느낌표가 없는 메서드가 존재하지 않는다면 뱅 메서드를 만들 필요가 없습니다. 객체를 변경하거나 예외를 발생시키기 때문에 위험하지만 이름 끝에 느낌표가 없는 메서드가 있습니다. 동등한 메서드가 없는 뱅 메서드를 만들면 코드를 사용하는 프로그래머에게 혼란을 줄 수 있습니다. 이 사람은 이 메서드의 위험성이 무엇인지, 왜 이름 끝에 느낌표가 있어야 하는지 설명할 수 없을 것입니다.

둘째, 어떤 종류의 위험에 대해 이야기하고 있는지 고려해야 합니다. 위의 예시를 통해 가장 일반적인 유형의 위험은 객체 자체를 변경하거나(복사본을 만드는 대신) 예외를 발생시키는 것이라고 결론을 내릴 수 있습니다. 물론 이것은 규칙이 아니라 Ruby와 Ruby on Rails에 정의된 메서드를 분석한 결과입니다. 예를 들어, 메서드 쌍의 구현을 고려할 수 있습니다. 느낌표 를 사용하면 데이터베이스에 레코드가 저장되는 반면 느낌표가 있는 메서드는 이 레코드의 유효성 검사를 건너뜁니다. 이 경우 이러한 메서드 사용의 잠재적 위험이 어디에 있는지 명확하게 알 수 있습니다.

요약

뱅 메서드에 대한 지식을 요약하면 다음과 같은 결론이 나옵니다. 느낌표가 있는 첫 번째 메서드는 다음과 같습니다. 덜 위협적 대응하는 메서드가 느낌표가 없는 경우, 둘째, 느낌표가 있는 메서드가 수신자를 수정하거나 예외를 발생시키는 등 위험한 작업을 수행하는 경우입니다.

결론적으로, 다음과 같은 개념을 이해하면 뱅 메소드 in Ruby 소프트웨어 개발 를 사용하면 코딩 기술을 크게 향상시키고 코드베이스를 더욱 명확하게 만들 수 있습니다. 뱅 방법이름 끝에 느낌표로 표시된 것은 파괴적이거나 잠재적으로 위험한 메서드임을 나타냅니다. 관례에 따라 뱅 카운터파트 메서드는 별도의 복사본을 만들지 않고 직접 객체를 수정할 수 있으므로 주의해서 사용해야 합니다. 변경 가능한 객체를 다루거나 성능 최적화가 중요한 경우 특히 유용할 수 있습니다. 하지만 제대로 처리하지 않으면 의도하지 않은 결과를 초래할 수 있으므로 뱅 메서드를 사용할 때는 주의를 기울이는 것이 중요합니다. 또한 모든 메서드에 뱅 버전의 존재 여부는 사례별로 평가해야 합니다. 뱅 메서드를 언제, 어떻게 만들어야 하는지에 대한 지식이 있다면 이 강력한 도구를 효과적으로 활용하여 특정 요구 사항을 충족하는 깔끔하고 효율적인 코드를 작성할 수 있습니다.