확장 방법을 사용하여 빈 값을 피하다

나는 Ada에서 C보다 프로그래밍 시간이 더 길다.항상 나를 괴롭히는 일들NET나 대상을 향한 고도의 언어는 모두 영해 인용률이 급속히 발전하는 원인이다.내가 어떻게 평범하지 않은 Ada 프로그램에서 인용을 풀 수 있는지 고려하면 이것은 특히 이상하다.인터넷 프로그래머들은 이것에 대해 너무 많은 불평을 하는데, 내가 C 언어를 더 많이 사용할 때, 나도 매우 화가 난다.
그러나 문제는 언어 자체가 아니다.진부하지만반대로 이것은 이 언어들이 격려하는 디자인 모델의 결과이다.
우리가 일을 어떻게 완성했는지 보여주면 문제가 명확해지기 시작할 것이다.

class Person {
    void Move();
}

Person p;
p.Move();

The problem is you didn't initialize p!

네, 이 지극히 자질구레한 구체적인 사례 중에서 가장 진부한 의미에서 말하자면 이것이 문제입니다.관건은 우리가 어떻게 부르는가Move()다.예를 들어 p 실제로는 한 무리의 교체 변수이다.데이터베이스를 조회했고 IEnumerable<Person> 의 회답을 받았습니다.아니면, 그것은 비정상을 일으켜야 할지라도, 대부분의 서열화 프로그램은 잘 작성되지 않는다.우리는 왠지 모르게 p 코드 흐름 분석만으로는 그것이 비어 있다고 말할 수 없다.
일이 바로 이렇다, 그렇지?이것이 바로 빈 링크가 존재하는 원인이다.분명히 내가 진정으로 해야 할 일은 p?.Move()!
근데 이건 나한테 안 어울려.다른 라이브러리를 주로 작성하는 개발자로서, 나는 호출 사이트를 가능한 한 간단하고 오류를 방지하려고 한다.?. 대신 사용.을 잊어버리는 것은 너무 쉽다.이 문제를 해결하는 것은 결코 쉽지 않다.여기저기 ?. 놓는 것은 사실상 문제가 있다. 왜냐하면 그 자체이기 때문이다.
그런데 일이 이렇다, 그렇지?아니오

type Person is tagged null record; --fieldless "class"

procedure Move(Self : in out Person);

p : Person;
p.Move; --object.Method() style
Move(p); --Procedure(object) style

이 두 가지 방법 모두null 인용 이상을 일으키지 않습니다!
이 중 상당 부분은 언어의 의미와 관련이 있다.Ada는 선언할 때 모든 대상을 초기화합니다. 명시적 선언이 없더라도 분석기가 일반적으로 보고하지만 경고나 오류가 발생합니다.분명히 우리는 C의 의미를 바꿀 수 없다.비록 이것은 매우 좋지만, 우리는 이것에 대해 무력하다.

해결 방안이 하나 있는데, 세상에, 그것은 둔하다.만약 네가 고객을 위해 제품을 생산하고 있다면, 이것은 너에게 조금도 쓸모가 없다.만약 네가 도서관 작가라면, 이것은 너의 흥미를 불러일으킬 것이다.
Ada의 함수/절차 설명을 참고하십시오.비록 그것이 하나의 유형을 분배하고 있지만, 우리는 여전히 이 매개 변수를 명시적으로 성명한다.저희가 C에 이런 게 있나요?맞다extension method.다시 한 번 시도해 봅시다.

class Person {
    void Move();
}

static class Operations {
    static void Move(this Person person) => person.Move();
}

Person p;
p.Move(); //This is still Person.Move, not Operations.Move

어?문제는 실례를 우선적으로 해결하는 방법이다.확장 방법에 앞서 검사를 진행하다.우리는 using static Operations 여기저기서 전화Move(p)를 할 수 있지만, 이것은 매우 반대 C이다.그러나 간단한 가시성 변경인 해결 방안이 있다.

class Person {
    internal void Move();
}

static class Operations {
    static void Move(this Person person) => person.Move();
}

Person p;
p.Move(); //This is Operations.Move now!

대단히 좋다비록 우리는 단지 이때 방향을 바꾸어 호출할 뿐이지만.우리는 여전히 빈 인용 이상을 얻을 수 있다.우리는 어떻게 우아하게 처리합니까null?

이것은 사실 우스갯소리가 아니다.간단한 미적분으로 이 점을 해석할 수 있다. 이것은 이렇게 간단하다. 나는 심지어 모든 이론을 얻을 필요가 없고 단지 형이상학일 뿐이다.
만약 우리가 아무것도 움직이지 않는다면, 무슨 일이 일어날까요?응, 아무 일도 없었어.무엇이 null입니까?어떤 내용도 가리키지 않는 포인터/인용.그래서 무중생유의 조작은 아무것도 할 수 없다.우리는 이렇게 편찬할 수 있다.

static void Move(this Person person) {
    if (person is null) {
        return;
    }
    person.Move();
}

현재 p.Move()에 대한 호출은 p에서 말한 대로 이동하거나 아무것도 하지 않습니다.
만약 당신이 되돌아오는 유형이 있다면, 그것은 약간 다르다.그러나 같은 형이상학적 사유가 답을 제시했다.집합에서 객체가 비어 있는 경우 나타나는 횟수를 계산하려면 몇 번입니까?Person.Move().더 뚜렷한 것은 한 자루에 사과가 몇 개 있고 자루가 비어 있다면 사과가 몇 개 있습니까?0 . 만약 네가 자루 안의 사과 수량을 세고 있는데, 네가 자루가 없다면, 자루 안에 사과가 얼마나 많은지 네가 없다.0 . 기억해라, 이것은 존재하지 않는 자루지, 네가 없는 자루가 아니다.
나는 이것이 대다수 사람들에게 유용하다고 생각합니까?아니오, 절대 아니에요.가장 중요한 것은 순수한 호기심이다.하지만 이것은 틀림없이 도서관 작가가 기억해야 할 것이다.나는 많은 실수를 피하는 데 도움이 되기 때문에 가용성에 대한 관심이 매우 높다는 것을 분명히 볼 수 있다.그러나 모든 방법이 이렇게 방공해야 하는 것은 아니다.어떤 방법은 반드시 실례 자체에서 호출되어야 하며, null 해석 인용 이상을 그 의미의 일부분으로 던져야 한다.API가 날로 강화되기를 원하는 사람들에게는 깔끔한 도구일 뿐이다.