1	비공개 손님 … 2018-04-17 18:58:57
	상속은 타입을 공유하기 위한 것이지, 코드를 공유하기 위한것이 아닙니다.

2	비공개 손님 … 2018-04-17 18:59:44
	코드 공유를 위한 패턴은 Utils 이나 Helper 같은 클래스로 대체하는게 좋아요.

3	비공개 손님 … 2018-04-17 20:33:17
	호옹이 utils 는 뭔가 fileUtils 같은 느낌으로다가 쓰고 있긴한데 helper는 그 도메인에 쓰는 static 말고 new 하는 개념 같은건가요? 예를 들어 파서를 만드는데 네이버 파서 다음 파서 다 비슷한데 중간이나 뒤에 코드 몇개만 바꾸면 되는 100줄 짜리 메소드가 있다고 하면...

4	비공개 손님 … 2018-04-17 22:29:32
	프로젝트를 고도화한다면 네이버 파서와 다음 파서의 공통으로 사용될 메소드들을 인터페이스로 빼고, 파서 프로세서(가칭)라는 새로운 클래스의 생성자에 주입을 하고, 파서 프로세서에서 실질적인 실행을 하게 만들죠. 이런 식으로 하면 다음에 구글 파서, 알지롱 파서만 만들어서 원하는 순간에 파서 프로세서에 주입만 해주면 됩니다. 파서 프로세스는 일종에 모든 사이트들을 파싱하는 프레임워크가 되는 거죠. 즉 100줄짜리 메소드가 있다면 이 메소드는 파서 프로세서에서 구현되어야 할 것 같습니다. 하지만 꼭 이러한 방식이 정답은 아닙니다.

5	비공개 손님 … 2018-04-17 22:47:06
	4// 굳이 abstract 안쓰고도 interface 만으로도 공통하나에 구현이 되는거네요~

6	비공개 손님 … 2018-04-18 09:47:12
	https://arload.wordpress.com/2009/02/18/misconception_of_gof_dp/ 읽어볼만한 떡밥이네요 (한글입니다)

7	비공개 손님 … 2018-04-18 10:10:41
	저는 utils 는 public static 들만 모아두고요 helper 는 internal static 모음 또는 internal instance 로만 활용해요. 물론 이게 정답은 아닙니다.

8	비공개 손님 … 2018-04-18 10:27:30
	공통으로 쓰더라도 변형할일이 없는 놈들은 따로 모아서 관리하는게 장기적으로 합리적이지 싶읍니다

9	비공개 손님 … 2018-04-26 17:56:45
	럭키님이 혼자 설계도 하고 개발도 하신다면 interface 딱히 안만드셔도 됩니다 아키텍쳐가 지좇대로 만드는 개발자들을 금제하기 위한 족쇄같은겁니다

10	비공개 손님 … 2018-04-26 18:08:40
	9 저를 족쇄하지 않으면...무슨일이 일어날지 후후 내일의 나를 파.괴.한.다(어제의 나야 무슨 코드를 짠거야?! ㅁㄴㄹㅇ)

11	비공개 손님 … 2018-04-26 18:10:36
	근데 앱스트랙트 클래스 왜 있는거죠?! 인터페이스 보다 할줄아는거라곤 코드 몇줄 더 구현하는게 다인데...공통코드 용 말고는 아무 장점이 없다고 생각했었는데...

12	비공개 손님 … 2018-04-26 18:35:16
	타입공유랍시고 공통구현 하나도 없는거만 만들면 비효율적이니까.. 자동차 - 가솔린엔진차/디젤엔진차 클래스 관계 생각해보세여 '연료 연소' 라는 공통메소드를 어디에 넣는게 좋을지, 아이면 이걸 헬퍼로 별도클래스로 밸경우 가솔린엔진차 상속한 소나타 그랜저 아반떼 이런놈들 가솔린 연료연소 메소드를 매번 어딘가에서 땡겨오는게 나을지 아니면 상위구현을 가져다쓰는게 좋을지.

13	비공개 손님 … 2018-04-26 18:36:22
	근데 여기서 혼동하면 안되는게 여기서 발생하는 코드공유는 가솔린엔진차 라는 타입의 공통된 행위를 집대성한 것이지 개별구현이 귀찮으니 한군데 모아두는 성질의 것이 아니라는거

