나는 짧은 스터디에서 이렇게 다양하게 이야기 하고 기록하고 있다는 것 자체가 놀랍네요~ ^^

의견을 올린다면.. interface 는 명세라는 정의에 동의 합니다. 그리고 논의 주제를 language 에서 사용하는 interface(키워드) 인지 디자인 측면에서의 interface 인지를 먼저 정하고 시작해야 합니다. 두가지 시점에 얽히다 보니 서로 다른 얘기를 하는 의견이 있을 것 같네요. 즉! 두가지 측면에서 논의 되어야 합니다.

1. 디자인 측면 디자인 측면에서 보면 명세입니다. 즉, 클래스 정의에서 상대방에게 노출하는 행위의 명세이죠. 모든 클래스 들은 자신의 인터페이스를 가지고 있습니다.

2. 랭귀지 측면( 자바 ) 랭귀지 측면에서 보면 interface 도 클래스의 일종이고 생성이 불가능하다는 의견이 나올수 있습니다. 그러면 왜 이렇게 만들수밖에 없었을까를 생각해 보는 것도 좋을 것 같습니다.

전에 윤신이가 올린 글에도 장황하게 비슷한 내용이 있었던 것 같은데... 그 글의 참조가 더 나을듯 하네요..

Interface는 명세이지 객체가 아니다. - 동의합니다.

객체는 상태와 행위를 가져야 하는데 Interface는 행위만을 정의하고 있다. 상태는 없기 때문에 객체가 아니다. - 동의합니다. 행위를 정의하는 게 아니라 선언하는 거죠. (C 언어에서는 민감한 부분... ^^)

객체는 클래스를 통해 생성되는데 Interface를 통해 객체를 직접 생성할 수 없기 때문에 객체가 아니다. - 뭔가 말이 이상하네요. 그냥 인스턴스로 생성 안되기 때문에 객체가 아니라면 동의

Interface는 자바의 Object 클래스도 상속하지 않고, Type 정의할 때도 Class가 아닌 Interface를 사용하지 않느냐? 그러므로 객체가 아니다. - 좀 논점을 알기 힘든 말이네요. 자바에서는 클래스도 Type이죠. Object를 상속하지 않으니 객채가 아니라는 말도... 객체가 아니니 Object를 상속하지 않는다고 하는 쪽이 더 맞을 듯... 귀납적 접근일까요? ㅎㅎ

디자인 측면에서 바라보면 Interface는 객체이다. 하지만 구현 측면으로 접근했을 때는 객체가 아니다. - 이해 안 되는 말이네요. 디자인 측면에서 왜 인터페이스가 객체라는 거죠?

정작 제가 하고 싶은 말을 안 했네요. 인터페이스가 객체냐는 질문 자체가 이상합니다. 그러니까... 일단 객체라는 말을 다들 어떻게 이해하는지도 불문명하달까요. 그냥 간단히 말하면 인터페이스는 객체를 구성하는 일부라고 할 수 있겠다 싶네요. 객체의 명세 부분만 별도로 분리해서 타입으로 사용할 수 있도록 만든 언어적 장치...

요구사항 1: 수정할 수 있게 해 주삼 요구사항 2: 트랙백할 수 있게 해 주삼 요구사항 3: 글 쓰면 SNS에도 등록되게 해 주삼

@fupfin 요구사항 좋은데요? ㅋㅋㅋ

객체에 한표.

public interface Human extends Mammal{...}

private classs JhangJhinDhal implement Human extends Parents {...}

객체가 아닌게있나? (물론 객체를 어느 관점으로 보느냐에 따라 달라질수는 있다만..)

@jhindhal.jhang 객체의 정의부터 시작해야겠군요.. 이 논의는 ㅋㅋㅋ

@짱가 다들 OOP를 생각 하지 않고 Java를 생각하면 틀린답들이 나올듯 Java는 OOP를 50%도 구현못한 프로그래밍 언어입니다.

