인터페이스

Search BackLinks only
Display context of search results
Case-sensitive searching

• 코바용어정리 . . . . 26 matches
       객체의 참조를 유지함으로써 원격 객체를 액세스할 수 있는 node(단어 선택이 부적절한 것 같군 --;;)이다. 즉 객체 레퍼런스를 사용하여 클라이언트는 객체의 오퍼레이션을 수행할 수 있게 된다. 원격 객체를 액세스 하는 과정에 대해 구체적으로 기술하면 다음과 같다. 클라이언트는 언어 맵핑을 통해 객체와 ORB 인터페이스에 액세스할 수 있다. ORB는 구현 객체와 클라이언트 사이의 커트롤 전달 및 데이터 전달 관리를 책임지고 있다. 결국 클라이언트는 언어 맵핑을 통해서 ORB와 상호 작용할 수 있고, ORB는 원격 객체에 대한 레퍼런스를 얻을 수 있게 된다. 이런 방식으로 클라이언트는 분산 환경하에서 객체를 이름과 인터페이스만으로 마음대로 참조할 수 있는 것이다. ORB를 버스라고 생각하면 쉽게 이해할 수 있을 것이다.
       클라이언트의 반대쪽에는 구현 객체라고 알려진 실제 객체가 있다. '구현 객체(Object Implementation)'는 실제 상태(state)와 객체의 반응 양상(behavior)을 규정하며 다양한 방식으로 구성될 수 있다. 구현 객체는 객체의 메소드와 객체에 대한 활성화 및 비활성화 프로시저를 정의한다. 구현 객체는 객체 어댑터의 도움을 받아 ORB와 상호 작용한다. 객체 어댑터는 구현 객체를 특정하게 사용하는 데에 편리하도록 ORB 서비스에 대한 인터페이스를 제공하게 된다. 구현 객체는 ORB와 상호 작용하여 그 정체를 확립하고 새로운 객체를 생성하며 ORB에 따르는 서비스를 획득할 수 있도록 한다. 새로운 객체가 생성되면 ORB에게 통보되고 이 객체의 구현이 어디에 위치하는가를 알게 된다. 호출이 발생하면 ORB, 객체 어댑터, 스켈레톤은 구현의 적절한 메소드에 대한 호출이 되도록 만들어야 한다.
       CORBA는 C++과 Java 같은 객체 지향 언어와 C와 같은 절차적 언어 양쪽 모두에서 사용될 수 있다. 객체 지향 언어에서는 사용자가 객체의 특성을 정의하고 그 프로퍼티에 액세스할 수 있게 해주는 메소드와 인터페이스를 제공한다. 이것은 비객체 지향 언어에는 없는 기능인데, 이것들은 각각
       의 인터페이스 타입에 대해 스텁에 대한 프로그래밍 인터페이스를 필요로 한다. 보통 스텁은 OMG-IDL로 정의되어 있는 객체 오퍼레이션에 대한 액세를 하게 해주는데, 일단 프로그래머가 OMG-IDL 및 특정 프로그래밍 언어에 대한 언어 매핑에 친숙해지면 손쉽게 예상이 가능한 방식으로 액세르를 하게 해준다. 해당 스텁은 ORB 코어에 전용이며 최적화된 인터페이스를 사용해서 나머지 ORB들을 호출하게 될 것이다. 만약 여러 개의 ORB를 사용하게 된다면 각각의 스텁은 제 각기 해당하는 ORB를 호출하게 될 것이다. 이 경우에 ORB와 언어 맵핑은 공조하여 각각의 스텁이 특정 객체 레퍼런스와 제대로 연결될 수 있도록 해야 할 것이다.
       == 동적 호출 인터페이스(DII : Dynamic Invocation Interface) ==
       클라이언트가 호출될 객체와 수행할 오퍼레이션을 지정하고자 할 때, 특정 객체 A의 특정 오퍼레이션을 지정하는 대신 객체 호출을 동적으로 생성하도록 허용하는 인터페이스를 이용할 수 있다. 이러한 경우 클라이언트 코드에서는 수행되는 오퍼레이션과 전달되는 파라미터의 타입에 대한 정보를 제공해야 한다. 이 정보는 대개 인터페이스 저장소와 같은 런타입 소스에서 얻어진다. 실행 시간 중에 해당 정보를 얻은 후, 클라이언트 코드는 이른바 동적 호출 인터페이스(DII)를 이용해서 동적으로 호출을 할 수 있게 된다.
       각각의 언어 매핑에 대해(아마도 객체 어댑터에의 의존하게 되겠지만) 각각의 타입의 객체를 구현하도록 해주는 메소드에 대한 인터페이스가 존재할 것이다. 이 인터페이스는 일반적으로 업콜(up-call) 인터페이스일 것이다. 구현 객체의 개발자는 그 인터페이스에 따라 루틴을 작성하게 되고 ORB는 스켈레톤을 통해서 그 루틴을 호출하게 될 것이다. 그러나 스켈레톤의 존재가 그에 사응하는 클라이언트 스텁의 조재를 의미하지는 않는다는 것이다. 이말은 클라이언트가 DII를 통해서 리퀘스트를 만들 수도 있다는 것이다. 또한, 어떤 언어 맵핑은 스켈레톤을 사용하지 않는데, 이것은 Smalltalk에시는 대체적으로 맞는 말이다.
       == 동적 스켈레톤 인터페이스(DSI : Dynamic Skeleton Interface) ==
       동적 스켈레톤 인터페이스는 IDL에 기초하지 않는 스켈레톤/스텁을 가진 객체의 메소드 호출을 처리해야 하는 서버에 대해 런타임 바인딩 메커니즘을 제공한다. 동적 스켈레톤은 수신된 메시지의 파라미터값을 참조하여 어떤 객체가 호출되었는지 어떤 메소드가 호출되었는지를 알게 된다. 이것은 일반적으로 컴파일된 스켈레톤을 사용하는 것과는 비교되는데 이러한 스켈레톤에서는 메소드의 구현이 IDL로 정의된다. 구현 코드는 모든 오퍼레이션 파라미터에 대한 상세한 설명을 ORB에 제공해야 하며, ORB는 오퍼레이션을 수행할 때 사용되는 입력 파라미터값을 제공한다. 오퍼레이션이 수행된 후, 구현 코드는 출력 파라미터 또는 익셉션을 ORB에게 넘겨준다. 동적 스켈레톤 인터페이스의 특성은 프로그래밍 언어 맵핑에 따라 또는 객체 어댑터에 따라 실질적으로 달라질 수 있지만, 일반적으로는 업콜 인터페이스이다. 동적 스켈레톤은 클라이언트 스텁 또는 DII를 통해서 호출될 수 있다. 이 두 가지 방식의 클라이너트 리퀘스트 생성 인터페이스는 동일한 결과를 제공한다.
       == ORB 인터페이스 ==
       ORB 인터페이스는 애플리케이션에 중요한 지역 서비스에 대한 API들로 구성되어 있지 않다. 이것은 곧바로 ORB로 가는 인터페이스이고 모든 ORB들에 대해 동일하다.ORB 인터페이스는 객체 어댑터 또는 객체 인터페이스에 의존하지 않는다. 대부분의 ORB의 기능이 객체 어댑터, 스텁, 스켈레톤 또는 동적 호출 등을 통해서 제공되므로 몇몇 오퍼레이션만이 모든 객체들에 대해 공통이다. 공통 오퍼레이션에는 get_interface와 get_implementation 같은 함수가 포함되어 있는데, 이것들은 임의의 객체 레퍼런스에 작용하며 각각 인터페이스 저장소 객체와 구현 저장소 객체를 얻는 데 사용된다.
• Gof/AbstractFactory . . . . 18 matches
       구체적인 클래스를 정의하지 않고서, 연관되거나 의존적인 객체집합을 만들수 있는 인터페이스를 제공한다.
       유저인터페이스 툴킷은 다양한 ["룩앤필"] 기준을 제공하도록 고려한다. 다른 룩앤필은 스크롤바, 윈도우, 그리고 버튼처럼 다른 모습과 행동양식의 유저 인터페이스 ["Widget"]을 제공한다. 이식가능한 룩앤필 기준을 위해서는, 개별적 룩앤필 Widget을 위한 어떤 애플리케이션은 ["하드-코드"] 가 아니어야 한다. 즉석으로 정의한 룩앤필 클래스는 나중에 룩앤필을 바꾸기 어렵게 만든다.
       이 문제는 기본적인 Widget의 인터페이스를 정의한 abstract WidgetFactory 클래스를 정의함으로써 해결할 수 있다. 또한 모든 종류의 Widget에는 추상클래스가 존재한다, 그리고 구체적인 서브 클래스는 Widget을 상속해서 룩앤필 기본을 정의한다. WidgetFactory의 인터페이스는 각각의 추상 Widget 클래스의 새로운 객체를 반환하는 기능을 가지고 있다. 클라이언트는 이런 기능을 수행해서 Widget 인스턴스를 만든다. 그러나 클라이언트는 사용하는 클래스의 구체적인 내용에 대해서는 신경쓰지 않는다. 이처럼 클라이언트는 일반적인(?) 룩앤필의 독립성에 의존한다.
       각각의 룩앤필에는 해당하는 WidgetFactory의 서브클래스가 있다. 각각의 서브클래스는 해당 룩앤필의 고유한 widget을 생성할 수 있는 기능이 있다. 예를 들면, MotifWidgetFactory의 CreateScrollBar는 Motif 스크롤바 인스턴스를 생성하고 반환한다, 이 수행이 일어날 동안 PMWidgetFactory 상에서 Presentation Manager 를 위한 스크롤바를 반환한다. 클라이언트는 WidgetFactory 인터페이스를 통해 개개의 룩앤필에 해당한는 클래스에 대한 정보 없이 혼자서 widget들을 생성하게 된다. 달리 말하자면, 클라이언트는 개개의 구체적인 클래스가 아닌 추상클래스에 의해 정의된 인터페이스에 일임하기만 하면 된다는 뜻이다.
        * 클래스 라이브러리를 나누고 싶고, 인터페이스만을 드러내되, 클래스의 동작을 보이지 않고자 할 때.
        * 추상 객체(ProductObject)들을 만드는 기능을 위한 인터페이스를 정의한다.
        * 어떤 객체(ProductObject)를 위한 인터페이스를 정의한다.
        * 추상 인터페이스(ProductInterface)를 수행한다.
        * AbstractFactory에 의해서 정의된 인터페이스와 AbstractProduct 클래스만을 사용한다.
        클라이언트는 추상 인터페이스를 통해서 인스턴스를 다룬다. concrete facoty의 수행에서 산물의 클래스 이름은 차단되어있다.
        UI 예제에서 Motif widgets을 Presentation Manager widgets로 바꾸는 작업을 단지 유사한 팩토리의 객체와 바꿔주고 그 인터페이스를 다시 생성함으로써 행할 수 있다.
        왜냐하면 AbstractFactory 인터페이스는 생산되어질 산물의 집합을 고정해놓기 때문이다. 새로운 산물을 지원하는 데는 factory의 인터페이스를 확장할 필요가 있다
        ET++[WGM88]은 다른 윈도우 시스템(예를 들면, X Windows 와 SunViews)간의 호환을 수행하기 위해서 Abstract Factory 패턴을 사용했다. 윈도우 시스템의 추상 base 클래스는 윈도우시스템의 자원 객체(예를 들면, MakeWindow, MakeFont, MakeColor)를 생성할 수 있는 인터페이스를 정의한다. Concrete 서브 클래스는 특정 윈도우 시스템에 인터페이스를 수행한다.
• Gof/Facade . . . . 18 matches
       서브시스템의 인터페이스집합에 일관된 인터페이스를 제공한다. Facade는 고급레벨의 인터페이스를 정의함으로서 서브시스템을 더 사용하기 쉽게 해준다.
       서브시스템을 구축하는 것은 복잡함을 줄이는데 도움을 준다. 일반적인 디자인의 목적은 각 서브시스템간의 통신과 의존성을 최소화시키는 것이다. 이 목적을 성취하기 위한 한가지 방법으로는 단일하고 단순한 인터페이스를 제공하는 facade object를 도입하는 것이다.
       예를 들기 위해, 어플리케이션에게 컴파일러 서브시스템을 제공해주는 프로그래밍 환경이 있다고 하자. 이 서브시스템은 컴파일러를 구현하는 Scanner, Parser, ProgramNode, BytecodeStream, 그리고 ProgramNodeBuilder 클래스를 포함하고 있다. 몇몇 특수화된 어플리케이션은 이러한 클래스들을 직접적으로 접근할 필요가 있을 것이다. 하지만, 대부분의 컴파일러 시스템을 이용하는 클라이언트들은 일반적으로 구문분석(Parsing)이나 코드 변환 (Code generation) 의 세부적인 부분에 대해 신경쓸 필요가 없다.(그들은 단지 약간의 코드를 컴파일하기 원할뿐이지 다른 강력한 기능을 알 필요가 없다.) 그러한 클라이언트들에게는 컴파일러 서브시스템의 강력하지만 저급레벨인 인터페이스는 단지 그들의 작업을 복잡하게 만들 뿐이다.
       이러한 클래스들로부터 클라이언트들을 보호할 수 있는 고급레벨의 인터페이스를 제공하기 위해 컴파일러 서브시스템은 facade 로서 Compiler class를 포함한다. 이러한 클래스는 컴파일러의 각 기능성들에 대한 단일한 인터페이스를 정의한다. Compiler class는 facade (원래의 단어 뜻은 건물의 전면. 외관, 겉보기..) 로서 작용한다. Compiler class는 클라이언트들에게 컴파일러 서브시스템에 대한 단일하고 단순한 인터페이스를 제공한다. Compiler class는 컴파일러의 각 기능들을 구현한 클래스들을 완벽하게 은폐시키지 않고, 하나의 클래스에 포함시켜서 붙인다. 컴파일러 facade 는저급레벨의 기능들의 은폐없이 대부분의 프로그래머들에게 편리성을 제공한다.
        * 복잡한 서브 시스템에 대해 단순한 인터페이스를 제공하기 원할때. 서브시스템은 종종 시스템들이 발전되어나가면서 더욱 복잡성을 띄게 된다. 대부분의 패턴들은 패턴이 적용된 결과로 많고 작은 클래스들이 되게 한다. 패턴의 적용은 서브시스템들이 더 재사용가능하고 커스터마이즈하기 쉽게 하지만, 커스터마이즈할 필요가 없는 클라이언트들이 사용하기 어렵게 만든다. Facade는 서브시스템에 대한 단순하고 기본적인 시각을 제공한다. 이러한 시각은 대부분의 클라이언트들에게 충분하다. 커스터마이즈가 필요한 클라이언트들에게만이 facade를 넘어서 볼 필요가 있는 것이다.
        * 클라이언트는 Facade에게 요청을 보냄으로서 서브시스템과 대화한다. Facade 객체는 클라이언트의 요청을 적합한 서브시스템 객체에게 넘긴다. 비록 서브시스템 객체가 실제 작업을 수행하지만, facade 는 facade 의 인퍼페이스를 서브시스템의 인터페이스로 번역하기 위한 고유의 작업을 해야 할 것이다.
       그러면 클라이언트는 추상 Facade class의 인터페이스를 통해 서브시스템과 대화할 수 있다. 이러한 추상클래스와의 연결은 클라이언트가 사용할 서브시스템의 구현을 알아야 하는 필요성을 없애준다.
       서브시스템은 인터페이스를 가진다는 점과 무엇인가를 (클래스는 state와 operation을 캡슐화하는 반면, 서브시스템은 classes를 캡슐화한다.) 캡슐화한다는 점에서 class 와 비슷하다. class 에서 public 과 private interface를 생각하듯이 우리는 서브시스템에서 public 과 private interface 에 대해 생각할 수 있다.
       서브시스템으로의 public interface는 모든 클라이언트들이 접속가능한 클래스들로 구성되며. 이때 서브시스템으로의 private interface는 단지 서브시스템의 확장자들을 위한 인터페이스이다. 따라서 facade class는 public interface의 일부이다. 하지만, 유일한 일부인 것은 아니다. 다른 서브시스템 클래스들 역시 대게 public interface이다. 예를 들자면, 컴파일러 서브시스템의 Parser class나 Scanner class들은 public interface의 일부이다.
       parser tree는 StatementNode, ExpressionNode와 같은 ProgramNode의 subclass들의 인스턴스들로 이루어진다. ProgramNode 계층 구조는 Composite Pattern의 예이다. ProgramNode는 program node 와 program node의 children을 조작하기 위한 인터페이스를 정의한다.
       우리가 토론해온 클래스들은 곧 Compiler 서브시스템을 이룰 것이다. 자 이제 우리는 이 모든 조각들을 함께 묶은 facade 인 Compiler 클래스를 소개할 것이다. Compiler는 소스 컴파일과 특정 machine에 대한 코드변환기능에 대한 단순한 인터페이스를 제공한다.
       이 구현에서는 사용하려는 code-generator의 형태에 대해서 hard-codes (직접 특정형태 부분을 추상화시키지 않고 바로 입력)를 했다. 그렇게 함으로서 프로그래머는 목적이 되는 아키텍처로 구체화시키도록 요구받지 않는다. 만일 목적이 되는 아키텍처가 단 하나라면 그것은 아마 이성적인 판단일 것이다. 만일 그러한 경우가 아니라면 우리는 Compiler 의 constructor 에 CodeGenerator 를 인자로 추가하기 원할 것이다. 그러면 프로그래머는 Compiler를 instance화 할때 사용할 generator를 구체화할 수 있다. Compiler facade는 또한 Scanner나 ProgramNodeBuilder 등의 다른 협동하는 서브시스템클래스를 인자화할 수 있다. 그것은 유연성을 증가시키지만, 또한 일반적인 사용형태에 대해 인터페이스의 단순함을 제공하는 Facade pattern의 의의를 떨어뜨린다.
       AbstactFactory 는 Facade구현시 서브시스템 독립적인 방법으로 서브시스템 객체를 만들 수 있는 인터페이스를 제공하기 위해 사용한다. Abstract Factory는 또한 플랫폼 비독립적 클래스를 감추기 위해 Facade의 대안으로서 사용할 수 있다.
       Mediator 는 존재하는 class들의 기능들을 추상화시킨다는 점에서 Facade와 비슷하다. 하지만 Mediator의 목적은 정해지지 않은 동료클래스간의 통신을 추상화시키고, 해당 동료클래스군 어디에도 포함되지 않는 기능들을 중앙으로 모은다. Mediator의 동료클래스들은 Mediator에 대한 정보를 가지며 서로 직접적으로 통신하는 대신 mediator를 통해 통신한다. 대조적으로 facade는 단지 서브시스템들을 사용하기 편하게 하기 위해서 서브시스템들의 인터페이스를 추상화시킬 뿐이다. facade는 새로운 기능을 새로 정의하지 않으며, 서브시스템 클래스는 facade에 대한 정보를 가질 필요가 없다.