14	비공개 손님 … 2018-04-27 00:49:27
	멍키님이 잘 설명해주셨는데, 좀 더 쉽게 풀어보자면 럭키님이 자동차를 만들고 있습니다 그리고 다른 사람은 오토바이를 만들고 있다고 가정하죠 그런데 둘다 엔진이 필요합니다 여기서 엔진을 럭키님도 만들고, 오토바이 만드는 사람도 만들고 둘다 만들면 좋겠지만 이것은 낭비죠 같은 것을 둘다 만들 필요는 없으니까요 그래서 엔진은 또 다른 개발자가 만들어서 제공하기로 했습니다 그런데 이미 럭키님은 자동차를 구현하기 위해 자동차 클래스를 상속 받았습니다 그러면 엔진을 연결할 방법이 요원하죠 그래서 인터페이스를 사용해서 해당 엔진을 끌어다가 쓴다고 보시면 됩니다(extends, implement) 클래스간 연결기능을 제공해준다고 보시면 됩니다 (그냥 다중 상속이 안되는 병신이라서 하나 더 만든거에요..) 그리고 멍키님이 집대성했다고 하신 표현은 이런 엔진이라는 인터페이스를 정의하면 모든 엔진류는 그 안에서 찾을 수 있다는 말과 같습니다 따라서 엔진이 필요하면 해당 인터페이스만 찾으면 되는거죠 나중에 인터페이스가 많아지면 찾아다 붙이는것도 일입니다 그러니 이것을 나름의 인덱스화 하는거죠 또 한가지 이 인터페이스를 가져다 쓸려면 어떻게 써야하는지를 알아야 하기때문에 인터페이스는 만들때 인풋과 아웃풋 데이터를 미리 정의 합니다 그래야 자동차 만드는 럭키님이나 오토바이 만드는 개발자나 엔진을 어떻게 붙이는지 알 수 있기 때문이죠 (예를 들면 엔진 타입코드와 기통수를 입력하면 해당 엔진 객체를 리턴해준다던가 하는 식의..) 그래서 이 인터페이스는 프로젝트를 설계할때 아키텍쳐가 미리 만들어서 제공해야 합니다 하지만 요즘 인터페이스 쓰는 꼬락서니들을 보면 그냥 프레임워크가 그렇게 돼있으니 아무생각없이 만들어서 쓰는 사람들이 너무 많아요 그러니 다른 언어들 개발하다가 온사람들이 그렇게 자바욕을 하죠..

15	비공개 손님 … 2018-04-28 11:09:31
	앱스트랙트 클래스는 내부에 자료를 저장하는 멤버를 가질 수 있습니다. 하지만 인터페이스는 그러지 못하죠. 앱스트랙트 클래스는 엄연히 클래스이지만 인터페이스는 클래스가 아닙니다. 자동차를 예를 들면, 앱스트랙스 클래스는 [남은연료량], [주행거리], [베터리량] 등을 저장할 수 있는 멤버를 가질 수 있고, 시동걸기() 메소드를 구현하려고 보니 어떤 자동차는 버튼을 눌러서 걸고, 어떤 자동차는 키를 꼽아 돌려서 걸고... 아 씨 모르겠다, 이건 이 자동차 클래스를 상속 클래스 구현하는 개발자가 내부로직을 만들어서 오버라이딩 해서 써! 이런 느낌이고요. 인터페이스는 [남은연료량] ? 이거 전기 자동차는 없을거 아냐? 암튼 내부 사정은 모르겠고, 자동차가 움질일러면 시동걸기()는 있어야할 거 아냐? 또 속도올리기(), 속도내리기() 정도는 있어야겠지? 그렇다면 이 자동차라는 녀석을 사용하는데가 어딘지는 몰라도 시동걸기(), 속도올리기(), 속도내리기() 는 꼭 사용할 거 같애. 그러니 개발자야, 자동차라는 인터페이스를 구현한 녀석이라면 저 메소드들은 무조건 구현되어 있어야 해! 이런 느낌입니다.

16	비공개 손님 … 2018-04-28 11:11:26
	라고 IDE가 속삭여줍니다.

17	비공개 손님 … 2018-04-29 13:46:38
	앱스트랙트 클래스는 필드를 공유 용이라고 생각하면 될까요? 순서 로직적인것만 앱스트랙트 클래스에 구현해주고 그안에 작은 개별 메소드 들은 실제 구현은 구현클래스에서 구현한다는거죠? 그 작은 개별 메소드들 중에 중복되는 애들은 헬퍼클래스 같은애들로 따로 빼서 구현하고 하면 나이스 한건가요?

18	비공개 손님 … 2018-04-30 02:27:55
	17/ 그러게 생각하시는게 편하시면 그리 하셔도 됩니다. 다만 앱스트랙트 메서드를 이러한 용도로만 써라 하는 법칙 같은 것은 없으니 너무 얽매이지는 않으셨으면 합니다. 분필은 칠판에 긁으면 필기구이지만 던지면 조는 학생을 깨우는 맴매로 사용할 수 있습니다. 코드를 따로 빼는 것도 저는 코드가 3번 이상 중복되면 그때서야 헬퍼로 빼는 걸 고민합니다. 중복 코드를 빼는 이유 중 하나는 나중에 수정할 때 여러군데를 수정하지 않기 위해서 입니다. 그런데 최근 제가 경험한게 A, B 가 공용으로 쓰는 중복 코드를 헬퍼로 빼 두었는데 정책이 A에 해당하는 중복 코드를 수정해달라고 하는 요청을 받아서 결국 다시 복제해서 수정한 적이 있습니다. 또한 기껏 헬퍼로 빼놨는데 그 이후로 더 이상 그 헬퍼 함수를 사용하지 않는다면 이것도 삽질한 거죠. 결국 미래 예측을 잘 하셔서 자주 쓰이는 코드다 싶으면 헬퍼로 빼시는게 맞지 않나 생각합니다. 이런 부분은 정답이 없는 케이스 바이 케이스죠.