@fupfin 요구사항 감사합니다.

• 요구사항1은 최우선 순위 업무로 등록되어 있습니다. 이번주 내로 개발 후 배포 예정임다. 최근 답변 패턴을 보니 반드시 있어야 겠다고 느낌. https://github.com/javajigi/slipp/issues/54

• 요구사항2의 트랙백은 고려하지 못했는데 등록해 놓을께요. https://github.com/javajigi/slipp/issues/55
• 요구사항3은 좀 더 고민해 볼께요. 질문할 때는 SNS 등록 기능을 고려하고 있는데요. 답변까지도 그렇게 할 것인지는 고려하고 있음다. 이 부분은 좀 더 고민해 볼께요. 일단 facebook과의 연동만 고려하고 있어요. https://github.com/javajigi/slipp/issues/32

인터페이스에 대한 의견도 감사요. 일단 스터디에서 나온 이야기들을 생각나는데로 올려봤어요. 온라인상에서 맞던 틀리던 더 많은 이야기가 이루어지고 한번쯤 고민해 봤으면 하는 마음입니다.

@jhindhal.jhang 오호라. "Java는 OOP를 50%도 구현못한 프로그래밍 언어"이다. 이거 처음 듣는 내용인데 좀 더 구체적으로 이야기해 주면 좋겠다.

만약 OOP를 제대로 배우고 싶으면 smalltalk 같은 언어를 배우라던지 그런 이야기도 좀 해주고... 그냥 그렇게 간단히 이야기해버리면 대부분의 프로그래머들은 납득이 안되잖아. 납득이 안돼. 납득이...

delphi로 정리된 글이 있습니다. 역시 객체 정의부터 시작합니다. @fupfin 님 의견과 같은 내용으로 보입니다. http://www.gekko-software.nl/Delphi/Art04.htm

이런 논의에서는, 정의해야 할 이야기가 한 두 가지가 아닙니다.

Object? (Java Object를 의미하는지, OOP 일반적인 영역의 Object를 의미하는지.)

Interface? (Java Interface를 의미하는지, 프로그래밍 일반적인 영역의 Interface를 의미하는지.)

및, 행위, 상태, 타입 등의 용어 정의가 한정되지 않으면, 논의가 산으로 가는 경향이 생겨요. (물론, 거기서 얻는 것도 많습니다. ^^)

일단, Java Interface 는 Java Object 와 구분해서 사용합니다.

• http://docs.oracle.com/javase/tutorial/java/concepts/interface.html
• http://docs.oracle.com/javase/tutorial/java/IandI/interfaceAsType.html

하지만, 재밌는 주제이긴 하네요.

아, Java Interface 에는 상태 정의가 가능합니다. (문법 상 문제 없습니다.)

• http://docs.oracle.com/javase/tutorial/java/IandI/interfaceDef.html

권위가 떨어지지만, 흥미 위주로 본다면 Wikipedia 문서도 읽어 볼 만 합니다.

