음. 어디서 부터 설명 드릴지가 조금 난감 합니다 ㅎㅎ

우선 상속을 그렇게 하실 필요는 없다는 것을 먼저 집고 넘어가겠습니다.

core에 MY Controller 확장은 보통 공통 되는 클래스를 하나 확장 하려고 하는 것이지, 세분화 하려는 것은 아닙니다.

[물론 규제 하는건 아니고, 사용자가 하고 싶으면 하는 거구요.]

상속에 대한 개념 깨우치기로는 OOP 디자인 패턴중에서  스트래티지 패턴과 팩토리 패턴 에 대해서 한번 찾아보시면 의문이 해결 되실거라 생각 됩니다.

상속에 대한 이야기는 이렇고, 메뉴를 상속별로 나눠서 사용하시는 정도는 라이브러리 부분을 이용 하시는 것을 추천해 드립니다.

물론 이건 제 개인 적인 경험에 의한 사견임 입니다.

core에는 모든 controller 에서 사용 할 수준의 것을

library 에는 하나의 리턴을 하는 클래스와 함수의 묶음.

helper 에는 하나만 리턴 하는 함수.

이렇게 분류해서 쓰고있습니다.

하실 수는 있으나 굳이 그렇게까지 할 필요가 없습니다.

보통은 메뉴 하나가 컨트롤러 하나에 대응합니다.

하나의 컨트롤러에 담기 힘든 정도면 컨트롤러 디렉토리를 나누고 컨트롤러를 세분화 하는 정도로 진행하시면 됩니다.

kaido //답변감사합니다 저도 사견이라는 쪽에다 무게를 싣고 다시 설계해봐야겠습니다 ㅠ

변종원 // 컨트롤러 안에 디렉토리를 만드는건 생각해보지 않았네요.. 한번 방법을 찾아봐야겠습니다. 감사합니다!

참고로 사이트의 메뉴.. GNB 작업을 위해서 상속을 떠올리셨다면 접근 방법을 너무 어렵게 잡으셨다는 사견도 남겨드립니다.

흔히 메뉴는 크게 2종류 타입이고, 메인 메뉴는 header 에 들어갑니다.

이건 그냥 view 파일에 넣으면 되니 딱히 큰 문제가 없습니다.

또하나는 로컬 타입의 메뉴가 있는데, 컨트롤러 마다 메뉴가 완전히 달라지거나 하는 경우.

이럴때는 helper로 빼서 만듭니다.

그리고 호출은  view에서 하는 거죠.

하드코딩 타입이 아닌 DB에 코드를 물려서 만들어야 된다거나 할때도  helper 에서도 DB 호출 가능하니 문제 없습니다.

경험은 쌓으면 됩니다 ㅎㅎ

디자인 패턴 책에도 상속을 얼마나 잘하고 잘 설계해야 하는지 끊임 없이 강조를 하다가 마지막 장에 써있는 말이

"적재적소. 달랑 한 문장 출력 하려고 복잡한 패턴 쓸거 없이 그냥 출력 하면 된다."

라고 나와있습니다.

java의 문법은 그 자체만으로 이미 하나의 패턴의 완성체 입니다.

그런데 String [문자 타입 변수 선언] 이라는 녀석은 java의 디자인 패턴의 철학을 철저하게 무시하는 근본 없는 타입 입니다.

이유는 '사용자가 편하게 사용하라고' 만든 겁니다.

아무리 좋은 개념도 편의성을 넘을 수 없습니다 ㅎㅎ