최근에 특정 프로젝트의 특정 클래스에 대해 체인 방법을 구현하여 코드의 가독성을 향상시킬 수 있다고 제안했습니다. 나는 "편의를 위해서가 아니라 의미론을 위해 유창한 인터페이스를 구현해야한다"라는 대답을 얻었고 제 제안은 거절되었습니다. 나는 유창한 인터페이스를 제안하는 것이 아니라 가독성과 코딩 편의성을 향상시키기 위해 메서드 체인 자체 ( 서로 혼란 스러울 수 있음) 에 대답했다 .

어쨌든, 이것은 아마도 아무것도 반환하지 않는 메소드 (예 : setter)에서 항상 "this"를 반환함으로써 나쁜 습관을 겪을 수 있다고 생각하게했습니다.

내 질문은 : 이전 관습을 적용하는 것이 나쁜 습관이나 학대로 간주 될 수 있습니까?, 왜?. 성능 저하가 있다고 생각하지 않습니까?

아니

로 켄트 벡이 지적, 코드는 훨씬 더 자주 기록보다 읽습니다.

메소드 체인으로 코드를 더 읽기 쉽게하려면 메소드 체인을 사용하십시오.

예, 단점이 있습니다

읽기 쉬운 코드는 좋지만 코드가 통신 하는 내용도주의하십시오 . 객체의 메소드가 항상 객체를 반환하면 몇 가지 사항을 전달합니다.

1. 어떤 순서로 설정하거나 구성해야하는지 확실하지 않은 고급 구성이 필요합니다.
2. 각 후속 메소드 호출은 마지막에 빌드됩니다.

유효한 사용 사례 : Ad Hoc 데이터베이스 쿼리

클래스 라이브러리는 대부분의 모든 언어로 존재하므로 하드 코딩 된 SQL에 의존하지 않고 데이터베이스를 쿼리 할 수 ​​있습니다. Entity Framework for .NET을 예로 들어 보겠습니다.

DBContext db = new DBContext();
List<Post> posts = db.Posts
    .Where(post => post.Title.Contains("Test"))
    .OrderBy(post => post.DateCreated)
    .ToList();

이것은 각 후속 메소드 호출이 이전 메소드 호출을 빌드하는 유연한 인터페이스입니다. 이러한 호출을 읽는 것은 데이터베이스 쿼리 컨텍스트에서 논리적으로 의미가 있습니다.

잘못된 사용 사례 : 속성 설정을위한 구문 설탕

이제 Post클래스 와 동일한 패턴을 사용합시다 :

public class Post
{
    public string Title { get; set; }
    public DateTime DateCreated { get; set; }
    public string Body { get; set; }

    public Post SetTitle(string title)
    {
        Title = title;

        return this;
    }

    public Post SetDateCreated(DateTime created)
    {
        DateCreated = created;

        return this;
    }

    public Post SetBody(string body)
    {
        Body = body;

        return this;
    }
}

이제이 클래스를 어떻게 사용할지 봅시다 :

Post post = new Post()
    .SetTitle("Test")
    .SetDateCreated(DateTime.Now)
    .SetBody("Just a test");

이 코드가 표시되면 즉시 다음과 같은 질문을합니다. "호출 한 후 SetBody데이터베이스를 쿼리합니까? '완료되었습니다'라는 다른 방법을 호출해야합니까?"

체인 메소드 호출 은 클래스를 사용하여 코드와 통신 하는 것은 무엇입니까 Post?

1. 복잡한 설정이 있습니다
2. 각 메소드 호출은 이전 메소드에서 빌드됩니다.

입니다 실제로 사실? 아니요. Post수업 에 복잡한 설정 이 없습니다 . 제목, 생성 날짜 및 본문을 설정해도 더 복잡한 최종 목표를 향해 구축 되지 않습니다 . 당신은 둥근 구멍에 사각형 못을 으깬다.

자체 참조 메소드 체인의 단점은 무언가를 수행하기 위해 여러 메소드 호출이 필요하며 각 호출이 마지막에 생성된다는 것을 전달한다는 것입니다. 이것이 사실이 아닌 경우, 메소드 체인은 잘못된 것을 다른 프로그래머에게 전달할 수 있습니다.

동료가 말했을 때 :

유창한 인터페이스는 편의를 위해서가 아니라 의미를 위해 구현되어야합니다

그들은 절대적으로 정확했습니다. 유창한 인터페이스 또는 메소드 체인은 사실이 아닐 수도있는 무언가를 전달합니다.

주요 단점은 선명도의 손실입니다. 예를 들어 :

x.foo();
x.bar();
x.baz();

이 문장들 중 어느 것도 값을 반환하지 않기 때문에 (혹은 무시된다면) 부작용을 일으키는 경우에만 유용 할 수 있습니다. 다음과 대조하십시오 :

x.foo()
 .bar()
 .baz();

첫째, 클래스가 해당 메소드를 가진 유일한 클래스 라는 사실을 알지 못하면 명확하지 않으며 bar와 baz같은 유형의 객체에서 작동 합니다. 이 경우에도 메소드가 새 객체 에서 작동 하는지 명확하지 않습니다 .xxx

부작용이있는 코드 부분을 강조 표시하면 프로그램에 대한 추론을 위해 해당 부작용을 추적해야하므로 유용합니다. 코드 작성이 쉬워지면 잠재적 인 선명도 손실 가능성을 고려해야합니다. 또한 코드를 작성하는 것보다 더 많이 읽습니다.

프로그래밍 언어의 모든 문체 요소 (수동 코딩 기계 언어와 반대)를 고려하면 "편의성이 아니라 의미 론적"주장이 약화됩니다.

엔지니어로서 우리가하는 많은 일들이 시맨틱에 편리함을 제공하고 있습니다.