Clean Code - 객체와 자료구조

프로그래밍 초기 시절에는 간단한 연산을 위해 프로그램을 사용했으므로 절자 지향 프로그래밍이 대세였다.

그러나 점차 기업이나 정부와 같이 규모가 큰 영역에서도 프로그래밍이 사용되기 시작하자 절차 지향 프로그래밍만으로는 유지보수가 어려웠다.

이를 용이하게 하고자 객체별로 체계화한 것이 객체지향 프로그래밍이다.

그러나 단순히 객체만 사용한다고 해서 객체 지향 프로그래밍이라고 하기에는 무리가 있다.

객체간의 역할을 분명히 하고, 이후 유지보수가 쉽도록 코드를 짜는 것이 중요하다.

---

내 코드 돌아보기

1. get/set 함수

• 자료구조이므로 get/set함수 없이 그저 변수만 공개했다.
• 코틀린의 좋은 점인 것 같다. data class를 따로 제공함으로써 철저한 자료구조 클래스로만 사용하는 것을 강제한다.

 

2. 디미터 법칙

• 사실 안드로이드 스튜디오나 프레임워크처럼 사용자가 "주"가 아닌 "부"가 되어서 사용법을 따라야 하는 환경에서는 디미터 법칙을 지키기 힘든 것 같다.
• 그때그때 필요한 모듈들을 import해와야 하고, 클래스들도 상속받은 것에 따라서 그 기능이 정해져 있기 때문이다.
• 따라서 정말 큰일이 아닌 한 바뀌지 않는 프레임워크의 속성들에는 디미터 법칙을 적용하지 말고, 내가 만든 클래스를 내가 임의로 사용할 때 디미터 법칙을 사용하는 것을 고려해야 겠다.

---

느낀점

• 자료구조와 실제 객체를 나누는 것은 평소의 내 코딩 스타일에 적용시키면 좋을 것 같다.
• 책을 통해 객체를 철저히 추상화해서 원하는 동작들만을 함수로 둔다면 훨씬 깔끔해지고 클래스간 결함도도 낮아진다는 것은 이해하겠다.
• 그러나 이론과 실무에서는 그 차이가 분명히 존재할 것 같다.
• 따라서 클래스는 다음과 같이 만드는게 좋지 않을까 생각해본다.
  • 목적에 따라 만든 함수
  • 디미터 법칙을 지키면 좋지만, 꼭 강제하진 말자.
  • 상황에 따른 객체 or 자료구조

---

포인트

1. 목적에 따른 함수를 사용하여 클래스의 내부 로직을 추상화하자.
2. 디미터 법칙 : "모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다."
   • 클래스 C가 있을 때, 함수 M이 호출할 수 있는메서드
     • C의 메서드
     • C안에 인스턴스로 저장된 객체의 메서드
     • M 안에서 생성된 객체의 메서드
     • M에 인자로 넘겨진 객체의 메서드
   • 이 때, 객체 -> 메서드 -> 객체 ( -> 메서드) 에서 ()부분으로의 접근은 없어야 한다.
3. 객체 vs 자료구조
4.  

	객체	자료구조
형태	자료는 추상화. 이 자료를 다루는 함수만 공개	자료만 공개.  별도의 함수 없음
장점	기존 함수에새 객체 타입을 추가하기 쉬움	기존 자료구조에 새 함수를 추가하기 쉬움
단점	기존 객체에 새 함수 추가하기 어려움	기존 함수에 새 자료구조를 추가하기 어려움