C# 반복되는 코드 줄 대 메모리 사용량 관점에서 속성 사용하기

Question

유지 관리 가능성과 메모리 영향 관점에서 다음 코드를 구현하는 더 좋은 방법이 있는지 궁금합니다. 다음 코드를 보면 속성을 사용하는 것이 더 좋을까요? 나는 많은 반복 코드를보고 이것이 최선의 방법이 될지 궁금해하고있다. 그런 짓을하는 것이 더 좋을 것이다 방법을 반복하기보다는

public class Win32OperatingSystem 
{ 
    internal ulong BytesToMegaBytes(ulong bytes) 
    { 
     return bytes/(ulong)1024; 
    } 

    public ulong FreePhysicalMemory() 
    { 
     ManagementObjectSearcher moSearcher = new ManagementObjectSearcher 
      ("SELECT FreePhysicalMemory FROM Win32_OperatingSystem"); 
     using (var enu = moSearcher.Get().GetEnumerator()) 
     { 
      if (!enu.MoveNext()) return 0; 
      return BytesToMegaBytes((ulong)enu.Current["FreePhysicalMemory"]); 
     } 
    } 

    public ulong TotalVirtualMemorySize() 
    { 
     ManagementObjectSearcher moSearcher = new ManagementObjectSearcher 
      ("SELECT TotalVirtualMemorySize FROM Win32_OperatingSystem"); 
     using (var enu = moSearcher.Get().GetEnumerator()) 
     { 
      if (!enu.MoveNext()) return 0; 
      return BytesToMegaBytes((ulong)enu.Current["TotalVirtualMemorySize"]); 
     } 
    } 

    public ulong FreeVirtualMemory() 
    { 
     ManagementObjectSearcher moSearcher = new ManagementObjectSearcher 
      ("SELECT FreeVirtualMemory FROM Win32_OperatingSystem"); 
     using (var enu = moSearcher.Get().GetEnumerator()) 
     { 
      if (!enu.MoveNext()) return 0; 
      return BytesToMegaBytes((ulong)enu.Current["FreeVirtualMemory"]); 
     } 
    } 
} 

...

MyMethod(string propertyName) 
{ 
     ManagementObjectSearcher moSearcher = new ManagementObjectSearcher 
      ("SELECT " + propertyName + " FROM Win32_OperatingSystem"); 
     using (var enu = moSearcher.Get().GetEnumerator()) 
     { 
      if (!enu.MoveNext()) return 0; 
      return BytesToMegaBytes((ulong)enu.Current[propertyName]); 
     } 
    } 

Answer 1

SQL 매개 변수의 부족에서 무시 (두 번째 옵션은 더 나은 일을 할 것 DRY 원칙을 사용하여 이 인스턴스). 작성하기가 적고 유지 보수가 쉽습니다. 그러나 코드를 수정하는 개발자가이 함수를 호출 한 모든 위치를 알지 못하면 버그가 발생할 수 있습니다.

저는 개인적인 방법이 하나 뿐이므로 공용 메서드에서이를 호출합니다.

public class Win32OperatingSystem 
{ 
    internal ulong BytesToMegaBytes(ulong bytes) 
    { 
     return bytes/(ulong)1024; 
    } 

    public ulong FreePhysicalMemory() 
    { 
     return GetProperty("FreePhysicalMemory"); 
    } 

    public ulong TotalVirtualMemorySize() 
    { 
     return GetProperty("TotalVirtualMemorySize"); 
    } 

    public ulong FreeVirtualMemory() 
    { 
     return GetProperty("FreeVirtualMemory"); 
    } 

    private ulong GetProperty(string propertyName) 
    { 
     ManagementObjectSearcher moSearcher = new ManagementObjectSearcher 
      ("SELECT " + propertyName + " FROM Win32_OperatingSystem"); 
     using (var enu = moSearcher.Get().GetEnumerator()) 
     { 
      if (!enu.MoveNext()) return 0; 
      return BytesToMegaBytes((ulong)enu.Current[propertyName]); 
     } 
    } 
} 

Answer 2

물론 DRY 원리에 관한 것입니다.

그러나 다른 3 가지 방법을 해당 방법으로 바꾸지 마십시오. 새 방법을 비공개로 설정하고 (다른 곳에서는 더 나은 이름을 지정하십시오.) 다른 쪽에서도 호출하십시오.

public ulong FreePhysicalMemory() 
{ 
    return FindMemoryObject("FreePhysicalMemory"); 
} 

이것은 유지 관리 용이성뿐만 아니라 가독성을 위해 적합합니다.

성능이나 기억에 대해 - 걱정하지 마십시오. 예, 추상화 수준이 추가되었습니다. 메서드를 호출해야하며 인라인되지는 않습니다.하지만 미세 최적화입니다. 가독성 + 유지 보수성을 고려하십시오.

Answer 3

메모리 영향은 무시할 수 있지만 많은 방법에 걸쳐 구현을 반복하여 DRY principle을 위반하는 것은 유지 보수성에 좋지 않습니다. 예, 대신 제안한 것을 수행하는 것이 좋습니다.