• HolubOnPatterns/밑줄긋기 . . . . 16 matches
        * 요즘은 상속과 인터페이스 같은 기능이 많은 언어에 내장되어 있다. 이들은 이디엄이 된 것이다.
        * 인터페이스는 패턴 전체를 도입하는 것과는 달리 그다지 복잡성을 증가시키지 않는다. 반면 기능 변경이나 추가 시 리팩토링이 쉬워진다.
        * 사실 많은 절차 지향적 프로그램은 사용자 인터페이스를 통해 데이터베이스 테이블을 보여주는 역할을 할 뿐이다.
       == 인터페이스로 프로그래밍하기 그리고 몇 개의 생성 패턴 ==
        * 인터페이스 관점에서 프로그래밍 하는 것은 OO 시스템의 기본 개념이며 GoF와 디자인 패턴은 이의 구체적이 예가 된다.
        * 하지만 많은 자바 프로그래머들은 인터페이스를 거의 사용하지 않고 extends 관계를 남용하고 있다.
        * 디자인 패턴은 크게 보면 구현 상속(extends)을 인터페이스 상속(implements)으로 바꾸는 방법을 설명하고 있다.
        * C++을 배우고 자바를 배우면 익숙한 구현 상속을 많이 사용하게 되지. C++에도 인터페이스의 개념이 있지만 시작부터 구체 클래스를 만드는 습관때문에 거의 쓰지 않았었다. - [서지혜]
       === 인터페이스 vs. 클래스 ===
        * 기반 클래스를 수정할 때마다 파생 클래스를 검토해 보아야 한다면 이는 기반 클래스를 확장하고 있는 것이 아니라 인터페이스를 구현하고 있는 것이다.
        * 그러고보니 일일이 오버라이딩할 바에는 인터페이스를 implements하는게 더 나을거같네? - [서지혜]
        * 단순한 클래스 계층 구조는 복잡한 계층 구조보다 만들고 유지 보수하기 쉽다. 또한 인터페이스를 이용하여 구현 상속이 하는 것과 같은 작업을 수행할 수도 있다.
        * Abstract Factory 패턴의 주요 장점은 격리(isolation)이며, 인터페이스를 통해 객체 생성을 가능 하도록 해준다.
        * 자바가 인터페이스에서 static 메소드를 지원했다면 좋았겟지만 현재는 그렇지 않다.
        * 10개의 디자인 패턴을 실제 프로젝트에서 사용하는 것처럼 함께 사용해 볼것이다. 다행히 프로그램이 이해하지 못할 정도로 거대하지는 않다. 클래스와 인터페이스를 모두 합쳐 20개 밖에 되지 않는다.
        * 객체들(Observer)에 주기적으로 클록 틱(clock tick)이벤트를 통지한다. 이 경우는 Universe가 ActionListener 인터페이스를 구현한 익명의 내부 클래스를 통해 이벤트를 받는다.
• Gof/Composite . . . . 14 matches
       Picture 클래스는 Graphic 객체에 대한 포함관계를 정의한다. Picture 는 Picture의 children의 Draw 메소드를 호출하게끔 Draw 메소드를 구현한다. 그리고 Picture는 child와 관련한 명령어들을 알맞게 구현한다. Picture 인터페이스는 Graphic의 인터페이스를 형성하므로, Picture 객체는 다른 Pricture들을 재귀적으로 조합할 수 있다.
        * composition 에의 객체들에 대한 인터페이스를 선언한다.
        * 모든 클래스들에의 기본적인 인터페이스에 대한 기본 행위를 구현한다.
        * 자식 컴포넌트들을 접근하고 관리하기 위한 인터페이스를 선언한다.
        * (optional) 재귀 구조에서의 해당 컴포넌트의 부모 클래스로 접근하기 위한 인터페이스를 정의하고, 적절하게 구현한다.
        * Component 인터페이스중 자식컴포넌트 관련 명령들을 구현한다.
        * Component의 인터페이스를 통해 composition의 객체들을 조작한다.
        * 클라이언트들은 Component 클래스의 인터페이스를 이용, composite 구조의 객체들과 상호작용을 한다. 만일 상호작용하는 객체가 Leaf인 경우, 해당 요청은 직접적으로 처리된다. 만일 상호작용하는 객체가 Composite인 경우, Composite는 해당 요청을 자식 컴포넌트들에게 전달하는데, 자식 컴포넌트들에게 해당 요청을 전달하기 전 또는 후에 추가적인 명령들을 수행할 수 있다.
        * Component 인터페이스의 최대화
       Equipment 클래스는 부분-전체 계층구조의 모든 equipment들을 위한 인터페이스를 정의한다.
       CompositePattern의 예는 거의 모든 객체지향 시스템에서 찾을 수 있다. Smalltalk 의 Model/View/Container [KP88] 의 original View 클래스는 Composite이며, ET++ (VObjects [WGM88]) 이나 InterViews (Styles [LCI+92], Graphics [VL88], Glyphs [CL90])등 거의 대부분의 유저 인터페이스 툴킷과 프레임워크가 해당 과정을 따른다. Model/View/Controller 의 original View에서 주목할만한 점은 subview 의 집합을 가진다는 것이다. 다시 말하면, View는 Component class 이자 Composite class 이다. Smalltalk-80 의 Release 4.0 은 View 와 CompositeView 의 서브클래스를 가지는 VisualComponent 클래스로 Model/View/Controller 를 변경했다.
       CompositePattern의 또다른 예는 각각의 자산들을 포함하는 portfolio인 financial domain 에서 나타난다. portfolio 를 각각의 asset 의 인터페이스를 구성하는 Composite 로 구현함으로써 복잡한 asset의 포함관계를 지원할 수 있다.
        * DecoratorPattern 은 종종 Composite와 함께 이용된다. descorator 와 composite 가 함께 이용될때, 그것들은 보통 공통된 부모 클래스를 가질 것이다. 그러한 경우 decorator는 Add, Remove, GetChild 와 같은 Compoent 의 인터페이스를 지원해야 한다.
• 작은자바이야기 . . . . 14 matches
        * Serializable 인터페이스와 ObjectOutput, ObjectInput을 사용한 직렬화, 역직렬화에 대해 공부했습니다.
        * transient modifier는 VM의 자동 직렬화 과정에서 특정 속성을 제외할 수 있고, Externalizable 인터페이스를 구현하면 직렬화, 역직렬화 방식을 직접 정의할 수 있음을 보았습니다.
        * native modifier로 함수의 인터페이스를 선언할 수 있고, 마샬링, 언마샬링 과정에서 성능 손실이 있을 수 있음을 이야기했습니다.
        * c++에서 상호배제 관련으로 mutex나 critical section같은거 엄청 배웠었는데 자바에서는 synchronized를 이용해서 쉽게 처리할 수 있다는게 신기했습니다. os 수업 들은지 오래 됐는데 멀티프로세스와 멀티스레드 수업을 다시 들으니까 설명을 참 잘 해주셔서 좋았습니다. 함수에만 붙일 수 있는게 아니고 보호자원을 가진 객체를 이용한 synchronized(this){ ... } 같은 부분은 나중에 스레드를 쓸 경우에 참고가 될 것 같습니다. 그리고 인터페이스와 리플렉션을 이용한 초기화를 보니 생각을 잘 하면 구체클래스가 코드에 안드러나게 할 수 있다는 점도 볼만했습니다. -[서영주]
        * 지난시간에 이은 Inner Class와 Nested Class의 각각 특징들 Encapsulation이라던가 확장성, 임시성, 클래스 파일 생성의 귀찮음을 제거한것이 새로웠습니다. 사실 쓸일이 없어 안쓰긴 하지만 Event핸들러라던가 넘길때 자주 사용하거든요. {{{ Inner Class에서의 this는 Inner Class를 뜻합니다. 그렇기 때문에 Inner Class를 포함하는 Class의 this(현재 객체를 뜻함)을 불러오려면 상위클래스.this를 붙이면 됩니다. }}} Iterator는 Util이지만 Iterable은 java.lang 패키지(특정 패키지를 추가하지 않고 자바의 기본적인 type처럼 쓸수있는 패키지 구성이 java.lang입니다)에 포함되어 있는데 interface를 통한 확장과 재구성으로 인덱스(index)를 통한 순차적인 자료 접근 과는 다른 Iterator를 Java에서 범용으로 쓰게 만들게 된것입니다. 예제로 DB에서 List를 한꺼번에 넘겨 받아 로딩하는것은 100만개의 아이템이 있다면 엄청난 과부하를 겪게되고 Loading또한 느립니다. 하지만 지금 같은 세대에는 실시간으로 보여주면서 Loading또한 같이 하게 되죠. Iterator는 통해서는 이런 실시간 Loading을 좀더 편하게 해줄 수 있게 해줍니다. 라이브러리 없이 구현하게 되면 상당히 빡셀 것 같은 개념을 iterator를 하나의 itrable이란 인터페이스로 Java에서는 기본 패키지로 Iterable을 통해 Custom하게 구현하는 것을 도와주니 얼마나 고마운가요 :) 여튼 자바는 대단합니다=ㅂ= Generic과 Sorting은 다른 분이 설명좀. - [김준석]
        * Data 부분을 인터페이스로 분리 - 내부에서 FactoryMethod 패턴을 사용. factory를 통해서 객체를 생성한다. new를 사용하지 않기 때문에 구체 클래스를 숨길 수 있다.
        * JDBC - 각 데이터들에 대한 접근 표준 인터페이스
        * java.sql.driver 인터페이스를 com.mysql.jdbc.driver 클래스로 구현, java.sql.connection 인터페이스를 com.mysql.jdbc.connection 클래스로 구현
        * abstract factory를 잘 쓰기 위해서는 인터페이스에 api가 잘 설계되어 있어야 한다.
        * Statement, ResultSet에 대해서도 마찬가지로 인터페이스를 이용한 abstract factory가 사용됨.
        * strategy 패턴은 인터페이스로 만들어 둔 전략 객체 클래스를 구현(implementation)하는 방식으로 행동을 확장한다.
        * DIP (depencency inversion principle) : 구체클래스를 사용할 때 구체클래스를 직접 사용하지 않고 추상화 된 인터페이스를 통해서 사용하게 하는 디자인 패턴.
        * JPA의 구체 클래스로 eclipse link와 hibernate가 있는데, 각각을 사용할 때 구체 클래스를 통해서 사용하지 않고 JPA 인터페이스를 통해서 사용하도록 하면 나중에 구체 클래스를 바꾸기 쉽다.
• EffectiveC++ . . . . 12 matches
       === Item 18. 최소한의 완전한 클래스 인터페이스를 추구한다. ===
       interface? 클래스를 이용하는 프로그래머가 접근할수 있는 수단을 주는 것이다. 일반적으로 함수들만 이러한 인터페이스 내에 존재한다. 만약 클래스내의 데이타 변들에게 접근을 허용하게 되면 많은 단점들이 생기기 때문이다. (별로 느끼지는 못해 봤다.. ^^;)[[BR]]
       최소한의 완전한 클래스 인터페이스를 추구한다(?) 이말은 클래스내에 군더더기 즉 비슷한 일을 하는 멤버 함수가 존재 하지 않는다는 의미도 된다. 그리고, 그 클래스는 그만큼 복잡하지않을 것이다. 그리고, 최소한의 인터페이스로 이 클래스를 사용하는 사용자가 모든 일(?)을 할수가 있어야한다. [[BR]]
       그런데, 왜 최소한인가? 여러가지 일을 할수 있는 멤버 함수들을 계속 추가해 나가면 안되는 것인가? 대답은 안된다. 왜 안되는 것일까? 당신은 멤버 함수가 10개 있는 클래스와 100개가 있는 클래스중 어떤것이 이해하기 쉽다고 생각하는가? 나 만 쓰려는 클래스가 아닌이상 다른 사용자들이 쉽게 이해 할수 있도록 만들어야 하지 않겠는가? 그렇기 때문에 최소한의 인터페이스를 추구하는 것이다. 그리고, 관리적인 면에서 볼때 적은 함수들을 가진 클래스가 용이하다는 것이다. 중복된 코드라던지 아니면 개선할 것들을 향후에 하기 쉽다는 것이다. 또한, document를 작성한다 든지 할때 적은 멤버 함수들을 가진 클래스 쪽이 용이하다는 것이다. 마지막으로 아주 긴 클래스 정의는 긴 헤더 파일을 초래 한다. 일반적으로 헤더 파일들은 프로그램이 컴파일될 때마다 매 번 읽혀져야 하기 때문에 필요 이상 긴 클래스 정의는 프로젝트 주기 중의 총 컴파일 시간을 갉아 먹는다. 그런 이유들 때문에 최소한의 클래스 인터페이스를 추구하는 것이 좀더 나은 판단이라는 것이다.
       === Item 20. 데이터 멤버를 공용(public) 인터페이스에 포함시키지 않는다. ===
       프로토콜 클래스는 인터페이스를 사용한다. 추상화된 인터페이스만 만들어 헤더에 포함시키는 방법으로 파일간의 의존성을 약화시킨다.
       === 항목 36. 인터페이스 계승과 구현 계승의 차이점을 이해하라. ===
       되도록이면 이런 경우는 가상함수와 클래스의 계층구조를 통한 인터페이스의 활용으로 해결한다.
       자바에서는 상속받을 클래스는 하나만 받을수 있고 인터페이스는 여러가지를 받을 수 있다.
