"결합 된 Getter / Setter VS 개별 방법의 장점은 무엇입니까?


12

이것이 내가 "결합 된"getter / setter 메소드 (jQuery)라고 부르는 것입니다.

var foo = $("<div>This is my HTML</div>"),
    myText;

myText = foo.text(); // myHTML now equals "This is my HTML" (Getter)
foo.text("This is a new value"); // The text now equals "This is a new value")

이것은 별도의 (이론적) 방법과 동일한 논리입니다.

var foo = $("<div>This is my HTML</div>"),
    myText;

myText = foo.getText(); // myHTML now equals "This is my HTML" (Getter)
foo.setText("This is a new value"); // The text now equals "This is a new value")

내 질문:

jQuery와 같은 라이브러리를 설계 할 때 왜 두 번째 경로가 아닌 첫 번째 경로를 선택하겠습니까? 두 번째 접근 방식이 한 눈에 명확하고 이해하기 쉽지 않습니까?


6
Martin Fowler는 그가 "오버로드 게터 세터"라고하는 팬이 아닙니다 : martinfowler.com/bliki/OverloadedGetterSetter.html
vaughandroid

1
나는 get / set split 메소드를 좋아했지만 (코드가 더 "명백한"것이라고 생각했지만) 오버로드 된 getter / setter 패턴이 요즘 더 매력적이라고 ​​생각한다. 코드를 더 깨끗하게 만들 수 있습니다. 파울러 씨의 타협을 좋아하는 사람은 없었습니다. 그것은 두 세계에서 최악 인 것 같습니다.
Brian Knoblauch

Martin Fowler의 유일한 주장은 'getter'가 인수를 전달할 때입니다.이 경우 getter처럼 보이지 않기 때문에 독자에게 혼란을줍니다. 지금까지 getter가 인수를 취하지 않고 setter가 명확한 API 주석과 함께 jQuery / Angular 접근 방식을 사용한다는 규칙을 고수한다면 결론을 내릴 수 있습니다. 지금은
zumalifeguard

답변:


13

순전히 여기에서 추측하지만 jQuery를 구성하는 데 많은 기능적 스타일을 사용한 jQuery 개발자는 분명히 기능 패러다임에 기울고 있다고 생각하는 경향이 있습니다.

기능 패러다임에는 중복성을 줄이는 강력한 문화가 있으며, 두 번째 접근 방식에는 불필요한 중복성이 있다고 주장 할 수 있습니다. 첫 번째 접근 방식은 모든 공통 명령 언어에 익숙한 사람에게는 분명하지 않지만 두 가지 방법 대신 하나의 방법 만 사용하면 더 적은 비용으로 더 많은 일을 할 수 있습니다. 이것은 위험 할 수 있지만 기능적 패러다임의 일반적인 도구이며 빠르게 익숙해집니다.

기능적 패러다임에서 연습하면 의식에 대한 욕구를 빨리 극복하고 더 적은 비용으로 더 많은 것을 할 수있는 능력을 높이는 법을 배우십시오. 비록 이것이 많은 사람들이 공백 관리에 관한 선호를 갖는 것과 같은 방식으로 선호를 기반으로하는 주관적인 선택이지만, 이것은 명백하게 주관적인 선택입니다. 이 방법으로 나는 한 가지 방법이 더 좋다고 말하는 것이 아니라 사람들이 익숙해 져서 jQuery가 접근하는 이유 일 것입니다.

이것이 jQuery 개발자가 이것을했다고 믿는 이유이며 일반적으로 누군가 가이 접근법을 취할 수있는 이유입니다.


2
또한 JS 크기를 가능한 한 줄이려고합니다.
매트 S

명령형 / 장황 형 및 기능적 / 암시 적 포인트의 경우 -1입니다.

3
@MattFenwick 불쾌감을 의미하는 것은 아닙니다. 기능적 패러다임이 명령형 패러다임이 명시성에 기대어있는 암시성을 향하고 있다는 것이 사실이 아닙니까? 나는 하나가 (이 똑같이 어느 쪽이든 간다) 다른 반대로 자동 그런 식으로 일을하는 원인이되는 하나 또는 다른 익숙해 질 수 있습니다 단지, 하나 더 말하고 있지 않다
지미 호파

@Jimmy 문제 없습니다; 내 요점은 내 경험상 암시 적 / 명백 함이 FP / 제국에 직교하는 것으로 나타났습니다.

