![]()
프로그래밍을 하면서 가장 힘든게 객체지향적으로 프로그래밍을 하는 것이다. 메소드를 어디에 위치를 시켜야 맞는 것일까? 객체의 책임은 어디까지 가져가야하는 것일까? 요즘들어 이런 생각들을 자주하게 되면서 코드를 썻다 지웠다하는 것 같다. 혼자 해결이 불가능하여 예전에 읽고 잊어버렸던, 사실은 그 당시에는 잘이해가 안되었던 것 같다. 객체지향의 사실과 오해란 책을 피고 객체에 대해 다시 읽어 보았다. 고민을 하고 읽을 때와 무지성으로 읽었을 때는 확실히 다르더라.. 이 곳에 정리되는 내용은 나중에 객체가 무엇이였지? 라고 생각될 때 기억을 되살리기 위해 작성됬다. 객체 개별적인 실체로 식별 가능한 물리적인 또는 개념적인 사물은 어떤 것이라도 객체가 될 수 있다. 개념적인 사물? - 오늘의 주문내역 혹은 어제..
객체 ⇒ 물리적인 경계를 지닌 구체적인 사물. (추상적인 사물까지도 사람들은 객체로 인식할 수 있다.) ex) 주문, 계좌 이체 물리적인 실체는 존재하지 않더라도 인간이 쉽게 구분하고 하나의 단위로 인지할 수 있는 개념적인 객체의 일종이다. 객체지향 패러다임의 목적 : 현실 세계를 모방하는 것이 아니라 현실 세계를 기반으로 새로운 세계를 창조하는 것 객체, 그리고 소프트웨어 나라 객체의 다양한 특성을 효과적으로 설명하기 위해서는 객체를 상태(state), 행동(behavior), 식별자(identity)를 지닌 실체로 보는 것이 가장 효과적이다. 상태(state) 상태는 특정 시점에 객체가 가지고 있는 정보의 집합으로 객체의 구조적 특징을 표현한다. 객체의 상태는 객체에 존재하는 정적인 프로퍼티와 동적인..
