이 기능을 설계하는 더 좋은 방법은 무엇입니까?

StackOverflow https://stackoverflow.com/questions/1405295

  •  05-07-2019
  •  | 
  •  

문제

나는 주로 배열에 데이터를 삽입하는 다른 함수에 대한 엄청난 양의 호출(50개 이상)로 구성된 함수를 가지고 있습니다. 여기저기에 논리가 배열에 다양한 항목을 삽입하기 위한 다양한 조건을 지시합니다(그리고 끝에 약간의 추가). 배열의 내용을 파일에 기록합니다.)이 기능을 만드는 더 좋은 방법이 없는지 궁금합니다.배열 삽입 명령 세트를 논리적으로 분할하여 자체 기능으로 시작할 수 있을 것 같지만 더 할 수 있는 일이 있는지 궁금합니다.거기 있나요?

예:

function buildTable(fileName, data)
    local dataToWrite = {}
    table.insert(datTWrite, {
        Type = "type1",
        Key = "someKey",
        Value = data.SomethingInteresting
    })
    --and so on ad nauseum with an occasional but of actual logic to spice things up
    dataWriter:open(fileName .. ".bla")
    dataWriter:batchWrite(dataToWrite)
    dataWriter:close()
end

이 경우 dataWriter는 파일 쓰기 프로세스를 처리하는 미리 정의된 클래스의 인스턴스입니다.

도움이 되었습니까?

해결책

좋은 소식은 출력을 구축하기 위해 루프의 버퍼에 연결 문자열의 일반적인 LUA 비관에 직접 밟지 않았다는 것입니다.

나는 다음과 같이 당신의 샘플을 쓸 것입니다.

function buildTable(fileName, data)
    local t = {}
    t[#t+1] = {
        Type = "type1",
        Key = "someKey",
        Value = data.SomethingInteresting
    }
    --and so on ad nauseum with an occasional but of actual logic to spice things up
    dataWriter:open(fileName .. ".bla")
    dataWriter:batchWrite(t)
    dataWriter:close()
end

임시 테이블에 긴 오타가 발생하기 쉬운 이름을 사용하지 않는 작은 이점이 있으며 t[#t+1] 호출보다 빠른 배열 부품을 확장하는 관용구 table.insert().

그렇지 않으면, 구조적 개선의 출처는 코드의 "Ad Ad Nauseum"부분에있을 것입니다.

  • 로컬 기능으로 수집 할 수있는 일반적인 계산 및 조각을 찾으십시오.
  • 기능 정의를 중첩 할 수 있으므로 헬퍼 기능을 사용하는 장소로 범위로 제한 될 수 있습니다.
  • 너무 많은 사람들의 논리를 찾아 내년에 그것을 유지 해야하는 사람에게 합리적으로 다시 작성하십시오.
  • 위키 : LUA 디자인 패턴
  • 위키 : 루아의 선
  • 위키 : 최적화 팁
  • 위키 : LUA 코드 프로파일 링

무엇보다도 조기 최적화를 조심하십시오. 비교 지점으로 지금 가지고있는 것을 벤치마킹하고이를 성능 병목 현상을 찾기위한 가이드로 사용하십시오.

다른 팁

"가끔씩 자극을 주기 위한 실제 논리가 포함된 광고 메스꺼움"이라는 말은 다음과 같은 블록이 많이 있다는 것을 의미한다고 가정합니다.

table.insert(datTWrite, {
    Type = "type1",
    Key = "someKey",
    Value = data.SomethingInteresting
})

함수에 고유한 유일한 측면은 채워지는 테이블과 data 물체.내 개인적인 "모범 사례"는 이 모든 것을 다음과 같은 별도의 테이블로 가져오는 것입니다.

local entries = {
    {
        Type = "type1",
        Key = "someKey",
        ValueField = "SomethingInteresting",
    },
    {
        Type = "type2",
        Key = "someOtherKey",
        ValueField = "SomethingElse",
    },
    -- etc.
}

이 테이블은 전역 테이블이거나 함수가 정의된 외부 범위에 있어야 합니다.이제 실제 작업을 수행하는 기능을 변경하지 않고도 항목을 더 쉽게 재구성할 수 있습니다.함수 자체는 다음과 같이 항목을 반복함으로써 크게 단순화됩니다.

for i, entry in ipairs(entries) do
    table.insert(datTWrite, {
        Type = entry.Type,
        Key = entry.Key,
        Value = data[entry.ValueField]
    })
end

"비정기적" 논리의 경우 각 항목에는 루프에서 흥미로운 정보를 제공하는 선택적 기능이 있을 수 있습니다.예:

for i, entry in ipairs(entries) do
    if not entry.CheckSomething or entry.CheckSomething() then
        table.insert(datTWrite, {
            Type = entry.Type,
            Key = entry.Key,
            Value = data[entry.ValueField]
        })
    end
end

또는 더 많은 사용자 정의 기능이 필요한 경우 테이블의 개별 항목을 BE 기능으로 허용할 수도 있습니다.각 입력 함수는 테이블을 반환하거나 반환하지 않습니다.

for i, entry in ipairs(entries) do
    if type(entry) == "function" then
        local newEntry = entry()
        if newEntry then
            table.insert(datTWrite, newEntry)
        end
    else
        table.insert(datTWrite, {
            Type = entry.Type,
            Key = entry.Key,
            Value = data[entry.ValueField]
        })
    end
end

계속할 것도 없이는 연구를 시도 할 것입니다. 코드 냄새 그리고 당신의 기능이 어떻게 비교되는지보십시오. 사물의 소리에서 아마도 당신이 할 일이 많을 것입니다. 다른 조건부 논리에 의해 격리 된 유사 / 복사 코드 블록이 있습니까? 중첩 된 루프 또는 조건부? 큰 기능을 부품으로 분할하려고 할 때 간단한 출발점입니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top