# 설계 원칙

xpmxf4

영한갓님의 강의에서 회원의 정보를 수정하기 위해 MemberService에 update 메서드를 추가하던 와중이었습니다. > "update 메서드는 엔티티를 바꾸겠다는 변경성 메서드인데, > 이 메서드의 return type 을 Member로 한다면 update로 조회를 하는 꼴이 돼요. > > command와 query 가 같이 있는 꼴이 되죠. > 그래서 저는 update 메서드의 return type을 void로 하거나 id 값 정도로 해줘요." > > -갓영한님의 말씀- 영한님이 실무를 하시면서 되게 신경쓰는 규칙이라고 느껴지기도 하고, 뭔가 일종의 디자인 패턴인가 싶기도 하고, 대충 문맥은 알겠는 데 저 문장에서 command 와 query라는 단어가 정확히 무슨 뜻이지? 라는 각종 의문이

dev-msj

유지보수 작업을 하다보면 최적화나 버그 fix 등의 이유로 코드 일부를 조금 수정 했는데, 전혀 예상하지 못한 엉뚱한 곳에서 에러가 나는 경험을 해본 적이 있을 것이다. 이런 프로그램들은 경험상 객체지향 언어의 특성을 고려하지 않고, 그냥 원하는 결과만 얻을 수 있게 마구잡이로 개발되어 있었다. 그러다보니 유지보수하는데 발생하는 문제점이 너무 많아서, 새로 만드는 것 외에는 해결방안이 없었다. 그렇다면 어떻게 해야 객체지향 언어 특성에 맞게 개발한 것인지, 유지보수성과 확장성을 가진 유연한 프로그램을 만들 수 있는지 알아보자. 객체지향 프로그래밍의 설계 원칙은 로버트 마틴이 2000년대 초반에 명명한 다섯 가지 기본 원칙이다. 프로그램 유지 보수와 확장이 쉬운 시스템을 만들기 위해 고안되었다. 또한 이 원칙들은 [애자일 소프트웨어 개발](https://ko.wikipedia.org/wiki/%EC%95%A0%EC%9E%90%EC%9D%BC_%EC%86%8C%ED%94%84%ED%