• Gof/Adapter . . . . 12 matches
       클래스의 인터페이스를 다른 필요한 클래스의 인터페이스에 맞게 변환해준다. Adapter 는 서로 호환성이 없는 인터페이스들끼리라도 같이 작동할 수 있게끔 해준다.
        * 이미 만들어져 있는 클래스를 사용하고 싶지만, 인터페이스가 원하는 방식과 일치하지 않을때.
        * 관련성이 없거나, 예측하지 못한 클래스들과 협동하는 재사용가능한 클래스를 생성하기 원할때. 이 경우 클래스들이 호환성을 가지는 인터페이스를 필요로 하지 않는다.
        * (object adapter 의 경우에만 해당) 현재 이미 만들어진 여러개의 subclass가 필요한 경우, 하지만 각각의 서브클래스들에 대한 인터페이스를 하는 것은 비효율적이다. 이 경우 parent class의 인터페이스를 adapt 할 수 있다.
        - 클라이언트가 이용한 domain-specific한 인터페이스를 정의한다.
        - Target의 인터페이스에 따라 객체들과 상호작용을 한다.
        - Adpatee 의 인터페이스를 Target 의 인터페이스에 adapt 시킨다.
       DecoratorPattern은 객체에 대한 인터페이스의 변화없이 객체를 확장시킨다. Decorator 는 adapter보다 더 application에 대해 투명적이다. 결론적으로 DecoratorPattern은 재귀적인 composition을 제공한다. 이것은 순수한 adapter로서는 불가능하다.
• Android/WallpaperChanger . . . . 10 matches
        // this : 서비스 처리의 본체인 run 메소드. Runnable 인터페이스를 구현 필요.
       인터페이스보다 가상 연결을 선호하라
       만약 사용자 인터페이스 루프에서 객체를 할당한다면, 주기적으로 가비지 컬렉션을 강요하게 될 것이고 사용자 경험에 있어서 조그마한 "딸꾹질(거북함)"을 만들게 될 겁니다.
       인터페이스보다 가상 연결을 선호하라
       전통적인 지혜에서는 Map을 사용해야 한다고 할 것입니다. Map 인터페이스를 구현한 어떤 것으로라도 구현체를 바꿀 수 있기 때문입니다. 전통적인 지혜는 전통적인 프로그래밍에는 맞습니다만, 임베디드 시스템에는 그다지 대단하지 않습니다. 인터페이스 참조를 통해 호출하는 것은 명확한 참조를 통한 가상 메소드 호출보다 2배 더 소요될 수 있습니다.
       안드로이드에서는 나쁜 생각입니다. 가상 메소드 호출은 인스턴스 필드 참조보다 더 비용이 높습니다. 일반적인 객체 지향 프로그래밍 관습에 따르거나, 공용 인터페이스에서 getter, setter을 가지는 것은 이치에 맞습니다. 그러나 클래스 내부에서는 언제나 직접적으로 필드 접근을 해야합니다.
       향상된 반복문(때로 "for-each"로 알려진 반복문)은 Iterable 인터페이스를 구현한 컬렉션들을 위해 사용될 수 있습니다. 이러한 객체들로, 반복자는 hasNext() 와 next()을 호출하는 인터페이스를 만들기 위해 할당됩니다. ArrayList의 경우 여러분이 직접 탐색하는 것이 좋을 수 있습니다만, 다른 컬렉션들에서는 향상된 반복문 구문이 명시적인 반복자의 사용과 동등한 성능을 보여줍니다.
       빈 인터페이스 메소드 호출 15
• 코바예제/시계 . . . . 10 matches
       시간 객체에 대한 인터페이스는 ObjTimeServer이며 getTime()이라는 메소드를 가지고 있는데 getTime()는 문자 형식으로 현재의 시간을 반환해 준다. CORBA 객체를 작성하는 첫번째 단계는 인터페이스를 만드는 것이다. 인터페이스는 IDL로 작성되며 인터페이스는 IDL 컴파일러로 컴파일된다. 이 IDL 컴파일러는 기본적으로 사용자가 이용하는(예를들면 VisiBroker) ORB에 포함되어 있는 것이다. IDL로 작성된 인터페이스를 컴파일하면 컴파일러는 두 개의 코드 파일을 생성해 준다. 이 코드 파일들은 각 IDL 컴파일러가 사용하도록 약정된 프로그래밍 언어로 되어 있다. 여기에서 사용하는 ORB는 Java ORB이므로 코드 파일은 Java(Stub, Skeleton)로 되어 있을 것이다. IDL 컴파일러에 의해 생성되는 코드는 프록시 객체(proxy object) 및 스켈레톤 코드이다. 클라이언트는 프록시 객체를 사용하여 IDL로 표현된 인터페이스 타입의 객체 레퍼런스에 대한 호출을 생성한다. 바꾸어 말하녀 프록시 객체는 클라이언트가 작업을 위해 사용하는 대리("stand-in") 객체인데 원격 객체가 마치 지역 객체처럼 보이게 해준다는 것이다. 스켈레톤 코드는 이러한 인터페이스를 지원하는 객체에 액세스하기 위해 사용된다. 생성되는 코드는 위치 투명성을 구현한다. 위치 투명성을 통해 객체 레퍼런스를 변환하여 네트웍 연결을 퉁해 원격 서버로 보내며, 객체 레퍼런스에 대한 오퍼레이션에 따르붙는 파라미터를 ["마샬링"]하고, 이를 객체 레퍼런스가 지시하는 객체의 현재 메소드에 전달하여 메소드를 수행하고 그 결과를 반환하려고 하는 것이다. 바꾸어 말하면 클라이언트는 IDL 컴파일러에 의해 생성된 프록시 객체를 가지고 작업을 하는데, 그것이 마치 지역 객체로 작업하는 것처럼 보일 것이라는 의미이다. ORB와 통신하는 것이 프록시 객체의 임무이며 ORB는 네트웍 연결을 관리하고 파라미터를 실제 서버 함수에 넘겨주며 결과를 리턴한다. 이런 식으로 수행에 대한 투명성을 유지한다.
       위의 IDL을 컴파일하면 스텁과 스켈레톤 코드가 생성된다. 컴파일러가 ObjTimeServer_Skeleton.java라는 이름의 파일을 생성하였으며, 여기에는 서버 쪽에서 사용되는 스켈레톤 코드가 들어 있다고 가정하자. 이제 이 IDL에서 지정된 인터페이스를 갖는 객체를 구현해야만 한다. 이 말은 서버 코드, 즉 구현을 작성해야 한다는 것이다. 그러한 구현 객체 클래스를 작성하기 위해서는 IDL 컴파일러에 의해 만들어진 스켈레톤 클래스와 결합해야 한다. 이 결합은 상속 또는 위임을 사용해서 이루어질 수 이다.
       클라이언트 구현은 기본적으로 다음 세 가지 단계를 통해 이루어진다. 먼저 CORBA 환경, 즉 ORB를 초기화한다. ORB를 초기화한다는 것은 ORB 의사 객체(pseudo-object)에 대한 객체 레퍼런스를 얻게 된다는 것을 의미한다. ORB가 '의사 객체'라 불리는 이유는 그 메소드가 런타임 시스템과의 통신을 통해 라이브러리의 형태로 제공되며, 의사 객체 레퍼런스는 CORBA 인터페이스 오퍼레이션에 대한 파라미터로 전달될 수 없기 때문이다. 그 다음 단계는 객체 레퍼런스를 얻는 것이다. 객체 레퍼런스는 불투명한 데이터 구조이다. 그러나 객체 레퍼런스를 문자열로 바꿈으로써 지속성을 가지게 될 수 있다. 이것은 '객체 레퍼런스의 문자열화'라 불리며, 그 결과 얻어지는 문자열을 일컬어 '문자열화 객체 레퍼런스'라고 한다.(IOR) 이 문자열화 객체 레퍼런스는 원래의 "유효한" 객체 레퍼런스로 다시 바뀔 수 있다. 이 과정은 CORBA, 즉 ORB 인터페이스에서 정의된 두 가지 오퍼레이션 object_to_string()과 string_to_object()를 이용하여 이루어진다. 모든 CORBA 2.0 호환 ORB는 상호 운용 가능한 문자열화 객체 레퍼런스를 실제 돌아가는 객체 레퍼런스로 바꿀 수 있다. 적절한 타입으로 객체의 범위를 줄이면 그러한 결과를 얻을 수 있다. 이러한 오퍼레이션을 'narrow'라 한다. ORB를 초기화하고 객체 레퍼런스를 얻은 후에야 CORBA 프로그래밍은 원래 의도한 표준 객체 지향 프로그래밍처럼 동작하게 된다. 클라언트가 객체의 메소드를 호출하게 되면, 실제로 그 메소드는 원격 객체와 함께 동작하지만 클라이언트가 보기에는 지역 객체와 함께 동작하는 것처럼 보인다.
• Adapter . . . . 9 matches
       클래스 인터페이스를 예상되는 다른 인터페이스로의 변환을 한다. '''Adapter'''는 상이한 인터페이스 때문에 다른 달랐던 클래스의 일을 묶는 역할알 한다.
       이처럼 Adapter가 정의되어져 있다면 Adapter와 Adaptee양쪽의 인터페이스를 이미 알고 있는 셈이다.;그래서 우리는 Shape 메세지를 TextView메세지에 맞추는 해석 과정과 같은 Adapter를 이런 특별한 용도에 맞추어 만들수 있다. 우리는 이런걸 Teilored Adapter라고 부른다.
       Adapter시나리오의 두번째는 Adaptee의 인터페이를 디자인 시간에 알수 없을 때 이다. Adaptee의 인터페이스를 먼저 알수 없기 때문에 우리는 하나의 인터페이스에서 다른 것으로 메세지를 간단히 해석할수 없다. 이런 경우에는 메세지의 변형과 전달의 일반적 규칙에 맞추어 Pluggable Adapter를 사용한다. Tailored Adapter와 같이 Pluggable Adapter도 해석기를 Client와 Adaptee사이의 해석기를 제공한다. 하지만 각각의 특별한 경우를 위한 새로운 Adapter클래스의 정의를 필요하지 않다. Pluggable Adapter가 쓰이는 경우의 상태를 생각해보자
       상호 작용(사용자가 직접 이용하는의미)하는 어플리케이션을 위한 Model-View-Controller(MVC) 패러다임에서 View 객체들(화면상에 표현을 담당하는 widget들) 은 밑바탕에 깔려있는 어플리케이션 모델과 연결되어진다. 그래서 모델안에서의 변화는 유저 인터페이스에 반영하고 인터페이스 상에서 사용자들에 의한 변화는 밑에 위치한 되어지는 모델 데이터(moel data)에 변화를 유도한다.View객제들이 제공되어 있는 상태라서 어떠한 상호 작용하는 어플리케이션 상에서라도 그들은 ㅡ걸 사용할수 있다. 그러므로 그들은 그들의 모델과의 통신을 위해 일반적인 프로코콜을 사용한다;특별한 상황에서 모델로 보내어지는 getter message는 값이고 일반적인 setter message역시 값이다.:예를 들자면 다음 예제는 VisualWorks TextEditorView가 그것의 contects를 얻는 방법이다.
       자 그럼 여기에 예제를 보자. 우리는 employee관리 application을 가지고 있다고 가정한다.어플리케이션 모델은 하나의 인자인, employee의 사회 보장(비밀) 번호(social security number)의 포함하고 application의 사용자 인터페이스는 employee의 사회 보장 번호를 화면상에 뿌려주는 '입력 박스 뷰'를 포함한다.모델의 엑세스하고 초기화 시키기 위한 메소드는 'socialSecurity'와 'socialSecurity:'로 이름 지어져 있다. 입력 박스는 단지 현재의 사회 보장 번호를 뿌리기만 한지만 모델의 값을 요청하는 방법만을 알고있다.( DeleteMe 수정 필요 ) 그래서 우리는 value mesage를 socialSecurity로 변환 해야 한다.우리는 Pluggable Adapter 객체를 이런 목적을 위해서 사용할수 있다.자 우리의 예제를 위한 interaction 다이어 그램을 보자
• MFC/ObjectLinkingEmbedding . . . . 9 matches
       OLE 컨테이너, 서버 사이의 통신은 윈도우 운영체제를 매개로 동작한다. 각 OLE 를 지원하는 프로그램은 공통의 OLE DLL을 가지는데 이 것이 윈도우의 기본지원 부분이다. DLL 안의 함수들은 이렇게 객체사이의 통신을 지원한다. 이때 이를 지원하는 표준적인 인터페이스가 COM(Component Object Model)이다. 본질적으로 엠비드된 객체의 모양과 컨테이너가 그것과 통신하는 방법을 정의한것이다.
       OLE 서버와 같은 COM객체는 IUnknown 이라는 인터페이스를 구현하고 있따.
       || QueryInterface() || 특정한 인터페이스가 객체에 의해 지원되는지를 검사. 지원된다면 포인터가 리턴된다. ||
       || AddRef() || 인터페이스를 사용하는 클라이언트의 개수에 대한 카운터를 증가시킨다. ||
       || Release() || 인터페이스를 사용하는 클라이언트의 개수에 대한 카운터를 감소시킨다. 카운터가 0이되면 더이상 사용되지 않으므로 메모리에서 해제될 수 있다. ||
       이외에도 다른 인터페이스들도 있다. 인터페이스의 이름은 I로 시작하는 것이 원칙이다. 또한 프로그래머가 자신만의 커스텀 인터페이
        COleClientItem 에는 엠베드된 항목의 관리를 위해 컨테이너가 필요로하는 인터페이스들이 존재한다.
        COleServerItem 안에서 서버를 지원하는 인터페이스도 많은 함수를 갖는다.
• DesignPatterns/2011년스터디/1학기 . . . . 8 matches
        1. DIP에서 의존관계 역전이 대체 무엇을 역전시킨다는 것인지 알게되었다. 기존에는 Highlevel 모듈이 Lowlevel 모듈에 의존하는 식이었지만 인터페이스를 사용하여 Lowlevel 모듈이 Highlevel이 제공하는 인터페이스에 의존하게 함으로써 설계를 더 유연하게 만들 수 있다.
        1. 처음엔 단순히 인터페이스 대신 넘겨받는 구체클래스를 써야해서인 줄 알았는데 상위기술이 하위기술에 의존하는 것이 아닌 하위기술이 상위기술을 지원하기 위해 만들어지는 것이라는것을 알게되었다.
        2. 프로젝트 설계를 하는게 매우 신기했습니다. 가장 최근에 했던 프로젝트가 약 2년 전이라 하나도 모르겠는데 모듈을 잡고 그 모듈의 역활을 잡고 그에 따라 인터페이스를 만들고 하는 걸보고 생각없이 그냥 순차적으로 프로그래밍 하려고했던 제가 참 답이 없었던거 같습니다.
        1. 쩌는 형님들은 잘 쓰시겠지만 코드가 꼬이는 모습을 보니 내가 하는 상속구현은 일단 슬퍼질 가능성이 매우 높으므로 생각에 생각을 해서 쓰던가 아니면 닥치고 인터페이스 구현을 해야겠다.
        1. 인터페이스를 이용한 캡슐화는 참 편리하다 Java를 만든사람들은 이걸 목적에 두고 만든것일까?
        1. 아키텍쳐 설계와 그에 따른 인터페이스를 만들었다.
        1. '''View''' : 유저에게 보여질 인터페이스군.
