클래스 속성을 HashMap으로 대체하는 데 문제가 있습니까?

디자인 측면에서 고려해야 할 이론적 인 질문입니다. POJO를이 재사용 가능한 클래스로 대체한다면 어떨까요? 일부 상용구 코드는 피할 수 있지만 어떤 문제가 발생할 수 있습니까?클래스 속성을 HashMap으로 대체하는 데 문제가 있습니까?

// Does not include failsafes, guards, defensive copying, whatever... 

class MySingleGetterAndSetterClass{ 

    private HashMap<String,Object> myProperties; 

    public SingleGetterAndSetter(String name){ 
     myProperties = new HashMap<String,Object>(); 
     myProperties.put("name", name); 
    } 

    public Object get(string propertyName){ 
     return myProperties.get(propertyName); 
    } 

    public Object set(string propertyName, Object value){ 
     myProperties.put(propertyName, value); 
    } 

}

출처

2013-06-18 James P.

은 당신의'set' 방법은'get' 호출하는 건가요? –

Nope. 결정된. 이 메모장에 쓴 : P –

브라우저의 코드 검사기가 최고되지 않습니다) –

주요 단점

사용하는 훨씬 느린 메모리
적은 유형의 안전
이상의 오류가 발생하기 쉬운
쓰기
더 많은 코드를 유지하기가 더 어렵 읽기/
더 많은 스레드 안전 문제 (중단 할 수있는 더 많은 방법) 및 mo 쓰레드를 안전하게 만드는 것은 어렵다. 디버깅
열심히 읽고하기가 어려워, 필드의 순서는 무작위로 의사를 배치 할 수 같은 "유형"의 다른 개체에 대해 서로 다른주의.
더 어려운
조금 리팩토링 또는 코드 분석을 지원하지합니다.
코드 완성을 지원하지 않습니다.

BTW 일부 동적 언어는 사용자가 제안한 것과 정확히 일치하며 이러한 모든 문제가 있습니다.

출처

2013-06-18 02:10:28

"BTW 일부 동적 언어는 사용자가 제안한 것과 정확히 일치하며 이러한 모든 문제가 있습니다." 저는 PHP와 같은 솔루션이 있다고 생각합니다. :). 만약 내가 실제로 이와 같은 일을한다면 그것은 클래스 생성기 또는 주석으로 갈 것입니다. –

클래스 생성기를 사용하는 경우 맵이 필요하지 않습니다. 가능한 한 많은 프리미티브를 사용하여 실제 유형의 모든 실제 필드를 생성하면됩니다. –

이렇게하면 매우 불안정한 코드가 발생할 수 있습니다. 당신의 get/setting은 컴파일 타임에 체크되지 않습니다. 일반적으로 코드를 빠른 속도로 수행하고 컴파일 시간을 최대한 단축 할 수 있습니다.

그것도 상대적으로 안전 당신이 여기 저기 취급 널 검사/예외를해야 할 것 만들려면 다음 방법은 지속적으로 값이 모든 코드를 통해, 발견되지 않는 경우를 처리합니까? 그것은 매우 빠르게 비대해질 것입니다.

출처

2013-06-18 02:03:32 ach

그냥 알다시피, 왜 이것이 채택되지 않았는지 알아 내고 싶었습니다. 대답은 좋은 통찰력을 제공해야합니다.컴파일 타임 검사에 대한 의견은 훌륭합니다. 수표는 클래스 외부의 코드를 의미합니까? 이 문제를 처리 할 래퍼는 어떻습니까? –

당신이'get (someProperty)'를 호출하는 케이스에 대해 보호 할 필요가 있으며 호출 할 때마다 존재하지 않습니다. 그 시나리오에서 당신은 무엇을합니까? 앞서 언급했듯이이 접근법은 동적 유형 언어를 에뮬레이트하려는 것과 비슷합니다. 역동적 인 유형 지정을 염두에두고 설계된보다 유연한/기능적 언어를 사용하는 것이 훨씬 낫습니다. – ach

검사를 컴파일하지 않습니다.
당신은 다운 캐스팅해야하는데, 이것은 좋지 않습니다.
mantain하기가 어렵습니다. OOP에 대하여
,

귀하의 POJO를이 클래스이다는 현실 세계에서 무언가의 추상화를 나타냅니다. 지도에 속성을 넣고 싶다는 것을 잘 알고 있다면 좋은 디자인이 아닙니다. OOP 사용에 반대합니다. 이런 식으로 생각한다면 모든 클래스를 하나의 큰 문자열로 가져 와서 위치별로 검색하면 속성이있는 사전 만 키로 사용하는 것보다 낫습니다.

출처

2013-06-18 02:12:13 nachokk

필드가 null 값도 보유 할 수 있으므로 검사 할 필요가 없습니다. –

@PeterLawrey 아, 나는 잊어 버렸다. 나는 처음에 그가 POJO를 속성 대신 저장하려고 생각했다. D, 나는 편집 할 것이다. 고마워. – nachokk

클래스 속성을 HashMap으로 대체하는 데 문제가 있습니까?

답변

관련 문제