@MattFenwick이 될 수는 있지만, 많은 암시성을 허용하고 HM 유형 시스템에 공통적 인 유형 유추를 제외하고는 FP 언어에 공통적 인 다른 것뿐만 아니라 모든 연산자 기능과 마찬가지로 암시성을 지향합니다. 함수에는 명시적인 이름이 없으며 암시 적으로 배우고 암시해야 할 기호 또는 DU 대신 구성원 의미 및 위치에 대한 암시 적 지식이 필요한 목록 또는 튜플의 일반적인 사용 (작성기 모나드의 작동 방식에 대한 생각)이 없습니다. 나는 또한 단일 문자 매개 변수 이름의 공통성을 보는 경향이 있지만, 당신이 옳을 수도 있습니다
Jimmy Hoffa

2

형태

foo.text("This is a new value"); 

여러 가지를 암시 할 수 있습니다. 가장 일반적으로 문자열 수락 foo이라는 메서드를 사용하여 무언가text수행 하는 객체를 제안합니다 . 이것이 속성이라는 의미는 없습니다.

많은 언어에서 이것은 약식 형식으로 간주 될 수 있습니다.

var result = foo.text("This is a new value"); 

결과가 버려지는 곳. 따라서이 방법은 코드 판독성 관점에서 속성을 설정하는 효과적인 방법이 되기에는 너무 모호합니다.


이것은 훌륭한 포인트입니다! Javascript를 읽을 때 FP 고글을 착용했는데 상황이 다르게 보이므로 이것에 대해 생각조차하지 않았지만 C #에서 이와 같은 코드를 보았을 때 "Wth이 방법은 무엇을합니까? ?? ".
Jimmy Hoffa

1

약간 투기 적이지만 여기에 내 기회가 있습니다.

jQuery는 자바 스크립트의 기능적 특성을 완전히 수용합니다. 그것이 그렇게 훌륭하게 만드는 이유이지만, 자바와 같은 순수한 OO 언어에서 왔을 때 많은 개발자가 머리를 긁을 수 있습니다. 모든 관습과 좋은 연습을 어기는 것 같습니다.

기능적 언어는 선언적 구문에 중점을 두는 경향이 있습니다. 같은 명령보다는 사실에 대한 진술을 읽는 경향이 있습니다. 예

var eligible = customers.where(c => c.age > 30);

"적격 고객은 30 세 이상인 고객"으로 읽을 수 있습니다. 대조적으로 명령형 언어는 일련의 명령처럼 읽습니다.

for (customer in customers)
    if (customer.age > 30)
        eligible.add(customer)

"각 고객을 확인하고 30 세 이상인 경우 해당 컬렉션에 추가하십시오"라고 읽을 수 있습니다.

aa setget연산을 추가하면 jQuery가 명령형 라이브러리처럼 느껴집니다. 다음 진술을 읽는 방법을 혼동 할 수 있습니다

// The element tag have an html of <p>hello</p>
$("#element").html("<p>hello</p>"); 

// content represent the html of the element tag
var content = $("#element").html();


//Imperative style

// Set the element tag to an inner html of <p>hello</p>
$("#element").setHtml("<p>hello</p>");

//Get the html of #element, and put it in the content variable
var content = $("#element").getHtml();

jQuery API에서 동작 동사를 유지함으로써 선언적 API처럼 느껴졌습니다. 라이브러리에 일관되고 기능적인 느낌을줍니다. 그래서 키워드에 과부하가 걸린 것 같습니다.


1

그것은 최근에 JavaScript에 도입 된 properties 와 비슷하게 동작하게 하므로 브라우저 비 호환성을 추상화하는 jQuery와 같은 라이브러리에서는 아직 널리 사용되지 않습니다.

이러한 속성으로 가득 찬 클래스 정의를 본 적이 있다면 value 매개 변수를 추가하면 이미 setter라는 것을 알려주기 때문에 "set"및 "get"접두사가 불필요하게 보입니다. Martin Fowler 는 매개 변수가 필요한 게터에 대해 좋은 지적을하지만, 그런 맥락에서 추가 값 매개 변수는 세터를 명확하게 나타내며 세터가 과제의 오른쪽에 거의 나타나지 않는다는 사실을 나타냅니다. 그리고 코드를 작성할 때는 어쨌든 라이브러리의 설명서를 봐야합니다.

장점 만 요청 했으므로 단점을 다루지 않습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.