• Gof/Command . . . . 8 matches
       Command Pattern은 request 를 객체화함으로서 toolkit 객체로 하여금 불특정한 어플리케이션 객체에 대한 request를 만들게 한다. 이 객체는 다른 객체처럼 저장될 수 있으며 pass around 가능하다. 이 pattern의 key는 수행할 명령어에 대한 인터페이스를 선언하는 추상 Command class에 있다. 이 인터페이스의 가장 단순한 형태에서는 추상적인 Execute operation을 포함한다. 구체화된 Command subclass들은 request에 대한 receiver를 instance 변수로 저장하고 request를 invoke하기 위한 Execute operation을 구현함으로서 receiver-action 짝을 구체화시킨다. The receiver has the knowledge required to carry out the request.
       Menu는 쉽게 Command Object로 구현될 수 있다. Menu 의 각각의 선택은 각각 MenuItem 클래스의 인스턴스이다. Application 클래스는 이 메뉴들과 나머지 유저 인터페이스에 따라서 메뉴아이템을 구성한다. Application 클래스는 유저가 열 Document 객체의 track을 유지한다.
       이러한 예들에서, 어떻게 Command pattern이 해당 명령을 invoke하는 객체와 명령을 수행하는 정보를 가진 객체를 분리하는지 주목하라. 이러함은 유저인터페이스를 디자인함에 있어서 많은 유연성을 제공한다. 어플리케이션은 단지 menu와 push button이 같은 구체적인 Command subclass의 인스턴스를 공유함으로서 menu 와 push button 인터페이스 제공할 수 있다. 우리는 동적으로 command를 바꿀 수 있으며, 이러함은 context-sensitive menu 를 구현하는데 유용하다. 또한 우리는 명령어들을 커다란 명령어에 하나로 조합함으로서 command scripting을 지원할 수 있다. 이러한 모든 것은 request를 issue하는 객체가 오직 어떻게 issue화 하는지만 알고 있으면 되기때문에 가능하다. request를 나타내는 객체는 어떻게 request가 수행되어야 할지 알 필요가 없다.
        * undo 기능을 지원하기 원할때. Command의 Execute operation은 해당 Command의 효과를 되돌리기 위한 state를 저장할 수 있다. Command 는 Execute 수행의 효과를 되돌리기 위한 Unexecute operation을 인터페이스로서 추가해야 한다. 수행된 command는 history list에 저장된다. history list를 앞 뒤로 검색하면서 Unexecute와 Execute를 부름으로서 무제한의 undo기능과 redo기능을 지원할 수 있게 된다.
        * 기본명령어들를 기반으로 이용한 하이레벨의 명령들로 시스템을 조직할 때. 그러함 조직은 transaction을 지원하는 정보시스템에서 보편화된 방식이다. transaction은 데이터의 변화의 집합을 캡슐화한다. CommandPattern은 transaction을 디자인하는 하나의 방법을 제공한다. Command들은 공통된 인터페이스를 가지며, 모든 transaction를 같은 방법으로 invoke할 수 있도록 한다. CommandPattern은 또한 새로운 transaction들을 시스템에 확장시키기 쉽게 한다.
        - 수행할 operation을 위한 인터페이스를 선언한다.
• Gof/State . . . . 7 matches
       StatePattern 의 주된 아이디어는 네트워크 커넥션의 상태를 나타내는 TCPState 추상클래스를 도입하는데에 있다. TCPState 클래스는 각각 다른 상태들을 표현하는 모든 클래스들에 대한 일반적인 인터페이스를 정의한다. TCPState의 서브클래스는 상태-구체적 행위들을 구현한다. 예를 들어 TCPEstablished 는 TCPConnection 의 Established 상태를, TCPClosed 는 TCPConnection 의 Closed 상태를 구현한다.
        * 클라이언트들이 원하는 인터페이스를 정의한다.
        * Context 의 특정 상태와 관련된 행위들을 캡슐화 하기 위한 관련 인터페이스를 정의한다.
        * Context는 클라이언트의 주된 인터페이스이다. 클라이언트들은 State 객체들과 함께 context 를 설정할 수 있다. 일단 context가 설정되면, context 의 클라이언트는 State 객체들을 직접적으로 다룰 필요가 없다.
       일단, 우리는 TCPConnection 클래스를 정의한다. TCPConnection 은 데이터를 전달하고 상태 전환을 위한 request를 다루는 인터페이스를 제공한다.
       TCPConnection 은 _state 멤버변수를 이용, TCPState 의 인스턴스를 유지한다. TCPState 클래스는 TCPConnection 의 상태-전환 인터페이스를 중복하여 가진다. 각각의 TCPState 명령들은 TCPConnection 인스턴스를 인자로서 취하며, TCPState 로 하여금 TCPConnection 으로부터 데이터를 접근하거나 현재 커넥션의 상태를 전환할 수 있도록 한다.
       이 방법은 HowDraw [Joh92]와 Unidraw [VL90] drawing editor 프레임워크에 이용되었다. 이는 클라이언트로 하여금 새로운 종류의 tool들을 쉽게 정의할 수 있도록 해준다. HowDraw 에서 DrawingController 클래스는 currentTool 객체에게 request를 넘긴다. UniDraw에서는 각각 Viewer 와 Tool 클래스가 이와 같은 관계를 가진다. 다음의 클래스 다이어그램은 Tool 과 DrawingController 인터페이스에 대한 설명이다.
• COM/IUnknown . . . . 6 matches
       COM 객체의 핵심을 이루는 인터페이스.
       COM 객체를 다루는데 있어서 가장 핵심적인 인터페이스. REFIID 를 이용해 ID 에 맞는 인터페이스 포인터를 얻을 수 잇다.
       IUnknown 은 구현체가 유효한 기간동안 인터페이스 포인터를 변경시키면 안된다.
       인터페이스 포인터는 '''QueryInterface(IID_IUnknown, (void**) &pIUnknownInterface)''' 를 통해서 얻을 수 있으며, 이의 유효를 검사하는 것이 가능하다.
       정상규현된 컴포넌트라면 인터페이스 포인터를 비교하는 것을 통해서 각 객체가 같은 컴포넌트의 인스턴스인지 확인이 가능하다.
• IDL . . . . 6 matches
       [CORBA] 의 경우 분산된 네트워크상에 따로 위치한 객체 간의 투명한 접근을 제공하는 서로 간의 약속이 필요하다. 이런 약속을 정의할 때 특정 언어([C], [C++], [Java] 등)에 의존하지 않는 인터페이스 정의 언어가 필요하게 되었는데, 그것이 바로 IDL(Interface Definition Language)이다. 서버와 클라이언트가 서로 통신을 하기 위해서 서버는 클라이언트에게 제공하는 서비스 인터페이스를 IDL 로 정의하게 되며, 클라이언트는 이런 인터페이스 정보를 활용하여 서비스를 활용하게 되는 것이다. CORBA 프로그램을 개발하기 위해서는 가장 먼저 IDL 을 정의해야 하는데, IDL 은 구현에 대한 정보는 포함하고 있지 않아 정의된 IDL 을 원하는 언어로
       물론, 인터페이스를 정의하는 방법이 IDL 만 있는 것은 아니다. [Visibroker] 의 경우 [Caffeine] 이라는 것을 이용하면 IDL 을 사용하지 않아도 되며, Java 의 RMI 나 RMI-IIOP 를 이용해면 IDL 을 몰라도 인터페이스를 정의할 수 있다. 하지만, IDL 은 OMG에서 규정하고 있는 인터페이스 정의 언어의 표준이고 개발자가 익히기에 어렵지 않은 만큼 CORBA 프로그램을 할 때는 꼭 IDL 을 사용하도록 하자.
• CCNA . . . . 5 matches
        - 이더넷 인터페이스(라우터에서 내부 컴퓨터방향), 시리얼 인터페이스(인터넷 혹은 다른 라우터, 그러니까 isp업체방향)
        * 이더넷 인터페이스의 ip주소는 보통 그 라우터가 연결하는 내부pc에 배정된 ip주소 묶음의 맨 앞 번호부여(이 ip는 다른 pc와 겹치면 안된다)
        * 시리얼 인터페이스의 ip주소는 상위계열의 ip주소에 맞춰 배정되고 서브넷마스크는 동일하게 된다.
        * 기본 게이트웨이 : 내부 네트워크를 벗어날때 밖으로 통하는 문 -> 라우터의 이더넷 인터페이스
• CCNA/2013스터디 . . . . 5 matches
        * 인터페이스 - 계층간 통신을 위한 통로
        || 5 || Router_A(config)#interface serial 0 || 어느 인터페이스를 통해 라우터B와 연결할 것인지 ||
        || 9 || Router_Aconfig-if)#no shut || 인터페이스 활성화 ||
        || msec 타임스탬프 || 인터페이스 || 상태 || In/Out || 메시지 || ID 필드 || 길이 ||
        2. 넥스트 홉(Next hop) 라우터와 연결하는 방법(상대방 라우터의 인터페이스)을 설정한다.
• Gof/FactoryMethod . . . . 5 matches
       객체 생성을 위한 인터페이스를 정의하라, 그렇지만 sub 클래스들이 구현사항을 결정할수 있도록 하자. [[BR]]
        * Factory Method가 생성하는 객체에 관한 인터페이스를 정의한다.
        * Product에 인터페이스에 대한 구현사항이다.
       Factory method는 당신의 코드에서 만들어야한 Application이 요구하는 클래스에 대한 기능과 Framework가 묶여야할 필요성을 제거한다. 그 코드는 오직 Product의 인터페이스 만을 정의한다.; 그래서 어떠한 ConcreteProduct의 클래스라도 정의할수 있게 하여 준다.
        2. ''Parameterized factory methods''(그대로 쓴다.) Factory Method패턴에서 또 다른 변수라면 다양한 종류의 product를 사용할때 이다. factory method는 생성된 객체의 종류를 확인하는 인자를 가지고 있다. 모든 객체에 대하여 factory method는 아마 Product 인터페이스를 공유할 것이다. Document예제에서, Application은 아마도 다양한 종류의 Document를 지원해야 한다. 당신은 CreateDocument에게 document생성시 종류를 판별하는 인자 하나를 넘긴다.
