엘레강트 오브젝트 #1 Birth

 

객체지향 프로그래밍 에서는 객체와 객체의 역할을 이해함으로써 코드의 유지보수성을 향상시킬 수 있습니다. 코드의 길이는 더 짧아지고, 소화하기 쉬워지며, 모듈성이 향상되고, 응집도가 높아집니다.

1.1 ) -er로 끝나는 이름을 사용하지 마세요.

• 클래스의 이름은 무엇을 하는지가 아니라 무엇인지에 기반
• 객체는 캡슐화 된 데이터의 대표자
  • 클래스 이름이 -er로 끝난다면 이 클래스의 인스턴스는 실제로는 객체가 아니라 어떤 데이터를 다루는 절차들의 집합일 뿐
• 올바른 이름을 지으려면
  • 클래스의 객체들이 무엇을 캡슐화 할 것인지 관찰 후 적합한 이름을 찾기
    • ex) 그는 픽셀이고 스스로 색을 바꿀 수 있어
• 외부에서 객체에게 그 일을 하도록 요청하면, 객체 스스로 무엇을 할 지 결정해야 함
  • 객체는 캡슐화 된 데이터의 대표자

느낀점

• -er을 붙힌다면 
  • 아래와 같이 저 행동만 해야 할 것 같은 느낌
• -er이 아니라 parent라면 
  • 아이 돌봄과 관련된 책임을 수행함하게 해서 응집도를 높일 수 있을 것 같음
    • 우유를 준다, 소화를 시켜준다...
   

 

1.2) 생성자 하나를 주 생성자로 만드세요.

 

• 하나의 주 생성자와 다수의 부 생성자
  • 생성자의 주된 역할은 제공된 인자를 사용해서 캡슐화하고 있는 프로퍼티를 초기화하는 일
  • 이런 초기화 로직을 단 하나의 주 생성자에 위치 시키고, 부 생성자에서는 주 생성자를 호출하도록 만든다.

 

class Cash {
	private int dollars;
    
    Cash(float dlr) {
    	this((int) dlr);
    }
    
    Cash(String dlr) {
    	this(Cash.parse(dlr));
    }
    
    Cash(int dlr) {
    	this.dollars = dlr;
    }

}

 

• 위와 같이 구현한다면 주 생성자에만 유효성 검사 로직이 들어가면 된다.
• 유지보수성을 저해하는 가장 커다란 장애물인 복잡성과 중복이라는 두가지 문제가 해결

 

느낀점

• '원시값을 포장하라' 객체 지향 생활체조 원칙을 지킬 때 유용하게 사용 할 수 있을 것 같다.

 

1.3 생성자에 코드를 넣지 마세요.

• 객체 초기화에는 코드가 없어야 하고 인자를 건드려서는 안됩니다.
  • 대신, 필요하다면 인자들을 다른 타입의 객체로 감싸거나 가공하지 않은 형식으로 캡슐화 해야합니다.
• 진정한 객체지향에서 인스턴스화란 더 작은 객체들을 조합해서 더 큰 객체를 만드는 것을 의미합니다.
  • 객체들을 조합해야 하는 단 하나의 이유는 새로운 계약을 준수하는 새로운 엔티티가 필요하기 때문입니다.

• "5"라는 텍스트 객체 대신 new Cahs("5")를 사용하는 이유
  • "5"가 필요로 하는 계약을 따르지 않음
    • 이것이 다른 타입의 새로운 객체를 생성해야 했던 이유

• 기술적인 이유
  • 생성자에 코드가 없을 경우 성능 최적화가 더 쉬워져서 실행 속도가 빨라짐
  • 생성자에 들어 간 로직은 생성시 무조건 실행되기 때문에 제어가 어려움

• lazy
  • 객체는 요청 받을 때만 행동하고 그 전에는 어떤 일도 하지 않습니다.

• 일관성
  • 우리는 이 클래스의 미래에 어떤 일이 일어날지 모른다.

 

느낀점

계약이라는 말이 자주 등장해서 찾아봤는데 좋은 객체의 7가지 덕목에 "객체는 계약에 따라 동작한다."가 있다.

https://codingnuri.com/seven-virtues-of-good-object/

이걸 토대로 1.3장을 조금 더 생각해보았다.

• 돈과 관련 된 계약을 수행 할 Cash 타입이 필요
  • String "5" 대신 Cash가 필요한 이유
• 계약은 인터페이스와 같이 객체의 행동을 명세 -> 객체들은 계약 한대로 움직이길 예상함
• 생성자에 로직이 들어가 버리면??? -> 예상불가
  • 생성자는 인터페이스에 정의되지 않음