• [http://en.wikipedia.org/wiki/Interface_(Java)](http://en.wikipedia.org/wiki/Interface_(Java))

추가로 생각해 볼 꺼리를 던져 보자면, 다음 상황은 어떤 것으로 봐야 할까요?

• http://stackoverflow.com/questions/4000062/can-we-create-an-object-of-an-interface

@자바지기 OOP라는 조건이 아래와 같다 1. Encapsulation/Data Hiding 2. Inheritance 3. Polymorphism 4. Abstraction 5. All predefined types are objects 6. All operations are performed by sending messages to objects 7. All user defined types are objects.

그리고 일단 Java에선 primitives 가 존제를 한다. 그리고 이 이슈처럼 interface라는 어중간한 넘이 있는것도 문제다. 네 말대로 smaltalk이 java보다는 OOP에 가깝다고 볼수있을건데 내가 알기로는 아직 OOP를 완전히 구현한 언어는 없는것으로 알고 있는데... 한 15년전 Java관련 논문에서 본 자료라 지금은 찾을 수가 없네... 그 논문에서는 pure OOP 언어가 있다면 현실세계를 100%로 구현할수 있어야 한다고 되었던 기억이...

. 객체는 상태와 행위를 가져야 하는데 Interface는 행위만을 정의하고 있다. 상태는 없기 때문에 객체가 아니다.

이건 좀.. 속성만 가지고 있는 실체는 객체가 아니다로 정의되기 땜시...

java language 로 보면 인터페이스는 Object를 상속 하지 않기 때문에 별개로 볼 수 있지만, 그냥 개념적 설계에 있어서는 객체로 보는게..

@자바지기 아 곰곰히 생각 해보니 내가 착각 한 부분이 있는데 C++ 가 OOP를 50%(정확한 수치는 모르겠다)정도 구현했고 자바가 75%로 나왔던것으로 기억이 떠오르네...아마 거기서는 OOP의 정의에 몇개가 위반되느냐로 따졌던것 같다. java는 다중상속의 문제도 있었는데 다중상속을 하지 않고 다중구현으로 대체 하기위해 결국 interface를 내놓은것이고 ...

난해할 수도 있는 글이지만,, http://rsmer.tistory.com/category/%EA%B0%9C%EB%85%90 에 있는 실체 부분의 정의를 참고하실만 합니다.

@jhindhal.jhang 다중상속을 하지 않고 다중구현을 위해 interface를 만듬. 정말 엄청 오랜만에 다시 상기하게 되는 글이네요. 예전에 java를 찬양하시던 C++ 개발자님께서 하시던 말을 얼핏 들었던게 기억났어요 ㅋㅋ

어제 논의 되었던 "인터페이스 가 객체인가?" 에서 말하는 인터페이스는 자바에서 interface 키워드로서 표현되는 코드를 대상으로 한정되어 말한것으로 생각이 됩니다.

"객체는 상태와 행위를 가져야 하는데 Interface는 행위만을 정의하고 있다. 상태는 없기 때문에 객체가 아니다." 동의합니다. 설계이지 실체화 되지 못했기 때문이라고 생각합니다. 다른 관점 아니 바라보는 자에 따라서 객체라고 말 할 수도 있을 것 같긴 하지만(컴파일러 ??) ..... @eclipse4j "속성만 가지고 있는 실체는 객체가 아니다로 정의" java interface 에 속성을 선언 할 수 있을 뿐이지 그것이 인스턴스 화 되기 전까지는 실체화 되지 않았기 때문에 interface 는 실체로 볼 수 없지 않을까요?

컴파일러가 답을 단다면 Interface 가 행위를 설계하는 도면으로 보고 실체가 있으므로 객체라고 볼 수는 있지만.....

```interface TestA {

String STR="STR";

}

public class Test { public static void main(String[] args) { System.out.println(TestA.STR);

} }```

앗??? 여기에서 new 로 인스턴스화 시키지 않았는데도 문자열이 출력되네요... 그렇다면 단순한 정의가 아니라 TestA가 속성을 가지고 있다는..

갑자기 C++ 의 가상메서드(인터페이스로 보아도 무방한가요??)가 생각나네요... 가물가물하지만 이것이 실체를 가지고 특정한메모리영역(어디지??)에 상주한다고 알고 있는데......

@jhindhal.jhang 자바가 부족한 OOP언어인 이유로 거론하신 primitive type은 동의합니다. 하지만 인터페이스는 지극히 OOP적인 장치입니다. Smalltalk과 달리 정적 타이핑 언어인 자바에서 메시지를 타입화하려면 인터페이스가 아주 유용하죠. 오히려 자바에 인터페이스가 없었다면 C++와 같은 수준으로 떨어졌을 겁니다.

그리고 나열하신 OOP의 조건은 근거가 뭔가도 묻고 싶습니다.

여기는 조금 딱딱하게 논쟁해도 되지 않나 싶어서 담백하게 글을 썼습니다.

@fupfin 1. Java에서는 다형성과 상속성의 구현을 위하여 interface를 두게 되었죠. C++에서는 다중상속으로 처리하였는데 여기서 다이아몬드 문제로 인하여 Java에서는 Interface를 채택 하게 됩니다. 저의 의견은 꼭 Interface를 두는 방식으로 처리하는것이 최선이 였나? 하는 것입니다. OOP적 프로그래밍 언어를 구현하기 위하여서 Interface라는 놈 대신 상속class형식을 하되 계층형(level정보를 가지는) 도구를 둘수도 있다고 생각 됩니다. 이럴경우 다이아몬드 문제도 해결하면서 상속성, 다형성을 만족 시켜줄수도 있다는 것입니다. 예전 lax and yacc 로 한번 compiler를 만들때 구상했던 계념인데요 class의 상속을 단방향 multi tree형식으로 구현했던 것인데요. 물론 이게 완벽하다고는 할수없지만 Interface가 정답이라고는 생각이 않들었던 것입니다.

1. 제가 나열한 OOP의 조건은 기본 조건에서 제가 좀더 객체지향적인 부분이 고려되어야할 것같다는 것을 적은 것입니다. (딱히 근거는 없습니다. 제가생각하는 OOP의 조건들이니까요) - 어떤 이들은 재사용성 까지도 넣기도 하니 이런 개인적인 판단이라고 생각해주시면 될듯 합니다.

@jhindhal.jhang

1. 자바의 Interface를 다이아몬드 문제 해결을 위한 장치로만 해석하는 건 조금 소극적인 이해 아닌가 싶습니다. 예를 들어 자바의 Interface는 Objective-C의 Protocol과 아주 유사하기 때문입니다. 즉 본문에도 나와 있는 (객체에 전달 가능한 메시지의) 명세 성격 말이죠. 전 이 부분 때문에 자바의 인터페이스가 자바를 (메시지 전달을 중심으로 한 스몰토크식 프로그래밍 패러다임인) OOP답게 하는 장치라고 봅니다.

2. 예. 그렇군요. 저는 (역시 개인적으로) OOP의 핵심 특징은 이 정도라고 생각합니다.

• Encapsulation/Data Hiding
• Polymorphism
• Abstraction
• Dynamic Dispatch

@yangwansu 저...저교! 아저씨! 여기서 이러시면 안 됩니다.

Interface에 정의한 값은 static final이 묵시적으로 정의됩니다. 한마디로 클래스 상수죠. 클래스 상수는 상태가 아닙니다.

1. 인스턴스별로 다른 값을 가지지 못합니다.
2. 변경이 불가능 합니다.

경고! Proof Of Concept 코드 입니다. 따라하지 마세요.

import java.util.HashMap;


interface TestA {
    String STR="STR";
    HashMap<String, String> sample = new HashMap<String, String>();
}


public class InterfaceTest {
    public static void main(String[] args)
    {
        System.out.println(TestA.STR);
        TestA.sample.put("test", "test");
        System.out.println(TestA.sample.get("test"));
    }
}

물론 static final의 헛점을 이용한 장난입니다. ㅎㅎ 아까 위에서 언급했던 링크에 적혀 있어요. 상수 용도로만 쓰라고.

@fupfin ㅎㅎ 성철님 안녕하세요. 성철님이 더 아저씨 잖아요 ㅋㅋ

final static 인 것은 당연 한것이고요.

제가 말하고 싶은 것은 TestA가 인터페이인데 new 로 인스턴스화 시키지도 않아도 STR 에 접근 가능한데 객체는 상태와 행위를 가져야 하는데 Interface는 행위만을 정의하고 있다. 상태는 없기 때문에 객체가 아니다. 라는 말과 같이 생각해 보았을때 어랏 행위만 정의 한 것이 아니고 멤버를 가질 수도 있구나 하고 생각이 들어 객체로 볼 수도 있지 않을 까? 라는 의도였어용...

아 ~ 상수는 멤버가 아니네요 ㅎㅎ 여기서 이래서 죄송 (__)

앗 전 interface에서 전역변수 안 되는줄 알아는데... 하여간 객체입니다. Uml에서 인터페이스도 객체로 표현하기 때문입니다.

1. 인터페이스는 다중 상속을 지원하기 위해 들고 나온것인가?
   위에서 언급되었듯이 다중상속을 지원하기 위한 대안으로 나왔다기 보다는 포로토콜 명세서로의 성격이 더욱 강하다. 반드시 해야 할 일을 정의하고 이를 꼭 구현하여 특정 능력을 가질 수 있게 만들어 줌으로써 이런 기능을 가지고 있는 그룹의 성격을 이용하여 클래스와 비슷하게 묶음(?)으로써의 능력을 가진다.

2. 인터페이스는 객체인가? 프로그래밍 레벨에서 말하는 객체(instance) 와는 달리 개념 설계적 레벨에서 말하는 객체 (Object)는 정의하기에 따라서, 추상화 레벨에 따라서 다를 수 밖에 없다. 현실세계에 존재하는 모든 객체를 프로그래밍하기 위한 컴퓨터의 가상 세계로 매핑하면서 필요에 의한 속성 및 행위를 추상화하여 클래스 및 인터페이스를 만든다는 측면에서 본다면 클래스와 인터페이스를 굳이 분리하지 않고 생각할 수 있다. 그러나 이를 구현하는 입장에서 본다면 객체(instance - 구분하기 위해 실체로 말할 수 있다)라는 것은 자신만의 유니크한 identity와 상태 정보를 가지고 있어야 한다는 전제에 따라 인터페이스로는 객체를 생성할 수 없다는 결론에 도달하게 된다. (결론의 전제로는 객체는 상태정보를 가질 수 있다는 것이 아니라 유니크한 identity를 가진다는 것을 인식해야 한다. 즉, 상태정보가 같더라도 객체를 서로 구분할 수 있어야 한다는 것이 전제조건이다.)

interface는 객체인가? 라는 질문은 좀 생뚱맞군요.

제가 설명하는 식으로 표현을 해보도록 하겠습니다. (전 사실 어렵게 말하는 것을 잘 못해요.)

프로그램을 만드는 과정을 생각해 본다면, 내가 어떤 기능의 프로그램을 만들어야 할지를 고민하게 됩니다. 그 고민을 하다보면, 화면은 어떻게 만들어야겠다. 어떤 기능이 있어야 겠다. 다른 회사시스템과는 어떤 정보를 교환해야 겠다. 등의 생각을 하게 됩니다.

이때 나올 수 밖에 없는 것들이 있는데, 그것은 보여지는 내용입니다. 이것을 사용자 인터페이스(User Interface)라고 말을 하죠. 그리고, 외부 시스템과 만나는 부분은 시스템 인터페이스(System interface)라고 합니다. 그리고, 비지니스에 대한 기능에 대한 정의는 비지니스 인터페이스(Business interface)라고 말합니다.

쉽게 말하면 껍데기이죠. 어떤 제품이든 껍데기가 있습니다. 그렇다고 껍데기만 있다면 그게 물건으로써의 구실을 할까요? 아마 못할꺼에요. 껍데기를 정했다면 그 안을 어떻게 만들지를 결정해야 합니다.

보여지는 겉모습은 비슷해도, 그 안의 모습은 다를 수 있죠. 가 안의 모습을 결정짓는 것이 알맞은 구조 즉 아키텍처입니다. 아키텍처에 따라서 그 안의 모습이 다르게 구현될 수 있는 것입니다.

그렇다면 껍데기가 나왔다는 것은, 그 껍데기를 알맞게 구현하기 위하여 아키텍처가 정의되고 그 아키텍처에 맞도록 설계가 되어야 합니다. 그 설계대로 만들어진 것은 설계도가 되겠죠.

그럼 그것은 객체인가? 설계도를 가지고 실제로 제품을 만들었을때 우리는 그것을 물체라고 이야기 합니다. 이 물체를 instance라고 말하기도 하는데 이것이 객체인 것이지요.

interface나 설계도를 객체라고 말하지는 않는다고 생각합니다.

interface가 객체냐? 라는 질문에는 아니다. 라고 말합니다.

그럼 interface는 무엇이냐? 설계를 위한 명세이자, 실제 객체를 사용하기 위한 접점이라고 말하고 싶습니다.

@김성박 동의합니다. 그리고 갑자가 비유를 보니 사람에게 있어 페르소나라는 것이 객체에게서 인터페이스와 유사하지 않을까 생각이 드네요. ㅎㅎ 뜬구름 같은 얘기였습니다. http://ko.wikipedia.org/wiki/%ED%8E%98%EB%A5%B4%EC%86%8C%EB%82%98_%28%EC%8B%AC%EB%A6%AC%ED%95%99%29

저는... 그렇게 굴레에 가둬 놓는게 크게 의미가 없다고 생각합니다.

java == oop 가 아니라서 oop 의 모든 개념이 1:1 대응이 되지 않잖아요... 꼭 1:1 이 아니라고 해도, 아무튼...

어떤 객체지향 언어에서는 +, - 같은 연산자도 객체인 반면 자바는 아니죠. (이걸 굳이 연산자라고 하는 것도 과거 언어로 인한 관습?) 래퍼 클래스가 있다고는 하지만 자바에는 primitive type 이 존재하고 여기에 행위는 없습니다(래퍼 나온 이후에는 1.equals(...) 가 되던가? 확인은 안 해 봤습니다. 그 이전에는 될 수 없었지요).

아무 생각 없이 1 + 2 와 "abc" + "def" 를 사용해 왔지만 이 두 가지 경우 전혀 다른 연산자입니다. 연산자라는 말을 쓰고 있지만 무엇이 되었든...

그냥, 인터페이스는 인터페이스 그 자체로 이해하는 것이 맞지 않을까... 굳이 객체인지 아닌지 구분할 필요 없이요.

자바 언어 명세서(http://docs.oracle.com/javase/specs/)를를) 확인해 봤습니다. 명세서에서는 다음과 같이 명세되어 있습니다.

4.3.1 Objects
An object is a class instance or an array. 
...
A class instance is explicitly created by a class instance creation expression (§15.9).
An array is explicitly created by an array creation expression (§15.10).

--덧붙이는 글-- 문득 abstract class 가 생각나는군요.

@greatkit OOP가 명확하게 정립된 개념이 아닌 이상 자바가 OOP 언어가 아니라는 말은 조금 수정할 필요가 있습니다. 순수 OOP 언어가 아닐 뿐 훌륭한 OOP 언어인 건 맞다고 생각합니다. 그리고 설사 자바가 OOP로 부족함이 있다고 해도 Interface가 어떤 의미인지 논의하는 게 의미 없는 일이라고 여겨지지는 않네요. 그를 통해서 인터페이스와 객체의 의미를 조금 더 분명히 알 수 있다면 말이죠. 저도 인터페이스가 객체냐는 질문이 패쇄적인 대답을 유도한다는 의미에서 문제가 있다고 생각하지만 논의 중에는 좋은 내용이 많이 나온 것 같습니다.

@fupfin 제가 오해하게 썼네요. java != oop 로 보이기 쉽겠군요. oop 를 실현한 언어는 맞는데 oop 그 자체가 아니라는 말을... 너무 멋대로 줄여 써버렸네요.