• ProgrammingWithInterface . . . . 5 matches
       책에서는 말한다. 많은 개발자들이 [[OOP#s-1.2|인터페이스]] 보다는 [[OOP#s-1.2|상속]]을 사용하여 개발한다고... 그렇다! 사실이다. 나도 여지껏 인터페이스로 무장한 코드를 보지 못했다.
       상속을 사용하는 상황을 국한 시켜야 할 것같다. 상위 클래스의 기능을 100%로 사용하면서 추가적인 기능을 필요로 하는 객체가 필요할 때! .. 이런 상황일 때는 상속을 사용해도 후풍이 두렵지 않을 것 같다. GoF의 책이나 다른 DP의 책들은 항상 말한다. 상속 보다는 인터페이스를 통해 다형성을 사용하라고... 그 이유를 이제야 알 것같다. 동감하지 않는가? Base 클래스를 수정할 때마다 하위 클래스를 수정해야 하는 상황이 발생한다면 그건 인터페이스를 통해 다형성을 지원하는게 더 낫다는 신호이다. 객체는 언제나 [[SOLID|SRP (Single Responsiblity Principle)]]을 지켜야 한다고 생각한다.
        "위임(합성)을 통해 인터페이스를 구현하자." 라는 결론이 나온다.
• ProjectCCNA/Chapter5 . . . . 5 matches
        - 이더넷 인터페이스(라우터에서 내부 컴퓨터방향), 시리얼 인터페이스(인터넷 혹은 다른 라우터, 그러니까 isp업체방향)
        * 이더넷 인터페이스의 ip주소는 보통 그 라우터가 연결하는 내부pc에 배정된 ip주소 묶음의 맨 앞 번호부여(이 ip는 다른 pc와 겹치면 안된다)
        * 시리얼 인터페이스의 ip주소는 상위계열의 ip주소에 맞춰 배정되고 서브넷마스크는 동일하게 된다.
        * 기본 게이트웨이 : 내부 네트워크를 벗어날때 밖으로 통하는 문 -> 라우터의 이더넷 인터페이스
• Gof/Strategy . . . . 4 matches
        * 모든 제공된 알고리즘에 대한 일반적인 인터페이스를 선언한다. Context는 ConcreteStrategy에 의해 구현된 알고리즘들을 호출하기 위해 이 인터페이스를 이용한다.
        * Strategy 인터페이스를 이용하여 알고리즘을 구현한다.
        * Strategy 가 context의 데이터를 접근할 수 있도록 인터페이스를 정의할 수 있다.
• JavaNetworkProgramming . . . . 4 matches
        *Runnable 인터페이스 : Thread 클래스를 직접 상속받지 않은 클래스의 객체가 손쉽게 쓰레드를 생성할수 있도록 해줌
        execution = new Thread(this); //Runnable 인터페이스를 구현한 것을 넣어줌
        *FileWriter : 텍스트 파일을 플랫폼의 기본 문자 인코딩 방식을 사용하여 출력하는 문자 스트림 인터페이스를 제공 파일에 쓰는것임 --;
        *FileReader : 플랫폼의 기본 문자 인코딩 방식을 사용하여 텍스트 파일을 읽기 위한 문자 스트림 인터페이스를 제공한다. 파일에서 읽는것임 --;
• 토비의스프링3/오브젝트와의존관계 . . . . 4 matches
        * 1.3.2 인터페이스의 도입
        * 인터페이스로 구현된 파라메터를 이용해 외부에서 전달받는다. (다형성)
        1. 클래스 모델이나 코드에는 런타임 시점의 의존관계가 드러나지 않는다. 그러기 위해서는 인터페이스에만 의존하고 있어야 한다.
        * DI의 장점 : DI를 받았을 경우 주입된 오브젝트를 인터페이스로 받는데 이렇게 하면 코드에 런타임 클래스와의 관계가 직접 드러나지 않기 때문에 주입시 주입하는 오브젝트를 바꿔주는 것으로 코드의 변경, 확장에 쉽게 대응할 수 있다.
• AcceleratedC++/Chapter11 . . . . 3 matches
       클래스를 설계할때에는 우선 인터페이스를 결정해야한다. 인터페이스의 결정에는 실제로 그 객체를 이용한 프로그램을 작성해보는 것이 좋다.
        앞의 인터페이스 명세에서 아래의 2가지를 가능하게 하도록 했기 때문에 생성자 2개는 최소한 구현해야한다.
• ComponentObjectModel . . . . 3 matches
       COM 을 처음 공부하고 직접 구현할때에는 모든 것들이 신기해보인다. 팩토리네 스마트 포인터네 스텁-스켈레톤이네 인터페이스네 구현상속과 인터페이스상속은 다르네 등등. 하지만, 동급에 해당되어보이는 Java 플랫폼 내에서의 솔루션들을 보면 너무나 당연한건데 대단하게 표현되어있다거나 (예를 들면 '인터페이스 상속'. COM 책에서는 이걸 왜 무언가 새로운 대단한 기술인 양 서술했을까?) 아에 필요가 없는 기술일 수도 있다. (스마트 포인터 : VM 지원을 받는 플랫폼에선 전혀 필요가 없다.) (물론, 이건 COM 을 설명하던 책들중에 C++ 로 COM 을 구현을 설명하는 책들에 한함)
• DPSCChapter3 . . . . 3 matches
        연관된 혹은 의존적인 객체들의 집합을 만들기 위한 인터페이스를 제공한다. 클라이언트가 구체적인 클래스들에 대한 구체화
        구체화 없이 관계된 혹은 의존적인 객체 집합을 만들기 위한 인터페이스를 제공하는" (Intent 부분에서 언급한 내용)
        여기에 효과적인 두 개의 추상이 있다. 첫번째, 모든 CarPartFactory들이 같은 메시지 인터페이스를 구현한다. 클라이언트가 그들이 메시지를 보내기 위해서 CarPartFactory의 정확한
• Gof/Mediator . . . . 3 matches
        Colleague 객체들과 통신을 위해서 인터페이스를 정의한다.
       ListBox, EntryField, Button은 특화된 사용자 인터페이스 요소를 위한 DialogDirector의 subclass들이다. ListBox는 현재 선택을 위해서 GetSelection연산자를 제공한다. 그리고 EntryField의 SetText 연산자는 새로운 text로 field를 채운다.
       FacadePattern(185)은 보다 편리한 인터페이스를 제공하고자 subsystem의 객체들을 추상화시킨 Mediator와 다르다. 그것의 protocol은 간접적이다. 다시 말하면 Facade 객체들은 subsystem의 요청들을 만들지만 반대의 경우는 그렇지 못하다. 대조적으로 Mediator는 colleague들이 제공하지 못하거나 할 수 없는 협동적인 행위를 가능하게 해준다. 그래서 그 protocol은 multidirectional하다.
• HardcoreCppStudy/두번째숙제/CharacteristicOfOOP/김아영 . . . . 3 matches
       데이터 은닉이란 모듈이 그것이 갖는 기능들을 명세한 인터페이스(interface)를 통해서만 접근되고, 그 기능을 구현하는 방법은 다른 모듈로부터 은닉되도록 하는 것을 말한다. 캡슐화된 객체의 외부 인터페이스를 엄밀히 정의함으로써 독립적으로 작성된 모듈간의 상호 종속성을 극소화하여 캡슐화된 객체는 외부 인터페이스만을 통하여 접근될 수 있도록 한다면, 세부적인 구현 상세 사항에 대해서는 객체내에 은닉시킬 수 있다. 또한 캡슐화된 객체는 객체 구현내역을 변경, 혹은 향상시킬 때 이 객체를 사용하는 타 객체들을 변경하거나 다시 컴파일하지 않도록 할 수 있다. 또 모듈의 내부 구현 사항들이 외부의 접근으로부터 보호될 수 있음으로, 그 객체의 정당성을 보증할 수 있으며, 오류가 발생되었을 경우에 오류는 한 모듈내로 국지화될 수 있다.
• MockObjects . . . . 3 matches
        ''인터페이스가 확실하게 정해지지 않은 모듈에 대해서는 어떻게 할 것인가?''[[BR]]
        -> MockObjects 자체가 인터페이스정의를 위한 도구로 이용할 수 있다. (TestFirstProgramming 에서는 Test Code가 일종의 인터페이스를 정의하기 위한 방법으로 이용된다.)
• MoreEffectiveC++/Miscellany . . . . 3 matches
       대안으로 C++을 사용할때 유도를 제한해 버리는 것이다. Item 26에서 어떻게 객체를 heap에 만들거고 auto_ptr객체로 heap객체를 조정하는 방법에 관해서 언급하였다. String을 위한 인터페이스 생성은 아마 독특하고 불편한 다음과 같은 문법 을 요구한다.
        * 당신의 인터페이스에게 일반적인 기능을 제공하고, 에러를 방지하도록 디자인 해라. 부정확하게 사용하기 어렵게 하고, 정확하게 사용하기 쉽게 만들어라. 예를 들어서 클래스에 대한 복사나 할당에 대한 연산자를 없애서, 복사, 할당을 못하게 하라. 부분적인 할당에 대하여 옙아하라. (Item 33참고)
        * 당신의 새로운 클래스를 당신이 상속 받고자 하는것과 비슷한 클래스 라이브리의 한부분에 구현해라. 예를 들어서 당신이 데이터 멤버로서 라이브러리 클래스의 객체를 가지고 싶을때, 당신의 새로운 클래스에 라이브러리 클래스의 인터페이스를 재정의 해라.
• MoreEffectiveC++/Techniques2of3 . . . . 3 matches
       자 중요한 이 아이템을 처음 시작할때 String클래스의 인터페이스와 다른 점은, 복사 생성자는 어디 있는가? 할당(assignment) 연산자는 어디 있는가? 파괴자는 어디 있는가? 정말 심각한 잘못으로 보이지 않는가?하지만 걱정 할것없다. 사실 이 구현 형태는 완전하다. 만약 이유를 모르겠으면, C++을 좀더 공부해라. (작성자주:이런 건방진 말투로 바꾸는..)
       대단하지 않은가? 누가 객체를 사용하지 않을까? 누가 캡슐화를 반대할까? 하지만, 이러한 신기한 String 클래스에 관한 기반 생각은 클라이언트 측에서 새부사항을 알필요가 없어야 밑이 나는 것이다. 알아야 할것이 없을수록 더 좋은 상태이다. 현재, String을 쓰는 기본 인터페이스는 바뀐것이 없다. 단지 참조세기의 기능이 추가되었을 뿐이다. 그래서 클라이언트는 기존 코드를 고칠 필요가 없다. 단, 재 컴파일(recompile)과 재링크(relink) 과정만이 남아 있을 것이다. 이러한 비용은 참조세기가 주는 이득에 비하면 정말 완전히 없는 비용이나 마찬가지이다. 캡슐화는 정말 좋은거다. (작성자주:뭐야 이 결론은..)
        // 표준 문자열 인터페이스를 따르는 클래스 형태를
• OpenGL스터디 . . . . 3 matches
        * 들어가기전에 openGL은 프로그래밍 언어가 아닌 ''그래픽 하드웨어 제어를 위한 소프트웨어 인터페이스''이다. 그리고 높은 이식성을 지닌 그래픽&모델링 라이브러리이다. 다시말해, OpenGL은 언어가 아닌 API이다.
        * openGL에는 창관리, 상호 작용 인터페이스에 대한 어떤 함수도 없다. 이는 '''일반적인 임플리먼테이션(지정된 규약을 구현한 구현체)'''에 적용하기 위해서이다. Mac이나 리눅스 윈도우 각각 환경에 대해서 모두 접근이 가능케 하기위함이라고 간단히 말할 수 있다.
        * 그렇다면 이 openGL은 구체적으로 어떤식으로 작용하는가? 윈도우를 예시로 들어보자. 윈도우 같은 경우 어떤 화면에 이미지를 출력하려면 '''GDI(graphic Device Interface)라는 그래픽 장치 인터페이스'''를 통해서 출력장치로 출력데이터를 보내 출력한다.
• PatternOrientedSoftwareArchitecture . . . . 3 matches
        * 각 레이어에 대한 인터페이스를 명확히 해라 (가능한한 black-box 접근을 사용하는 것이 좋다, 이것이 시스템 발전을 도와주기 때문이다. 효율이나 다른 레이어의 내부에 접근할 필요가 있을때는 예외이다.)
        * Exchangeability : 특정 레이어를 쉽게 바꿀 수 있다. 그것을 바꿔도 전체적으로 다른 부분은 안바꿔도 된다. 바꾸는 것은 당연히 그 바꿀 대상 레이어의 인터페이스데로 구현되어 있는 것이어야 한다.
        * cascades of changing behavior : 레이어를 바꾸는것뿐만 아니라 그 인터페이스를 바꿀경우에 다른 부분까지 수정해줘야 한다는 말 같다.
• erunc0/COM . . . . 3 matches
        * 간단한 C++ 클래스로 시작하여 재사용 가능한 이진 Component로써 클래스를 사용하는 법을 간단한 예제를 통해서 배우게 된다. 처음은 DLL을 통해서 client 에게 제공하는 문제에 대해 말하며. 다음에는 이렇게 제공되어진 컴포넌트에 대한 방화벽(?)등에 대해 논의 하면서 인터페이스를 통하여 컴포넌트 내의 은닉화를 위한 방법들을 설명해준다. 그리고 그다음으로는 abstract class를 사용해 (virtual function을 이용한 방법) 인터페이스의 확장에 관한 부분까지 설명한다. 그리고 끝으로는 RTTI 이용하여 더 나은 인터페이스의 확장 방법과 다중의 client 에게 컴포넌트를 제공할수 있게 만드는 부분까지 설명한다. 한서라서 그런지 애매한 용어들이 많이 있어서 아직도 이해가 가질 않는 부분이 많았다. 한번더 chapter 1응 읽은 후에 정리하고 chapter 2로 넘어가야 하겠다.
• 니젤프림/BuilderPattern . . . . 3 matches
       쉽게 말해서, 아주 복잡한 오브젝트를 생성해야하는데, 그 일을 오브젝트를 원하는 클래스가 하는게 아니라, Builder 에게 시키는 것이다. 그런데 자꾸 나오는 생성/표현 의 의미는, 바로 director 의 존재를 설명해 준다고 할 수 있다. director 는 Building step(construction process) 을 정의하고 concrete builder 는 product 의 구체적인 표현(representation) 을 정의하기에.. 그리고, builder 가 추상적인 인터페이스를 제공하므로 director 는 그것을 이용하는 것이다.
       패스트(정크)푸드 레스토랑 맥도날드에서 어린이용 해피밀을 만들어내는 걸로 예를 들 수 있다. 일반적으로 해피밀은 메인, 사이드, 음료, 장난감 (햄버거, 프라이, 콜라, 매달 바뀌는 장난감)으로 이루어져 있다. 여기서 중요한건, 이런 템플릿이 정해져 있다는 것이다. 요즘 같이 까다로운 아이들에게 어릴때부터 맥도날드의 입맛을 확실히 들여놓으려면 당연히 다양한 바리에이션이 필요하다. 고객은 햄버거나 치즈버거나, 아니면 맥너겟이나 이런걸 선택할 수 있지만, 기본적으로 해피밀이 구성되는 방식에는 변함 없다. 여기서 빌더 패턴을 적용한다면, 카운터에서 주문을 받는 직원을 Director 라고 할 수 있다. 물론 고객은 Customer 이다. 고객이 원하는 바리에이션을 선택해서 해피밀 셋트를 구성하게 되면 (Customer가 Concrete Builder 를 선택한다) Director 는 정해진 템플릿에 따라 주방 직원(Concrete Builder) 에게 의뢰하여 해피밀 세트(Product) 를 만들어 낸다. 여기서 Director 가 Concrete Builder 에게 요구하는 방식은 종류에 따라 비슷 하므로 그것을 추상화시킨 인터페이스를 Builder 라고 할 수 있겠다.
       Builder 를 구현한 부분. 일반적으로 다수개의 Concrete Builder 가 존재하며, Builder 가 제공하는 인터페이스를 이용해서 late binding 의 형식으로 사용하게 된다. 물론, builder pattern 에서의 주 관심하는 Product 를 만들어내는 것이다.
• 졸업논문/본론 . . . . 3 matches
       기본적으로 지원 되는 레코드 삽입, 삭제, 변경은 자동으로 사용자 화면까지 만들어주는 장점을 가진다. 대부분 웹 애플리케이션이 레코드를 한 건씩 입력하는 인터페이스를 가지기 때문에, 개발 전반부에 걸친 데이터 삽입, 삭제, 변경을 자동화할수 있기 때문이다. 특히 삽입, 변경은 저장이란 단일 개념으로 보고 save메소드로 추상화하였다. 또한 삭제는 관련된 레코드를 함께 지워주는 기능까지 제공한다. 이러한 기능은 Model클래스에 정의된 데이터 타입에 따라 자동으로 이루어진다. 따라서 삽입, 삭제, 변경 SQL문을 실행하는 인터페이스에 많은 노력을 기울이지 않고 기민하게 전체 시스템을 설계함에 집중할 수 있다.
       다행히 django에서는 CLI와 마찬가지로 직접 SQL문장을 수행할 수 있는 인터페이스를 제공한다. 또한 도메인 언어인 python을 이용하면 CLI를 이용해 데이터베이스와 연동할 수도 있다. 종합적으로 기능적으로 지원이 불가능한 면은 없지만, 검색 측면에서 좀더 많은 추상화가 필요하다고 평가할 수 있다.
• 타도코코아CppStudy/0724/선희발표_객체지향 . . . . 3 matches
        겉에서 그객체를 사용하기 위한 사용자 인터페이스는 제공하나 데이타를 검색, 수정 그리고 함수의 이용을 위해서는 이 인터페이스를 꼭 거쳐야 되게 하는것이다.
        자동차라는 객체 클래스를 우리가 사용하기 위해서는 알아야할 것이 운전하는 방법뿐인 것이다. 표지 판이나 교통신호등은 관계는 있으나 자동차를 움직이기 위한 객체 인터페이스와는 아무런 관계가 없는것이다. 캡슐화는 기능의 조직성과 논리성을 연관시킨다.
• 타도코코아CppStudy/객체지향발표 . . . . 3 matches
        겉에서 그객체를 사용하기 위한 사용자 인터페이스는 제공하나 데이타를 검색, 수정 그리고 함수의 이용을 위해서는 이 인터페이스를 꼭 거쳐야 되게 하는것이다.
        자동차라는 객체 클래스를 우리가 사용하기 위해서는 알아야할 것이 운전하는 방법뿐인 것이다. 표지 판이나 교통신호등은 관계는 있으나 자동차를 움직이기 위한 객체 인터페이스와는 아무런 관계가 없는것이다. 캡슐화는 기능의 조직성과 논리성을 연관시킨다.
• 2010JavaScript . . . . 2 matches
        * 인터페이스
        * 김상호,박재홍 : HTML & CSS 로 인터페이스 띄우기
• AcceleratedC++/Chapter13 . . . . 2 matches
       class Grad:public Core { // 구현(implementation)의 일부가 아닌 인터페이스(interface)의 일부로서 상속받는다는 것을 나타냄.
        특정 형의 포인터를 캡슐화시킨 인터페이스를 제공해서, 프로그래머에게 포인터가 보이지 않도록 하는 방법을 제공한다.
• AcceleratedC++/Chapter14 . . . . 2 matches
       Student_info 클래스는 레코드의 인터페이스. 레코드의 메모리 공간을 관리한다.
       기본 인터페이스는 이전의 Str과 동일하지만 자료구조가 Ptr< Vec<char> > 형으로 정의되었기 때문에 전체적인 메소드의 세부 구현이 많이 변경되었다. 그리고 Ptr템플릿으로 자료구조를 다룸으로서 Str클래스가 동일한 객체를 가리킬 수 있는 기능을 제공한다.
• AcceleratedC++/Chapter6 . . . . 2 matches
        * 5장에서 본것처럼 우리가 다루는 컨테이너들은 내부 사정은 다를지라도, 우리는 그것을 모르고도 똑같이 쓸 수가 있다. 즉 일관된 인터페이스를 제공한다는 것이다. 컨테이너나 반복자와 마찬가지로 표준 라이브러리도 일관된 인터페이스를 제공한다. 벡터를 배웠으면 리스트도 금방 쓸수 있는 것처럼, 하나의 알고리즘 쓰는 법을 배우면, 다른 것 쓰는 법도 금방 알수가 있다.
• CToAssembly . . . . 2 matches
       마이크로컴퓨터 시스템의 구성요소가 무엇인가? 마이크로컴퓨터 시스템은 마이크로프로세서 장치 (microprocessor unit, MPU), 버스 시스템, 메모리 하위시스템, 입출력 하위시스템, 모든 구성요소들간의 인터페이스로 구성된다. 전형적인 대답이다.
       Libc wrapper는 시스템호출 규칙이 변경되는 경우 프로그램을 보호하고, 커널에 그런 시스템호출이 없는 경우 POSIX 호환 인터페이스를 제공하기위해 만들어졌다. 그러나, 유닉스 커널은 보통 거의 POSIX에 호환한다: 즉 대부분의 libc "시스템콜"의 문법은 실제 커널 시스템호출의 문법과 (반대로도) 정확히 일치한다. 그러나 libc를 버리지않는 이유는 시스템콜 wrapper외에 printf(), malloc() 등 함수도 있기때문이다.
• CleanCode . . . . 2 matches
        * 인터페이스 분리 원칙 (ISP)
        * 어떤 객체의 사용자에게 그 사용자한테 필요한 메소드만 있는 인터페이스를 제공하라.
• CollectiveOwnership . . . . 2 matches
       만약 누군가가 클래스의 인터페이스를 변경했으면 변경된 클래스를 사용하는 모든 클라이언트 코드에서 오류가 발생할 것이다. 그렇게되면 클래스를 변경한 사람이 모든 오류를 수정해야만 하는가, 아니면 먼저(컴파일 시간에 오류가 발생할꺼 같은데) 발견한 사람이 수정해야 하는가?
       특히 이미 많이 코드가 작성된 시점에서 클래스의 인터페이스를 변경하는 것은 너무 많은 코드를 바꿔야하기 때문에 걱정(귀찮음?)이 앞설 수 있다.
• DNS와BIND . . . . 2 matches
       ; 인터페이스를 위한 특정한 이름들
       ; 인터페이스를 위한 특정한 이름들
• DPSCChapter4 . . . . 2 matches
       '''Adapter(105)''' 는 다른 인터페이스의 Clients들이 예상할수 있는 형태오 클래스의 인터페이스를 변형시킨다. 즉, Adapter는 양립할수 없는 다른 상황의 두가지의 일을 수행하는 클래스를 상호간연결시키는 역할을 한다.
• DataStructure/List . . . . 2 matches
       인터페이스와 개략적인 알고리즘만 적겠습니다.
       //노드 클래스 모습과 인터페이스
• DocumentObjectModel . . . . 2 matches
       DOM은 HTML, XML문서를 다루는 API이다. 이것은 프로그래밍 언어와 플랫폼에 비종속적이다. 인터페이스의 뒷쪽에서 이 문서는 객체지향 모델로 다루어진다.
       XML 에 대해서 파싱하는 API 방식 이야기. DOM 모델이냐 SAX 모델이냐 하는것. 인터페이스 상으로는 DOM 이 쉽긴 함. SAX 는 좀 더 low-level 하다고 할까. (SAX 파서를 이용해서 DOM 모델을 만들어내는 경우가 많음) SAX 는 Tokenizer 가 해당 XML 문서를 분석하는 중의 이벤트에 대한 이벤트 핸들링 코드를 작성하는 것이므로. 그대신 모든 도큐먼트 노드 데이터가 필요한건 아니니, SAX API 로 XML을 파싱하면서 직접 개발자가 쓸 DOM 객체를 구성하거나, 아니면 XPath 를 이용하는게 좋겠지.
• Gnutella-MoreFree . . . . 2 matches
        Gnuclues는 Gnutella 프로젝트 중 OpenSoure로 실제 인터페이스 부분이 열악하다.
        어렵지만 같은 버전 사이의 접속은 가능하므로 인터페이스 부분을 수정한다면
• Java Study2003/첫번째과제/방선희 . . . . 2 matches
        * VM이란? : 자바 언어 및 그 실행 환경의 개발자인 썬 마이크로시스템즈에 의해 사용된 용어이며, 컴파일된 자바 바이너리 코드와, 실제로 프로그램의 명령어를 실행하는 마이크로 프로세서(또는 하드웨어 플랫폼) 간에 인터페이스 역할을 담당하는 소프트웨어를 가리킨다.
        프로그래밍을 할때 데이터베이스에 대한 접근이라든가 또는 다른 시스템에 대한 참조를 할때 굳이 그 시스템에 대해서 세세하게 알필요 없이 그저 외부에 주어진 인터페이스만을 이용해서 접근하면 됩니다. (예를 들자면 어떤 기능을 이용할때는 이런 메소드를 호출하면 된다. 어떤 값을 저장하기 위해서는 이런 메소드로 접근하면 된다 정도). 빈즈에 대한 내용은
• JavaStudy2004/자바따라잡기 . . . . 2 matches
        이 문제를 해결하기 위하여 고슬링은 C와 C++를 개조해서 해결을 해보려고 시도를 했던 것이다.그래서 C언어의 불필요한 부분이나 문제가 될 부분들을 제거한 새로운 언어를 개발하게 되였는데, 이것이 바로 자바인 것이다. 최초로 자바를 이용한 프로젝트는 가전 제품과 전기 기기들을 통합하여 가정 환경에 새로운 인터페이스를 제공하는 소위 그린 프로젝트(Green Project)라는 것 이였다. 그러던 1993년, 그래픽 기반의 월드와이드웹이 발표되고 자바의 개발자들은 곧 이러한 웹 기반의 응용 프로그램에는 자바와 같은 기기(컴퓨터 및 그 운영체제)로부터 독립된 언어가 이상적이라는 것을 발견하였다. 그리하여 그들이 개발한 것이 나중에 핫자바(HotJava)로 이름이 바뀐 웹러너(WebRunner)라는 웹 브라우저였다. 이것이 최초로 자바를 지원한 웹 브라우저가 되었다. 자바라는 이름은 지역의 어느 커피점 안에서 얻었다. 그래서 지금은 웹 페이지에서 항상 끓고 있는 커피의 상징을 볼 수 있다.
        *1. 최근의 컴퓨터 분야의 용례에서, 가상머신은 자바 언어 및 그 실행 환경의 개발자인 썬 마이크로시스템즈에 의해 사용된 용어이며, 컴파일된 자바 바이너리 코드와, 실제로 프로그램의 명령어를 실행하는 마이크로프로세서(또는 하드웨어 플랫폼) 간에 인터페이스 역할을 담당하는 소프트웨어를 가리킨다. 자바 가상머신이 일단 한 플랫폼에 제공되면, 바이트코드라고 불리는 어떠한 자바 프로그램도 그 플랫폼에서 실행될 수 있다. 자바는, 응용프로그램들이 각각의 플랫폼에 맞게 재작성 되거나, 다시 컴파일하지 않아도 모든 플랫폼에서 실행되는 것을 허용하도록 설계되었다. 자바 가상머신이 이를 가능하게 한다. 자바 가상머신의 규격은 실제 "머신"(프로세서)이 아닌 추상적인 머신을 정의하고, 명령어 집합, 레지스터들의 집합, 스택, 가배지를 모은 heap, 그리고 메쏘드 영역 등을 지정한다. 이러한 추상적, 혹은 논리적으로 정의된 프로세서의 실제 구현은, 실제 프로세서에 의해 인식되는 다른 코드, 혹은 마이크로프로세서 그 자체에 내장될 수도 있다. 자바 소스 프로그램을 컴파일한 결과를 바이트코드라고 부른다. 자바 가상머신은, 실제 마이크로프로세서의 명령어에 그것을 대응시키면서 한번에 한 명령어씩 바이트코드를 해석하거나, 또는 그 바이트코드는 실제 마이크로프로세서에 맞게 JIT 컴파일러라고 불리는 것을 이용해 나중에 컴파일될 수도 있다.
• MoniWikiPlugins . . . . 2 matches
       == 사용자 인터페이스 관련 ==
        * format: 프로세서를 액션으로 이용하기위한 인터페이스 액션 (모인모인도 이 방법을 쓴다)
• MoreEffectiveC++/Efficiency . . . . 2 matches
       이제까지 언급했던 예제 코드들을 다시 한번 봐라 당신은 클래스 인터페이스만이 주어진다면 그것이 eager, lazy인지 알수는 없을 것이다. 그것의 의미는 eager evaluation도 역시 곧바로 적용 가능하고, 반대도 가능하다는 의미이다. 만약, 연구를 통해서 클래스의 구현에서 병목 현상을 보이는 부분이 보인다면, 당신은 lazy evaluation의 전략에 근거한 코드들을 적용 할수 있을 것이다. 당신의 클라이언트들은 이러한 변화가 성능의 향상으로 밖에 보이지 않는다. 고객(클라이언트들)들이 좋와하는 소프트웨어 향상의 방법, 당신이 자랑스로워하는 lazy가 될수 있다. (DeleteMe 모호)
       이 예제는 operator+=과 operator-=이 다른곳에 구현되어 있는 것이고, operator+와 operator-가 이들을 이용해 각기 기능을 구현한 모습이다. 이런 디자인이라면, 이 operator들에게 할당된 기능은 유지될것이다.(다른 것이 변하면 같이 변한다는 소리) 게다가 public 인터페이스에서 operator들이 할당된 버전에서 클래스 상에서 friend로서 stand-alone operator에 대한 필요성은 없다.
• ObjectOrientedDatabaseManagementSystem . . . . 2 matches
       OODBMS[오오디비엠에스]는 객체로서의 모델링과 데이터 생성을 지원하는 DBMS이다. 여기에는 객체들의 클래스를 위한 지원의 일부 종류와, 클래스 특질의 상속, 그리고 서브클래스와 그 객체들에 의한 메쏘드 등을 포함한다. OODBMS의 구성요소가 무엇인지에 관해 광범위하게 합의를 이룬 표준안은 아직 없으며, OODBMS 제품들은 아직 초기에 머물러 있다고 여겨진다. 그 사이에 관계형 데이터베이스에 객체지향형 데이터베이스 개념이 부가된 ORDBMS 제품이 더욱 일반적으로 시장에 출시되었다. 객체지향형 데이터베이스 인터페이스 표준은 산업계의 그룹인 ODMG (Object Data Management Group)에 의해 개발되고 있다. OMG는 네트웍 내에서 시스템들간 객체지향형 데이터 중개 인터페이스를 표준화하였다.
• ProjectGaia/요구사항 . . . . 2 matches
        * 편리한 사용자 인터페이스
        * 편리한 사용자 인터페이스
• SeparatingUserInterfaceCode . . . . 2 matches
       도메인모델로부터 프레젠테이션 부분이 분리되었을때, 도메인 코드의 어떠한 부분도 presentattion 코드와 관련이 없도록 해야 한다. 그리하여 만일 WIMP GUI 어플리케이션을 작성했을때 당신은 WIMP 인터페이스를 통해 할 수 있는 모든 것들을 command line interface 로 작성할 수 있어야 한다. WIMP 코드로부터 어떠한 코드도 복사하지 않고.
       도메인모델로부터 퍼시스턴스 부분이 분리되었을때, 도메인 코드의 어떠한 부분도 퍼시스턴트 레이어 코드와 관련이 없도록 해야 한다. 만일 MySQL Repository을 작성했을때 당신은 MySQL 인터페이스를 통해 할 수 있는 모든 것들을 Flat File Repository interface 로 작성할 수 있어야 한다. MySQL 코드로부터 어떠한 코드도 복사하지 않고.
• UploadFile . . . . 2 matches
       == 두가지 인터페이스 ==
       MoniWiki는 두가지 인터페이스의 UploadFile매크로를 지원한다. 각각 이에 대응하는 액션이 있다.
• VisualBasicClass/2006/Exam1 . . . . 2 matches
       ② 사용자에게 제공되는 인터페이스 옵션을 중심으로 설계가 이루어진다.
       D) 사용자 인터페이스 설계 및 구성
• WOWAddOn/2011년프로젝트/초성퀴즈 . . . . 2 matches
       로 현재 인터페이스 정보를 알아볼수 있다.
       내가 작성하는건 4.2니까 40200이겠지 인터페이스 정보를 갱신안해놓으면 와우 애드온 로드시 '구버전'으로 제대로 로드가 안될 수 있다.
• django/Model . . . . 2 matches
       Django는 정의한 모델에 Admin클래스를 재정의해서 이를 삽입, 삭제, 갱신할 수 있는 기본적인 관리자 인터페이스를 자동으로 생성해준다. 사용자 인터페이스는 입력 항목을 원하는대로 배치할 수 있으며, 원하는 디자인도 적용할 수 있다. 이것으로 기본적인 입력 시스템은 만들어졌다.
• 데블스캠프2002/날적이 . . . . 2 matches
        * [영동] : 오늘 오목을 짰습니다... 처음에 어렵사리 유저 인터페이스를 구현했습니다. 처음엔 덮어쓰기를 불가능하게 하고 칸 밖으로 삐져 나가지 않도록 고치는 것은 간단했습니다만... 오목인지를 확인하는 것... 육목은 인정 안 하는 것을 아직 못 했습니다. 대각선 방향으로 체크하는 것도 아직 못 했습니다. 너무 어렵네요. 빨리 적당한 알고리즘을 찾아야...
        * 성재) 우선 처음의 Unix의 경우는 쉽고 재밌었습니다. 제가 개인적으로 홈페이지에 관심이 많던터라 퍼미션 조정에 대해서도 잘 알수 있었구요.. 서버에서의 html을 찾아가는 경로도 알수 있어서 좋았습니다. 그런데... -_-;; 씨 프로그래밍은 여전히 어려웠습니다...-_-;; 첫번째 문제밖에 못풀었는데요.. 우선 Randomwork경우에는 문제조차 이해를 바로하지 못했던게 문제였던 것 같습니다. 동적배열을 쓰는 법도 잘 몰라서 문제였구요. 선배들이 도와주셔서 알긴 했지만 좀 더 공부해야 겠다는 생각이 들었습니다. 그리고 중요한 에러중에 하나가 괄호를 생략하는데서 나온건데요.. 코딩시 줄을 줄여보겠다는 일념<?>하에 괄호가 필요하지 않은데는 일일히 해주지 않았더니 꼬이더라구요... 코딩을 하는데에서의 인터페이스와 여러가지에 대해 깨우치고 알았던 기회였던 거 같습니다. 다음에는 좀 더 찬찬히 알고리즘부터 쫘악 짜서 천천히 풀어봐야 겠습니다...
• 레밍즈프로젝트/연락 . . . . 2 matches
       1. 맵의 자료구조 : 이 부분이 Map과 Pixel 다이어그램인데... 흠... Map은 2차원 배열로서 모든 픽셀에 대한 데이터를 관리하게 되겠지?? 그리고 그 접근 방식은 순차접근(List)가 아니라 인덱싱을 이용한 임의접근(Vector) 일거고. 맵은 Pixel 이라는 인터페이스에 대한 배열을 2차원 Vector로 관리하게 되는겨-_-ㅋ(조금 복잡해지지 이럴땐 [http://www.redwiki.net/wiki/wiki.php/boost boost]의 [http://www.redwiki.net/wiki/wiki.php/boost/MultiArray 다차원배열]에 대한 STL비슷한 녀석을 사용해도 괜찮을겨-_- boost에 대해서 좀 조사를 해야겠지만... vector를 다차원으로 쓰기엔 까다로운 부분이 많거든...)
       2. 픽셀의 기능 : Pixel 인터페이스는 draw라는 순수 가상 함수를 가지고 있어 그리고 전달인자로 CMyDouBuffDC*를 받게 되지. 그리고 SetPixel(int x, int y)따위를 통해서 윈도우에 그림을 그리게 되지 (이부분은 [레밍즈프로젝트/프로토타입/SetBit]참조)을 통해서 배경에 대한 픽셀을 뿌리게 되는거지.
• 레밍즈프로젝트/이승한 . . . . 2 matches
       output 인터페이스 ConsoleCoutput 제작.
       메모리 관련 버그가 아니라. 메모리 확보와 해제를 위한 CPU 타임이었음. 보통의 맵이 1000*150 정도의 크기를 가질 텐데 그것을 죄다 인터페이스화 된 클래스로 생성을 중간에 메모리 소모가 심했다. CDwordArray, CByteArray두개로 필요 데이터를 나누고 좀더 최적화 시켜서 해결을 해 보았다. 메모리 확보와 해제에 필요한 시간은 거의 잡았지만 실제로 출력 할 때 어떤 어려움이 나타 날지는 모르겠다.
• 튜터링/2011/어셈블리언어 . . . . 2 matches
        * 14주차 : 고급언어 인터페이스
        * 상위 언어 인터페이스
• 1002/Journal . . . . 1 match
       중간 개개의 모듈을 통합할때쯤에 이전에 생각해둔 디자인이 제대로 기억이 나지 않았다.; 이때 Sequence Diagram 을 그리면서 프로그램의 흐름을 천천히 생각했다. 어느정도 진행된 바가 있고, 개발하면서 개개별 모듈에 대한 인터페이스들을 정확히 알고 있었기 때문에, Conceptual Model 보다 더 구체적인 Upfront 로 가도 별 무리가 없다고 판단했다. 내가 만든 모듈을 일종의 Spike Solution 처럼 접근하고, 다시 TDD를 들어가고 하니까 중간 망설임 없이 거의 일사천리로 작업하게 되었다.
• 2학기파이선스터디/클라이언트 . . . . 1 match
        * ChatMain? : 채팅의 주 인터페이스를 관리하는 클래스이다. 이 클래스에서 대부분의 GUI를 관리하고, 채팅메세지보여준다. 또한 채팅에 접속한 사람들의 ID를 보여준다.
• 3DGraphicsFoundation . . . . 1 match
        * 수학함수 모듈 인터페이스 예제 - C style : ["3DGraphicsFoundation/MathLibraryTemplateExample"]
• 3D프로그래밍시작하기 . . . . 1 match
       retained는 정점지정시에 속도가 떨어지고.. immediate는 어렵지만 여러방식으로 지정이 가능하고.. 빠르고.. 그랬던거 같습니당.. 요즘엔 direct graphics라 해서 인터페이스가 바꼈는데.. 어떻게 됬는지 몰겠네용..
• 5인용C++스터디/윈도우에그림그리기 . . . . 1 match
       GDI(Graphics Device Interface)란 윈도우의 클라이언트 영역에 그리기를 하는데 사용되는 함수이다. 비디오 출력과 프린터에 그래픽 출력을 책임지고 있는 부분이다. 사용자가 Windows용으로 작성하는 응용 프로그램이 GDI를 사용하여 시각적인 정보를 출력할 뿐 아니라 Windows 자체도 GDI를 사용하여 메뉴, 스크롤 바, 아이콘, 그리고 마우스 커서 같은 사용자 인터페이스 아이템의 시각적인 출력을 수행한다.
• AM/20040817열한번째모임 . . . . 1 match
        * 공부한 내용 : MFC 교재 5장(사용자 인터페이스)
• AcceleratedC++/Chapter1 . . . . 1 match
       interface : 객체의 타입으로 묵시적으로 내포 되어 있는 것은 인터페이스로서, 해당 타입의 객체에 사용 가능한 연산(operation)들의 집합을 말합니다. name을 string 타입의 변수(이름 있는 객체)로 정의 하게 되며, 우리는 string으로 할 수 있는 모든 일들을 name으로 하고 싶다는 뜻을 묵시적으로 내포하게 됩니다.
• AcceleratedC++/Chapter12 . . . . 1 match
        상기의 함수는 Str 자료형에 입력을 하기 때문에 Str 형에 대한 쓰기 권한이 필요하다. 그러나 9.3.1절처럼 단순히 입력 함수를 만들게 되면 일반 사용자가 객체의 내부 구조를 건드릴 수 있는 인터페이스를 제공하는 꼴이 되기 때문에 옳지 못하다.
• AcceleratedC++/Chapter9 . . . . 1 match
        접근함수는 캡슐화의 기본개념이 반하는 것으로 다른 인터페이스 일부로서만 사용해야한다.
• Barracuda . . . . 1 match
       Struts와 비슷한 모델 2 형태의 아키텍처 이지만 스트럿츠 보다 발전된 모델 이벤트 통지 메커니즘을 제공한다. 바라쿠다 프레임 워크는 엄격한 JSP접근 방식과 달리 더 뛰어난 유연성과 확장성을 제공할 수 있도록 템플릿 엔진 컴포넌트를 새로 만들었다. 이 프로임워크에서는 사용자 인터페이스를 생성할 때 XMLC를 이용하여 코드와 컨텐츠를 분할한다. XMLC는 자바 기반의 컴파일로써 HTML과 XML문서를 소스로 읽어 들여 컴파일 하고 자바 클래스 파일을 생성한다. 이 자바 클래스 파일은 런타임에 문서를 재생성하는데 이용된다. ...중략... 마크업과 애플리케이션 로직을 분리한 덕에 웹 디자이너는 마크업에, 프로그래머는 코딩에 집중할 수 있다.
• BasicJAVA2005/7주차 . . . . 1 match
        - Serializable 인터페이스
• BoaConstructor . . . . 1 match
        3. 해당 코드들의 Abstraction Level 을 적절히 맞춰서 리팩토링하며 인터페이스나 모듈관계들에 대한 디자인과 원하는 기능들에 대한 구현 모습에 대한 피드백을 받는다.
• CORBA . . . . 1 match
       CORBA(Common Object Request Broker Architecture)는 소프트웨어 객체가 분산 환경에서 협력하여 작동하는 방식에 대한 일단의 명세서이다. 이 명세서에 대한 책임 기관은 OMG이며, 소프트웨어 업계를 대표하는 수 백 개의 회원 업체로 이루어져 있다. CORBA의 핵심부분은 ORB이다. ORB는 객체의 소비자인 클라이언트와 객체 생산자인 서버 사이에서 객체를 전달하는 일종의 버스로 생각될 수 있다. 객체의 소비자에게는 IDL이라는 언어를 이용한 객체 인터페이스가 제공되며, 객체의 생상자에 의해 제공되는 객체의 자세한 구현사항은 객체의 소비자에게는 완전히 숨겨진다.
• CivaProject . . . . 1 match
        //으음. 클론에이블 인터페이스 구현여부를 어떻게 판단하지 -_-;;
• CppStudy_2002_2/슈퍼마켓 . . . . 1 match
       다음과 같이 표준입출력을 통한 커맨드라인 인터페이스가 어떨까요? (자동) 테스트하기도 훨씬 쉬울테고요.
• CxxTest . . . . 1 match
       단점이 있다면 테스트 상속이 안된다는 점이다. 개인적으로 MockObject 만들어 인터페이스 테스트 만든뒤 RealObject 를 만들어 테스트하는 경우가 많은 만큼 귀찮다. (테스트의 중복으로 이어지므로) 어흑.
• DataCommunicationSummaryProject/Chapter5 . . . . 1 match
        * 새 하드웨어가 필요하지만, 새로운 라디오 인터페이스가 필요없으며, Walsh Codes를 두번 사용해서 두배의 용량을 지원한다.
• DataCommunicationSummaryProject/Chapter8 . . . . 1 match
        * Gateway GPRS Support Node(GGSN)는 GTP 데이터 패킷을 TCP/IP로 교환 하거나 그 역으로 교환할 수 있다. 인터넷에 대한 인터페이스가 되는 것이다.
• DesktopDecoration . . . . 1 match
       MacOS에 존재하는 가장 특징적인 기능중의 하나로 윈도우 식의 Alt+Tab 창이동의 허전함을 완전히 불식시킨 새로운 인터페이스이다. [http://www.apple.co.kr/macosx/features/expose/ Expose]에서 기능의 확인이 가능하다.
• DevelopmentinWindows . . . . 1 match
        * 표준 사용자 인터페이스 제공 (["DevelopmentinWindows/UI"])
• DevelopmentinWindows/UI . . . . 1 match
       윈도우즈에서 제공되는 사용자 인터페이스.
• DiceRoller . . . . 1 match
        * 유저 인터페이스의 개선. 조금 더 편해졌다.
• DirectDraw . . . . 1 match
       [해성] 지나가다가 한마디.. ^^;; DX 초기화 과정은 이전버전과 흡사하군요.. 음.. 초기화 인터페이스를 파악했다면.. 다이렉트 엑스가 어떻게 내부적으로 작동해서 일반 윈도우 프로그래밍 보다 빠른 엑세스 메카니즘을 제공하는지 파악하시구요.. 왠만하면 DX 쓰지말구.. 추가적인 이펙트등을 구현해보는게 좋을것 같네요.. 알파블렌딩을 응용한 여러가지 기법(페이드 인아웃이나 전환.. 뭐라그러드라).. 하구.. 전 못해봤지만.. 블러링 필터 같은것두.. 서페이스에 직접 억세스 하는거 공부하면.. 해볼만 할것 같군요.. 그리구.. 음.. 매일 허접 플밍을 하구 있지만.. 그래두 지겨운 초기화 과정을 단축시키기 위해 어느정도 모듈화되게 라입을 구축하면 좋겠지요.. 전 절대 안하지만.. ㅋㅋ;; 그럼.. 잡설이었습니당~ 수거~[[BR]]
• EffectiveSTL/Container . . . . 1 match
        * STL의 Container들의 장점이라고 한다면, 역시 유연성, 메모리 관리 알아서 하기, 자신이 알아서 늘었다 즐었다 하기 등등이 있겠다. 또한 인터페이스가 이거나 저거나 비슷비슷해서 하나만 공부하면, 쉽게 다른것도 쓸수 있다는 것도 또 하나의 장점이 될수 있겠다.
• EmbeddedSystem . . . . 1 match
        * 임베디드 시스템은 더 큰 시스템의 구성요소를 이루거나 사람의 개입 없이 동작하도록 기대되는 하드웨어와 소프트웨어이다. 전형적인 임베디드 시스템은 전원이 켜져 동작하기 시작하면 전원이 꺼질 때까지 멈추지 않는 특수한 용도로 사용하는 일부 응용 프로그램을 시동하는 롬에 들어 있는 소프트웨어를 포함하는 단일 보드 마이크로컴퓨터이다. 임베디드 시스템은 운영체제를 포함하거나 단일 프로그램으로 작성할 수 있을 만큼 단순할 수 있다. 시스템에 필요 없을 경우 키보드, 모니터, 직렬 통신, 대용량 기억 장치와 같은 일반적인 주변 장치나 사용자 인터페이스 소프트웨어를 지원하지 않는다.그리고 실시간성을 요구할 때도 있다.
• FreeMind . . . . 1 match
       인터페이스가 매우 간단해서 사용방법을 익히는 과정 필요없다. 설치 즉시 마인드 맵을 작성 할 수 있다.
• GRASP . . . . 1 match
        변화 가능성이 있는 부분에 인터페이스를 형성하도록 책임을 할당하라.
• Garbage collector for C and C++ . . . . 1 match
       == 인터페이스 ==
• Java Study2003/첫번째과제/곽세환 . . . . 1 match
       자바에서는 인터프-리터가 런타임 환경을 검사할 필요 없이 실행될 수 있도록 구성하였기 때문에 뛰어난 성능을 제공해 줍니다. 쓰레기 수집기(garbage collector) 즉 메모리 관리자는 자동으로 낮은 우선순위의 백그라운드 스레드로 실행되어 메모리가 필요할 때에만 동작하도록 함으로써, 자바 가상머신에게 무리를 주지 않으면서 보다 나은 수행 성능을 제공할 수 있도록 해 줍니다. 또한, 방대한 양의 계산을 수행하는 프로그램은 계산이 많은 부분을 본래의 플랫폼에 해당하는 기계어 코드로 재작성하여 자바 프로그램과 인터페이스 할 수 있도록 하였습니다.
• Java Study2003/첫번째과제/노수민 . . . . 1 match
       자바에서는 인터프-리터가 런타임 환경을 검사할 필요 없이 실행될 수 있도록 구성하였기 때문에 뛰어난 성능을 제공해 줍니다. 쓰레기 수집기(garbage collector) 즉 메모리 관리자는 자동으로 낮은 우선순위의 백그라운드 스레드로 실행되어 메모리가 필요할 때에만 동작하도록 함으로써, 자바 가상머신에게 무리를 주지 않으면서 보다 나은 수행 성능을 제공할 수 있도록 해 줍니다. 또한, 방대한 양의 계산을 수행하는 프로그램은 계산이 많은 부분을 본래의 플랫폼에 해당하는 기계어 코드로 재작성하여 자바 프로그램과 인터페이스 할 수 있도록 하였습니다.
• Java Study2003/첫번째과제/장창재 . . . . 1 match
       자바에서는 인터프-리터가 런타임 환경을 검사할 필요 없이 실행될 수 있도록 구성하였기 때문에 뛰어난 성능을 제공해 줍니다. 쓰레기 수집기(garbage collector) 즉 메모리 관리자는 자동으로 낮은 우선순위의 백그라운드 스레드로 실행되어 메모리가 필요할 때에만 동작하도록 함으로써, 자바 가상머신에게 무리를 주지 않으면서 보다 나은 수행 성능을 제공할 수 있도록 해 줍니다. 또한, 방대한 양의 계산을 수행하는 프로그램은 계산이 많은 부분을 본래의 플랫폼에 해당하는 기계어 코드로 재작성하여 자바 프로그램과 인터페이스 할 수 있도록 하였습니다.
• Java2MicroEdition . . . . 1 match
       그리고, 수많은 소비자/임베디드 디바이스들에 공통적으로 적용할 수 있는 플랫폼을 개발한다는 것도 자체적으로 한계가 있었다. 다양한 하드웨어, 다양한 운영체제, 그리고 전혀 호환성 없는 유저 인터페이스까지, 이 모든 차이점을 극복하면서 기존의 J2SE 기반의 자바와의 호환성까지 유지할 수 있는 솔루션은 불가능하다는 문제인식이 있었다. 그래서 등장한 개념이 컨피규레이션과 프로파일로의 플랫폼 분할이다.
• JavaStudy2002/영동-3주차 . . . . 1 match
       3번째의 코드는 comment solving을 보인거니 감안하십시오. 3번을 그대로 한다면, 입력 데이터와, Bug 사이의 인터페이스를 맞추는 함수가 필요할것입니다.
• MFC/Print . . . . 1 match
       || m_bDocObject || 응용프로그램이 lPrint 인터페이스를 통하여 출력하면 TRUE로 설정되며, 그렇지 않은 경우에는 FALSE이다. ||
• MFCStudy_2001/진행상황 . . . . 1 match
        * 1월 21일 새벽 1시 현재 - 정상적인 사용자 인터페이스 구성을 끝내고 육목 막았습니다. 3 * 3 만 막으면 이제 인공지능으로 들어가야겠습니다. AI 설계는 뼈대만 잡은 상태입니다.
• MoreEffectiveC++/Techniques1of3 . . . . 1 match
        // 그래픽 인터페이스(수정이 허락되는 한에서)
• PairProgramming . . . . 1 match
       IConnection을 이용해 각각의 Connection에 대해 단일의 인터페이스를 제공하고 IConnection을 구현하는 MySqlConnection , SqlConnection , OciConnection을 만들자는 것이 나의 생각이었다. 파트너는 switch구문을 이용해 클래스의 상속 구조를 없애는 것과 비교해서 어떠한 이점이 있는가에 대해 질문했다. 이것은 장시간의 토론으로 이어졌다.
• ProjectPrometheus/Journey . . . . 1 match
       Spike Solution으로 만들어 두었던 것들이, 실제로 프로그래밍 소스로 전환되고 있는 과정 중이다. 이제 User내의 Spike Solution관련 코드들이 사라지면 Spike Solution의 Test들도 다 깨지면서 사라 질것이다. 내일이면 DB와의 연동이 마무리 되고, 웹에 인터페이스 노출이 이루어 질것 같다. 그렇게 되면 커다란 줄기는 완성되는 것이다. 역시나 감회가 새롭다. Acceptance Test에 관련한 코드들을 내가 너무 모르고 있다. 그쪽 코드를 보고 이해 해야 불안하고 들뜬 마음을 안정 시킬수 있을것 같다. 나는 즐거운거 맞는 걸까? 학교 더 일찍오면 확실히 즐거울꺼 같다. ;; --["상민"]
• ProjectVirush/Idea . . . . 1 match
        22. 게임은 플레이어의 재미와 편리를 위해서 멋진 그래픽과 편리한 인터페이스를 제공해야 한다. (이를 위해 미소녀가 등장해도 뭐라하지는 않겠....퍽!)
• ProjectZephyrus/ClientJourney . . . . 1 match
        * 소프트웨어 개발이 공장스타일이 될 수 없는 이유를 하나 든다고 한다면 개발중 개발자가 계속 학습을 해나간다는 점에 있지 않을까 한다. 처음부터 끝까지 모든 것을 다 예상하고 개발할 수 는 없을것이니. (필요한 라이브러리가 무엇인지, 실제 그 라이브러리의 장단점이 무엇인지, 어떻게 사용하면 바로 알수 없는 버그가 되어버리는지 등등. 뭐 큰 소프트웨어일 경우 이것을 다 예측해야 한다라고 하면 할말없지만. 이것도 비용을 고려해서 처신해야하겠지. Cost Estimate 자체가 Cost 가 드는것일거니.) 암튼 아쉬운건 중간에 디자인이 바뀌었을때 (실제로 처음 디자인의 클래스들을 몇개 뺀것도 있고, 인터페이스만 맞춰본 것들도 있고 그러함) 바쁜 사람들이 참석을 하지 못해서 처음부터 설명해야 하는 경우이다.
• ProjectZephyrus/ServerJourney . . . . 1 match
        * 현재 상태에서는 속도에는 신경 쓰지 말자, 일단 구조만 잘 정의 해놓으면, 개선 사항은 얼마든지 체계적으로 생각 날것이라고 생각 된다. 현재는 체계적으로 생각 나지 않지 않그런가? 당장 그날 구현만 해도 JDBC의 몇가지 api로 중복 부분의 속도 개선의 여지가 보이는데, 너무 많이 생각하면 해골 복잡하니, '''기능 구현''' 에만 중점을 두자. 이제 DB는 인터페이스만 정의 하면 완전 따로 놀수 있을것 같다. --상민
• PythonNetworkProgramming . . . . 1 match
       Medusa 는 내부적으로 select / poll 를 이용, 비동기 소켓부분을 구현한다. 소켓 이벤트들 처리에 대한 인터페이스가 아주 깔끔. 참 마음에 든다.
• Refactoring/BadSmellsInCode . . . . 1 match
       서브클래스가 부모의 behavior는 재사용하나 부모의 인터페이스를 지원하기를 원하지는 않을 때.
• Refactoring/BuildingTestCode . . . . 1 match
       사실 테스트 코드를 작성하기 위한 가장 좋은 때는 프로그래밍을 시작하기 전이다. 어떤 기능을 추가해야할 때, 테스트 코드를 작성하는 것으로 시작한다. 이것은 뒷걸음질 치는 것이 아니다. 그 기능을 추가하기 위해서 어떤 것들이 행해져야 하는지 스스로에게 물어보는 것이 된다. 그리고 테스트 코드를 쓰는 것은 구현보다는 인터페이스에 집중할 수 있게 해준다. (그리고 이것은 언제나 좋은 것이다)
• Ruby/2011년스터디 . . . . 1 match
        * 자바의 인터페이스 같은 느낌?
• SmallTalk/강좌FromHitel/소개 . . . . 1 match
       터 사용자 인터페이스를 생성하는 방법이 마련되어 있었으며, 예전에는
• SmallTalk_Introduce . . . . 1 match
       터 사용자 인터페이스를 생성하는 방법이 마련되어 있었으며, 예전에는
• Spring/탐험스터디/2011 . . . . 1 match
        1.1. DIP : 멤버 변수를 외부에서 주입 받을 때는 구체 클래스가 아닌 인터페이스를 이용한다. 최대한 클래스 내부에서 변수를 할당하지 말고(new를 사용하지 말고) 주입을 받도록 한다.
• SuperMarket . . . . 1 match
       다음과 같이 표준입출력을 통한 커맨드라인 인터페이스가 어떨까요? (자동) 테스트하기도 훨씬 쉬울테고요.
• TddWithWebPresentation . . . . 1 match
       하지만, 이건 리팩토링 단계에서의 이야기고, 만일 새 코드를 작성하는 중의 UI 부분 presenter 를 TDD로 구현한다면 어떻게 될까? 아마 저 MockViewPresenter 부분이 먼저 구현되고, 이 인터페이스를 근거로 ViewPresenter 를 만든 뒤 HTML 코드 부분을 작성하면 될 것 같다. 실제 UI 에 어떠어떠한 것이 표현되느냐는 AcceptanceTest 단에 맡기면 되리라.
• TestCase . . . . 1 match
       XP에서 TestCase를 먼저 작성함으로서 프로그래머가 내부 구현에 신경쓰다가 정작 그 원하는 동작(예를 들어, 다른 모듈과의 인터페이스)을 놓칠 위험을 줄여준다. 왜냐하면, 프로그래머는 먼저 만든 TestCase를 통과하는 것을 첫번 목표로 삼을 수 있기 때문이다.
• TestDrivenDevelopment . . . . 1 match
       테스트를 작성할때엔 '이미 완성되어있는 잘 된 API' 를 상상하며 작성한다. 잘 만들어진 API는 같은 일을 하더라도 직접 호출해줘야 하는 함수의 갯수가 적고 이해하기 편하며 '무엇'을 해주는지 그 메소드가 말해준다. 적게 코드를 써도 많은 일을 해주는것이다. 그리고, 테스트로서 컴퓨터의 컴파일러에게 코드작성을 위해 해야 할 일들을 묻고, 인터페이스를 만들고. 그리고 구현하고, 다시 구현된 코드를 Refactoring 한다.
• Trac . . . . 1 match
       Trac 은 SubVersion 에 대한 인터페이스를 제공하며 위키와 통합되어있고 편리한 레포트 기능을 제공해준다.
• Ubiquitous . . . . 1 match
        인간화된 인터페이스(Calm Technology)를 제공해 사용자 상황(장소, ID, 장치, 시간, 온도, 명암, 날씨 등)에 따라 서비스가 변한다.
• UnitTest . . . . 1 match
       A: MockObjects가 최적입니다. Socket이나 Database Connection과 동일한 인터페이스의 "가짜 객체"를 만들어 내는 겁니다. 그러면 Socket 에러 같은 것도 임의로 만들어 낼 수 있고, 전체 테스팅 시간도 훨씬 짧아집니다. 하지만 "진짜 객체"를 통한 테스트도 중요합니다. 따라서, Socket 연결이 제대로 되는가 하는 정도만(최소한도로) "진짜 객체"로 테스팅을 하고 나머지는 "가짜 객체"로 테스팅을 대체할 수 있습니다. 사실 이런 경우, MockObjects를 쓰지 않으면 Test Code Cycle을 통한 개발은 거의 현실성이 없거나 매우 비효율적입니다. --김창준
• VMWare . . . . 1 match
       유사기술을 적용한 Linux [Xen] 커널이 등장하기 시작했으며, Xen 은 차후 나타나게될 멀티코어 CPU 환경(플랫폼 자체가 완전히 다른)에 적합한 커널의 구축을 목표로 하고 있다고 한다. (완전히 다른 프로세서라면 당연히 해당 머신에 접근하는 인터페이스 역시도 다를텐데 XEN 을 이용해 해당 부분을 추상화시켜서 접근하는 식으로..) 현재에는 해당 기술을 보안 분야에서 이용하기 위한 연구가 진행중이며 기존의 단일 커널하의 커널모드, 유저모드 식의 구분이 아닌 관리자 커널, 애플리케이션 커널과 같은 구분으로 2개의 서로 다른 커널을 구현해 커널 단에서 애플리케이션이 머신에게 직접적으로 접근할 가능성을 원천 차단하는 방식의 연구가 되고 있다.
• VendingMachine/세연/1002 . . . . 1 match
       디자인을 할때에 보통 Input / Output 은 요구사항이 자주 바뀌므로 일단 메인 Vending Machine 코드가 작성되고 난 뒤, Vending Machine 의 인터페이스에 맞춰서 Input / Output 코드를 나중에 작성하는 것이 좋습니다.
• VendingMachine/재니 . . . . 1 match
        * 자판기는 사용자 인터페이스를 구현하는데 사용하고, 사람이 주문할 음료(Drink)를 따로 분류하자..
• VonNeumannAirport/1002 . . . . 1 match
       이 인터페이스도 수정하길 컴파일러가 바라고 있다. 원하는대로 해주자.
• WebService . . . . 1 match
       웹 서버를 통하여 프로그램 인터페이스를 노출하려는 방법
• WhatToProgram . . . . 1 match
       이 과정이 어느 정도 되면, 타인을 위한 프로그램을 작성할 수 있다. 나에게는 별 의미가 없지만 남에게 "아주 귀중한 가치를 주는" 프로그램을 만들어라. 서로 만들어줘도 좋다. 자신이 컴퓨터 공학과라면 국문학과 학생에게 프로그램을 만들어주라. 그와 가까이 지내고 그가 진정 원하는 것이 무엇이며, 진정 필요로 하는 것이 무엇인지(원하는 것과 필요로 하는 것은 다르다) 분석하고, 프로그램 해줘라. 그가 그 프로그램을 한 달 이상 사용하는가? 그래야 한다. 그 정도로 가치있는 프로그램이어야 한다. 가치있는 프로그램이 꼭 복잡하거나 거대할 필요는 없다. 그가 프로그램의 수정을 요구한다면 가능하면 모두 들어주어라. 그게 힘들다면 그를 납득시켜라. 아마도 이 단계에서 타인을 위한 프로그램을 작성하면서 "작성자"와 "사용자"간의 프로그램을 통한 커뮤니케이션의 중요성에 눈을 뜨게 될 것이다. 인터페이스에 대해 고민할 것이다. 얼마나 이쁘냐보다, 얼마나 실수할 행위유발성을 제공하지 않느냐, 그리고 어떤 메타포를 사용할 것인가(이에 대해서는 비지칼크란 프로그램을 연구하라) 하는 문제를 생각할 것이다.
• WindowsConsoleControl . . . . 1 match
       터보 C를 사용할때는 라이브러리로 콘솔제어를 쉽게 하는 함수들이 존재하였다. MS의 콘솔을 배제하는 정책 때문인지 함수는 존재하지만, 불편한 인터페이스를 그대로 유지하고 있는데, 이를 살작 추상화 시키는 간단한 소스들이다.
• WindowsTemplateLibrary . . . . 1 match
       지원이 되지 않는 라이브러리이기 때문에 WTL에 관한 문서는 거의 없다. 그러나 대부분의 API는 표준 Win32 콜을 거의 직접적으로 반영하므로, WTL의 인터페이스는 대부분의 윈도우즈 프로그래머들에게 친숙하다.
• Yggdrasil/가속된씨플플/1장 . . . . 1 match
        * 인터페이스: 해당 타입의 객체에 사용 가능한 연산(operation)들의 집합
• ZIM . . . . 1 match
        * 1월 7일 유저인터페이스 프로토타입에 대한 생각을 맞춰보려합니다. 학교서 뵙죠. ^^;
• ZIM/RealUseCase . . . . 1 match
       사용자 인터페이스와 함께 설명이 이루어지면 더 좋겠죠. 일단 ["ZIM/UIPrototype"]이 대강 나온다면... ^^;;;
• ZIM/UIPrototype . . . . 1 match
       사용자 인터페이스의 프로토타입을 보여주세요.
• ZeroPageServer/SubVersion . . . . 1 match
        [http://zeropage.org/cvs/?root=project ViewCVS] : 웹인터페이스로의 체크아웃이 가능하다.
• django/RetrievingObject . . . . 1 match
       Django에서 기본적으로 제공하는 조인 연산은 없다. SQL문을 직접 수행하여 원하는 결과를 얻을 수 있다. 이는 JDBC의 인터페이스와 비슷하며, 커서를 이용하여 질의를 수행한 결과를 하나씩 얻어오는 방식을 사용한다. 다음은 특정 부서 에서 시행한 위험 관리 대책을 얻어오는 함수이다.
• html5/overview . . . . 1 match
        * 휴먼 인터페이스에 가까워질수있음
• html5/web-workers . . . . 1 match
        * 워커 인터페이스 생성자에 JavaScript 소스 파일의 URL인수로 전달하면 소스파일을 내려받아 백그라운드에서 실행한다
• whiteblue/간단한계산기 . . . . 1 match
       아직은 인터페이스만...;;
• 그래픽스세미나/1주차 . . . . 1 match
        a. 인터페이스의 표시
• 데블스캠프2011/둘째날/후기 . . . . 1 match
        * 제가 처음 준비했던 컨텐츠였는데 성현이가 세미나를 진행하니 감회가 새로웠습니다. 저는 09년 때 간단한 인터페이스만 가르쳐줬는데 학우들이 창의적인 컨텐츠를 많이 만든 반면 성현이는 기능 하나하나 상세히 설명해주어서 제가 몰랐던 기능도 많이 알게 되었습니다. 수업을 들으면서 플래시 같은 애니메이션을 만들었는데 갑자기 게임을 만들라고 해서 소닉이 좌우로 이동하는 것밖에 못 만들어봤네요 ㅋㅋ 그래도 이동할 때의 모습을 바꾸는 데에서 삽질 끝에 성공해서 뿌듯뿌듯했습니다. 저의 Scratch 작품의 포인트는 역시 '음악' 입니다.
• 데블스캠프2013/셋째날/후기 . . . . 1 match
        * 자바도 C처럼 직접 짜는 것만 있는 줄 알았는데 편리한 인터페이스가 구현되 있다는 것은 처음 알았네요 - [원준연]
• 땅콩이보육프로젝트2005/개발일지 . . . . 1 match
        == 인터페이스 ==
• 레밍즈프로젝트/그리기DC . . . . 1 match
       TODO. 출력 인터페이스로 상속 받아오기
• 레밍즈프로젝트/드래프트버전 . . . . 1 match
       게임 전체 인터페이스 제작.
• 마샬링 . . . . 1 match
       마샬링은 하나 이상의 프로그램 또는 연속되어 있지 않은 저장 공간으로부터 데이터를 모은 다음, 데이터들을 메시지 버퍼에 집어넣고, 특정 수신기나 프로그래밍 인터페이스에 맞도록 그 데이터를 조직화하거나, 미리 정해진 다른 형식으로 변환하는 과정을 말한다.
• 방울뱀스터디 . . . . 1 match
        * 화면 인터페이스는 각 플레이어 위쪽 모서리에 '점수, 목숨, 내땅' 출력
• 방울뱀스터디/만두4개 . . . . 1 match
        * 화면 인터페이스는 각 플레이어 위쪽 모서리에 '점수, 목숨, 내땅' 출력
• 실시간멀티플레이어게임프로젝트/첫주차소스3 . . . . 1 match
       - 로그인 인터페이스 깔끔하게->표만들기 태그 이용
• 정모/2011.3.21 . . . . 1 match
        * 이번에 승한이 형의 Emacs. Elisp 세미나를 들었다. 세미나를 들어보니 Emacs는 매우 자신에 맞게 전환 할 수 있는 도구 인 것 같다. 와우 에드온 같이 자기에게 딱 맞게 설정하는 재미가 있을꺼 같다. 기회가 되면 한번 다뤄봐야겠다. 그리고 다음 OMS로 주제를 키넥트에 관해서 하고싶은데 아직 사지도 않아서!!! 뭘해야될지 고민이다... 그냥 요즘 새로나온 게임 인터페이스들에 대해 통짜로 해버릴까...고민중임 - [임상현]
• 정모/2011.3.28 . . . . 1 match
        * OMS에서 상현이형이 발표하신 인터페이스에 관한 것들이 참 기억에 남더군요. 그 장비들로 작년에 창설을 진행했으면 전 A+을 받고 1학기 장학금을 타서 ZP 선배, 동기 들에게 술과 밥을 제공했을 것 같았습니다. 그리고 스터디는 하고있지만 학생회 일정 때문에 했다간 민폐력만 키울거 같아서 못하게 된게 정말 아쉬웠구요 ㅠ 방학 때에나 해야겠습니다. 그리고 새싹 저희반이 생각보다 다른 반보다 한게 은근히 많더군요. 1등반 만들도록 애들 닥달해야겠습니다. 훗. 그리고 전 회비 냈지 말입니다. 그리고 회장님이 아이스 브레이킹에서 이상한 키워드라고 회피하셔서 아쉬웠어요. - [윤종하]
• 정모/2011.4.4 . . . . 1 match
        * 튜터링 수업은 정규 수업 진도를 꼭 따라갈 필요는 없을 듯 합니다. 작년에 튜터링 수업을 들었던 경험상, 튜터 선배님이 다들 1년동안 배운 C, C++과 공통된 문법은 넘어가고 클래스부터 설명을 하였습니다. 그리고 수업 외에 이때 내가 알았으면 좋았을거다! 싶다 생각한 것을 가르쳐 주셨습니다. map, set에 대한 간단한 설명이나, UML 사용법에 관한 프린트를 뽑아와 알아두면 좋다 하시기도 하고, MVC에 대해 예시를 들어 설명하시기도 하고, 인터페이스를 저그, 프로토스, 테란의 공통된 기능을 묶어 설명하기도 하고... 열심히 연습하며 따라가면 좋았을텐데 저의 성찰일지는 늘 공부를 했어야 했는데...로 끝났다는 게 미스지만요ㅠㅠ([강소현])
• 정모/2011.8.8 . . . . 1 match
        * [http://www.zdnet.co.kr/news/news_view.asp?artice_id=00000039139151&type=det ISP(인터페이스 분리 원칙)]
• 정모/2012.7.11 . . . . 1 match
        - 인터페이스를 잘 이용해서 수정할 부분이 적도록 만들었다.
• 제로페이지의문제점 . . . . 1 match
        * 졸업선배들중에 제로위키를 이용하시는 분들은 없을까? 물론 회사 차원에서의 보안상 공개할 수 없는 정보도 많고, 일과 피로때문에 글을 정리하실 시간이 많지 않다는 등 어려움이 많다. 그리고 위키 인터페이스 자체를 불편해하는 사람들 또한 많다.
• 조영준/CodeRace/130506 . . . . 1 match
        * Compare은 인터페이스를 구현시킨건가? 음...
• 조현태/놀이/치이/기능명세/화면 장식 . . . . 1 match
        * 미소녀 인터페이스 제공
• 졸업논문/서론 . . . . 1 match
       이러한 맥락에서 python언어로 만든 django라는 프레임워크가 존재한다. RoR과 마찬가지로 django를 이용하면 기민하게 동적으로 웹 사이트를 만들 수 있다.[4] Django에서는 모델, 뷰, 템플릿, 세팅 등을 이용하여 웹 사이트를 구축할 수 있는 특징과 함께, 관리자 인터페이스를 자동으로 제공해주는 장점을 가진다. 또한 모델과 데이터베이스를 자동으로 동기화 해주고, 데이터를 삽입, 변경, 삭제할 때 웹 개발자가 직접 데이터베이스에 질의를 던지지 않아도 되도록 데이터베이스 접근을 추상화하였다.
• 채팅원리 . . . . 1 match
       ChatMain : 채팅의 주 인터페이스를 관리하는 클래스이다. 이 클래스에서 대부분의 GUI를 관리하고, 채팅메세지보여준다. 또한 채팅에 접속한 사람들의 ID를 보여준다.
• 토비의스프링3/밑줄긋기 . . . . 1 match
        * 서비스 추상화에는 기능은 유사하나 사용 방법이 다른 로우레벨의 다양한 기술에 대해 추상 인터페이스와 일관성 있는 접근 방법을 제공해주는 것을 말한다. 반면에 테스트를 어렵게 만드는 건전하지 않은 방식으로 설계된 API를 사용할 때도 유용하게 쓰일 수 있다.

Found 160 matching pages out of 7555 total pages (5000 pages are searched)

You can also click here to search title.