객체지향 프로그래밍(OOP) 에서 Design pattern 이 흔히들 생성/구조/행위의 카테고리의 각각의 List 로 제시가 되어있는데, 

Design pattern 에 대해서 말을 하자면,

System 에 대해서 객체를 지향한다기 보다는 System 의 구성을 객체형태로 하기를 지향한다는 것에서 Design pattern 도 있는 듯함.. ㅇㅅㅇ.. 

그러니까, 컴퓨터(Computer) 에 대해서는, 

System 의 행태(Behavior) 에 대해서 조합묶음의 특성에 대한 Procedure 로 CRUD 를 개발하고 이에 대해서 Condition CODE 를 맞춰놓는 Frame 을 

개발하는 것이 공학적인 프로그래밍의 일반적인 형태가 됨..  

그래서 OOP 에서의 객체지향이라는 것은 이러한 Procedure 를 CRUD 로 System domain 에 대해서 정보를 처리하는 것으로 개발을 하고서, 

이로부터 System 의 CODE 에 대해서 Condition 을 System domain 의 하위영역을 정의해나가면서 개발을 하는 행위에 대해서 하위영역의 정의에 관해, 

Method 중심의 Object 를 지향한다는 의미에서의 객체를 다루는 것이 맞음. ㅇㅅㅇ 

객체지향은 System 의 CRUD 에 대한 System domain 에 대한 하위영역을 정의하는 의미에서 객체가 옳다는 것이고, Design pattern 의, 

생성/구조/행위라는 것은 하위영역의 Domain 을 System 의 Domain 전체에 대한 CRUD 에 대해서 Inter domain (도메인 상호) 에 대해, 

객체 간의 생성과 구조 및 행위에 대해서 Trigger 로써 있어야 하는 List 에 대해서 정의를 했다고 봄. ㅇㅅㅇ

그래서 결국에 Design pattern 이라는 것이, 개발행위에 대해서 문제해결의 Box answer 가 된다는 의견이 주류로 많은 실정인데 이것에 대해서는, 

정확히 문제해결의 Template 가 된다고 보여지지는 않음.. ㅇㅅㅇ..

아무튼 간에 판단을 해보면, 

Design pattern 이라는 것은 Inter domain(도메인 상호)에 대해서 System 의 CRUD 에 대한 도메인(Domain) 전체의 것에 대해서, 

System 에 의하면 있게 되는 하위영역에 대해서 객체로써 정의행위를 Tree 방식으로 설계적인 흐름 중에 타고내려가면서 정의를 해야하는데, 

여기에서 발생하는 도메인 상호(Inter domain) 의 Getter/Setter 가 Object 자체단위로 있게 되는 것에 대한 pattern 이라는 것임.. 

그래서 객체지향 프로그래밍(OOP) 를 하는 것이 Design pattern 을 따라서 프로그램을 설계를 한다기 보다는 실제로는, 

System 단위의 도메인 전체의 CRUD 를 정의해놓고서, 이를 근거기준으로 

하위영역을 정의를 하는 Tree level 의 Object 를 완성하는 것이 된다고 봄.. ㅇㅅㅇ.. 

OOP 라는 것이 System 단위로 Define tree 를 만드는 것에 대해서 Condition CODE 를 정의로써 집어넣는 행위에 관해서 객체의 관점을 따름으로써, 

언어적인 활동이 이뤄지는 것에 일반적인 느낌의 객체가 있고 그러한 흐름(Convention) 의 결과로 Design pattern 이 개발된 것으로 봄. 

ㅇㅅㅇ..