현재 Java로 게임을 작성하고 있으며, 간단한 사용으로 메모리 사용량을 줄일 수있는 간단한 설계 결정을 내리고 있습니다. 큰 변화가 나중에 메모리 사용을 줄이기 위해). 게임의 주 레이아웃은 헥스 그리드가 될 것이고, 헥스를 저장할 때 HashMap을 사용할 것입니다. 각 엔트리는 Point 오브젝트를 키로 사용하고 Hex 타입 오브젝트 (Hex은 인터페이스입니다) 값으로. 나는 Hex을 구현하는 두 개의 다른 객체를 가질 것입니다. OceanHex 및 LandHex.정적 필드만을 포함하는 객체에 대한 메모리 사용
LandHex은 많은 수의 필드 (건물, 통계, 현재 타일에있는 플레이어)를 포함하지만 플레이어는 바다 타일을 만들거나 바다 타일로 이동할 수 없습니다. 근본적으로, 그들은 단지 미적입니다. 이러한 이유로 OceanHex은 정적 최종 부재 2 개를 포함하기 때문에 각각의 인스턴스는 OceanHex이됩니다. 원래는 OceanHex 인스턴스를 하나만 인스턴스화하고 각각의 바다 타일 참조를 인스턴스로 사용하여 메모리 사용량을 줄이려고 계획 했었지만이 방법이 궁금합니다. OceanHex에는 정적 필드 만 있기 때문에 OceanHex의 많은 인스턴스가 실제로 단일 인스턴스보다 많은 메모리를 사용합니까?
일반적으로 내 질문은 : 정적 필드 만 포함하는 클래스에 대해 개체의 많은 인스턴스가 많은 참조를 가진 개체의 한 인스턴스를 갖는 것과 같은 양의 공간을 차지하게됩니까?
정적 필드 만있는 클래스의 인스턴스를 생성하는 경우는 거의 없다고 생각하지만, 그럼에도 불구하고 궁금합니다.
각 추가 객체는 여전히 일부 메모리를 차지하지만 필드가 인스턴스 필드 인 것처럼 많이 사용되지는 않습니다. 그러나 정적 필드가있는 인스턴스를 만드는 것보다 싱글 톤 인스턴스를 만드는 것이 정확합니다. – shmosel
나의 충고는 : 디자인을 간단하고, 정확하며, 탐색하기 쉬워지며, 메모리 사용이 그 자체를 보살 피는 것보다 더 자주한다. 그렇지 않으면 다시 쓰기가 쉽습니다. 끔찍한 디자인으로 시작한다면, 상황은 더욱 악화 될 것입니다. 이 특별한 경우에,'OceanHex'을 싱글 톤으로 만드는 것은 모든 메모리 발자국 고려 사항 때문이 아니라 모든 세계가 논리적으로 동등한 간단한 사실입니다. – biziclop
그건 그렇고, 당신이 'OceanHex'의 단일 복사본을 사용하는 것에 대해 언급 한 접근법은 * Flyweight * 디자인 패턴이며, 특정 구체적인 클래스가 구분할 수없는 경우 모든 "인스턴스"가 의미가 있습니다. – chrylis