애스팩트 지향 프로그래밍은 (2장의 Aop 객체처럼) 변수에 객체 리터럴을 할당하지 않으면 시작부터 문제가 된다. 애스팩트를 적용하려면 포인트컷(예: 변수명)이 있어야 하는데 객체 리터럴은 이름 자체가 없기 때문이다. 하지만 객체 리터럴을 팩토리 함수로 생성하면 반환된 리터럴을 갖고 놀 after 애스팩트에 함수를 래핑할 수 있다.

단순 객체 리터럴에서는 의존성 주입은 아예 시도조차 해볼 기회가 없지만, 리터럴을 생성/반환하는 함수는 (2장에서 언급한) 애플리케이션 시작부에서 의존성을 주입하는 과정에 아주 잘 어울린다.

단순 객체 리터럴은 생성 시 검증할 수 없다는 것도 문제다. 일반적으로 생성자는 전달받은 인자를 어떤 식으로든 검증하여 올바른 결과를 보장하지만, 단순 객체 리터럴은 그런 검증을 할 수 없다.

그러므로 객체 리터럴은 싱글톤 또는 확실히 테스트를 마친 코드에서 생성된 객체 리터럴이 아닌 한 중요한 애플리케이션 부분에 쓰지 않는 편이 좋다.

객체 리터럴은 한 곳에서 다른 곳으로 데이터 뭉치를 옮길 때 쓰기 편하다. 예를 들어 더글라스 크락포드가 《자바스크립트 핵심 가이드(한빛미디어, 2008년)》에서 이야기한 것처럼 함수 인자가 워낙 많아 그 순서를 정확히 맞추기 쉽지 않을 때 객체 리터럴을 사용하면 유용하다. 그는 리터럴에 프로퍼티가 하나도 없다는 건 기본값을 사용하라는 신호로 받아들일 수 있다고 말했다.

쓰기 편한 객체 리터럴이지만 한 가지 명심하자! 함수가 어떤 프로퍼티 조합도 대비할 수 있으려면 그만큼 테스트를 많이 해야 하는 부담이 생긴다. 생성 방식을 잘 다스릴 수 있고 테스트를 확실히 마친, 말하자면 isValid 같은 메서드로 검증 가능한 객체를 대용하는 방안을 고민하라.