아키텍쳐 패턴 묻는거 아닌이상
기본적으로
OOP내에서 자주 쓰이는 코드 템플릿내에서 뭐가 숙달되있느냐 그런거 묻는거니까
보통
생성(Object 생성에 관여)
팩토리,추상 팩토리,빌더,프로토 타입,싱글톤(최근에 여기에 서비스 로케이터 포함)
구조(Object 단위, 즉 오브젝트를 나누는데 관여)
어댑터, 브릿지, 데코레이터,퍼사드,플라이웨이트
행동(Object 책임 할당)
커맨드,이터레이터,모듈레이터,옵저버
이렇게 나뉨
디자인 패턴이라는 말은 기본적으로 랄프 존슨과 4명이 저술한
Design Patterns: Elements of Reusable Object-Oriented SoftWare
라는 책에서 나온거(1994년 발매로 앎)(이게 바로 GOF임, Gang of Four)
그래서 우리가 흔히 디자인 패턴이라고 말하는건 OOP적 관점인거.
일반적으로 멀티 패러다임 언어 지향인 요즘에서 '꼭' 패턴을 지향할 필욘 없지만
팀마다 기본적으로 XX해서 구현했다 이런것보다 XX패턴을 이용해서 구현했다라고 하는 소통에 기여하기때문에 이해하기 쉽고
코드 리뷰할때도 그래서 패턴 코딩이 쉽다고 하잖아.
그런관점에서 OOP 프로그래머면 패턴 써봤냐는 기본적으로
'너가 다른 사람과 이 팀의 다른 사람과 의사소통 할 수 있냐' 정도로 받아들이면 되지 않을까 싶다.
기본적으로 자기가 아는 걸 말로 정리해서 설명하는것도 일종의 능력이긴함
물론 내재적으로 거의 대부분 사람들은 알고 있지만 그걸 의사소통 하느냐는 좀 딴 문제라고 생각함.
교수들중에서도 천재인데 설명 존나게 못하는 양반들 많듯이.
나도 패턴을 굳이 꼭 써야만 한다 생각하지 않고, 오히려 패턴이라는 건 Simple Code로 가기 위한 일종의 여정의 부산물이라는데 동의는 한다만
남들 다 쓰는데 모르는것도 좀 문제긴해 ㅋㅋ
아직도 지배적인 유행이잖아. 우리 코딩 대부분 OOP 관점내에서 코딩하고 있고ㅋㅋㅋ
솔직히 패턴 써보다보면 결국은 과잉설계되는데, 이 과잉설계가 프로그래밍 맥락적으로 추후에 컨텐츠 추가할때 도움된다는 설문조사가 있으니까
물어보는건 문제가 안되지 않을까 싶다
실전에 MVC, 싱글톤 외에 거의 쓰이지 않음 의사소통할일도 없음
MVC는 아키텍쳐 패턴이긴한데, 일단 뭐 그건 둘째치고, 팩토리 패턴이나 다 써볼 수 있지 않나? 당장 어댑터, 빌더 정도는 다 써본듯? 당장 나 저기에 쓴 패턴들 게임 만드는데 다 써봤으니까. 기본적으로 웹은 모르겠지만 게임 만들땐 다 한번씩 써보는 패턴들이긴함.
Mvc 시리즈도 시발 설명보면 ㅈㄴ 장황함 ㅋㅋ 걍 확장성있게 solid 잘지키려면 걍 mvvm써야하는걸 말붙이고 있음
뭔 개소리야 정적 팩토리 생성자 메서드 클래스 수준에서 다 쓰고, 파사드, 브릿지, 데코레이터, 빌더, 옵저버 이런거 다 쓴다 ㅋㅋ
자지
보지
아니 "패턴을 쓴다는" 말이 웃김 그냥 존나 기초 입문에 말붙인건데 걍 정처기 안따면 개발자 아님같음 왜냐고? 남들도 다 따니깐 ㅋㅋ 솔직히 여태 개발 잘하다가 이제 배우려니 ㅈㄴ 뻔한 일차방정식 장황하게 설명한거같아서 걍 열받음 실제로 저거 하나 넣으려고 코드를 안짬 ㅈㄴ 복합적으로 짜지
이것도 존나 말맞긴함. 근데 결국 경험적으로 알아도 말로 표현할 수 있느냐 없느냐 같은 느낌이긴함
니 말이 틀렸단게 아니라, 그냥 이거는 그거같음 "어차피 코드 짜면 다 아는데 그거 써봤냐고 묻는거 무시하는거 아니냐?" 근데 내 생각에는 "회사에서 니가 한 결과물 이야기할때 의사소통 능력 요구하는구나" 정도로 생각드네 . 뭐 니 말이 백프로 맞긴함
우우 비겁한 니말맞 우우
하지만 내 말도 맞음 우우
님 정보 정리한건 항상 궁금했던 주제라 흥미있긴한데 따로 블로그로 정리는 안해둠?
블로그 옛날에 만들어둔거 이글루스 삭제된이후로 디시에서나 글씀
어차피 나는 주로 책 사서 공부하는편이니까
확인
그래도 너가 뭐 현역이라 나보다 많이 알겠지만 나는 뭐 독학이라 해외 대학 커리큘럼보고 전공서적 Z라이브러리로 공부한거라 너가 훨씬 더 잘 알거임ㅋㅋ