캡슐화

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

• Gof/Facade . . . . 6 matches
       서브시스템은 인터페이스를 가진다는 점과 무엇인가를 (클래스는 state와 operation을 캡슐화하는 반면, 서브시스템은 classes를 캡슐화한다.) 캡슐화한다는 점에서 class 와 비슷하다. class 에서 public 과 private interface를 생각하듯이 우리는 서브시스템에서 public 과 private interface 에 대해 생각할 수 있다.
       Compiler 서브시스템은 BytecodeStream 클래스를 정의한다. 이 클래스는 Bytecode 객체의 스트림부를 구현한다. Bytecode 객체는 머신코드를 구체화하는 bytecode를 캡슐화한다. 서브시스템은 또한 Token 클래스를 정의하는데, Token 객체는 프로그램 언어내의 token들을 캡슐화한다.
        * AddressTranslation 은 address translation hardware 를 캡슐화한다.
• 타도코코아CppStudy/0724/선희발표_객체지향 . . . . 6 matches
        * 캡슐화(encapsulation) : 객체의 내부적인 사항과 객체들간의 외부적인 사항들을 분리시킨다. 이렇게 캡슐화된 객체의 행위는 외부에서 볼 때는 구체적인 아닌 추상적인 것이 되므로 정보 은닉(information hiding) 개념이 존중된다. 주어진 클래스의 특정 연산 기능은 메소드(method)라고 한다. 캡슐화는 무슨 메소드로 구현되었는가에 구애받지 않고 추상적으로 정의된 연산 기능을 통해 객체가 사용되고 시스템의 상태(state)를 변화시키도록 해준다.
        * 캡슐화(Capsulation) : 캡슐화는 객체의 속에 모든 함수와 그 함수에 의해 유통되는 데이타를 밖에서 유통시키지 않는것이다.
        자동차라는 객체 클래스를 우리가 사용하기 위해서는 알아야할 것이 운전하는 방법뿐인 것이다. 표지 판이나 교통신호등은 관계는 있으나 자동차를 움직이기 위한 객체 인터페이스와는 아무런 관계가 없는것이다. 캡슐화는 기능의 조직성과 논리성을 연관시킨다.
• 타도코코아CppStudy/객체지향발표 . . . . 6 matches
        * 캡슐화(encapsulation) : 객체의 내부적인 사항과 객체들간의 외부적인 사항들을 분리시킨다. 이렇게 캡슐화된 객체의 행위는 외부에서 볼 때는 구체적인 아닌 추상적인 것이 되므로 정보 은닉(information hiding) 개념이 존중된다. 주어진 클래스의 특정 연산 기능은 메소드(method)라고 한다. 캡슐화는 무슨 메소드로 구현되었는가에 구애받지 않고 추상적으로 정의된 연산 기능을 통해 객체가 사용되고 시스템의 상태(state)를 변화시키도록 해준다.
        * 캡슐화(Capsulation) : 캡슐화는 객체의 속에 모든 함수와 그 함수에 의해 유통되는 데이타를 밖에서 유통시키지 않는것이다.
        자동차라는 객체 클래스를 우리가 사용하기 위해서는 알아야할 것이 운전하는 방법뿐인 것이다. 표지 판이나 교통신호등은 관계는 있으나 자동차를 움직이기 위한 객체 인터페이스와는 아무런 관계가 없는것이다. 캡슐화는 기능의 조직성과 논리성을 연관시킨다.
• HardcoreCppStudy/두번째숙제/CharacteristicOfOOP/김아영 . . . . 5 matches
       데이터 은닉이란 모듈이 그것이 갖는 기능들을 명세한 인터페이스(interface)를 통해서만 접근되고, 그 기능을 구현하는 방법은 다른 모듈로부터 은닉되도록 하는 것을 말한다. 캡슐화된 객체의 외부 인터페이스를 엄밀히 정의함으로써 독립적으로 작성된 모듈간의 상호 종속성을 극소화하여 캡슐화된 객체는 외부 인터페이스만을 통하여 접근될 수 있도록 한다면, 세부적인 구현 상세 사항에 대해서는 객체내에 은닉시킬 수 있다. 또한 캡슐화된 객체는 객체 구현내역을 변경, 혹은 향상시킬 때 이 객체를 사용하는 타 객체들을 변경하거나 다시 컴파일하지 않도록 할 수 있다. 또 모듈의 내부 구현 사항들이 외부의 접근으로부터 보호될 수 있음으로, 그 객체의 정당성을 보증할 수 있으며, 오류가 발생되었을 경우에 오류는 한 모듈내로 국지화될 수 있다.
       '''* 캡슐화(Encapsulation) '''
       우리가 흔히 다루는 각각의 객체들은 서로의 관련되 영역을 사용할 수 있는 부분과 없는 부분이 있다. 이것은 별도로 접근이 가능한 영역과 불가능한 영역으로 나누어서 관리하기 때문이다. 이것을 바로 캡슐화라 한다. 갭슐화는 바로 접근 가능한 코드와 불가능한 코드로 나눔으로 인해서 데이터나 특별한 영역을 보호하거나 감추는 역활을 할 수 있다. 때문에 필요한 경우 데이터의 접근 필드를 제한함으로서 데이터를 보호하는 결과를 얻을 수 있다.
• HardcoreCppStudy/두번째숙제/CharacteristicOfOOP/변준원 . . . . 5 matches
       캡슐화 (encapsulation)
       일반적으로 우리 생활에서 어떤 정보와 어떤 종류의 작업은 개념적으로 서로 연관되어 있음을 많이 접한다. 이러한 연관된 정보와 작업 또는 기능을 하나로 묶는 것은 자연스런 과정이다. 예를 들어 대학교의 인사관리에서는 학생들의 이름, 주소, 학번, 전공 들의 정보를 유지하며 학생들에 관해 가능한 작업인 평점 계산, 주소변경, 과목신청 들의 기능들을 생각할 수 있다. 이러한 정보와 정보 처리에 필요한 작업, 즉 기능들은 모두 학생에 관한 것이므로 학생이라는 테두리로 묶어두는 것이 자연스러운 것이다. 이렇게 연관된 사항들을 하나로 묶는 것을 캡슐화(encapsulation)라고 한다.
       프로그램상에서의 캡슐화의 의미는 프로그램 분석자나 설계자가 주어진 문제를 데이타와 함수들의 세부사항들은 개발의 차후단계에서 정의하고, 객체라는 덩어리 단위로 문제에 대해 생각하게 하는 추상화의 수단을 제공하는 데 있다.
       정보 은폐란 캡슐속에 쌓여진 항목에 대한 정보를 외부에 감추는 것을 의미한다. 즉, 처리하려는 데이타 구조와 함수에 사용된 알고리즘 들을 외부에서 직접 접근하지 못하도록 하고 캡슐 내부의 함수들만이 접근하게 된다. 객체지향에 관한 서적이나 논문에서 이 두가지 개념이 중요시 소개되는 것은 바로 객체라는 것이 캡슐화와 정보 은폐의 원리를 실제의 프로그래밍 언어에서 실현한 것이기때문이다.
       위에서 살펴볼 캡슐화와 정보 은폐의 이점은 우선 객체 내부의 은폐된 데이타 구조가 변하더라도 주변 객체들에게 영향을 주지 않는다는 것이다. 예로서, 어떤 변수의 구조를 배열(array)구조에서 리스트(list) 구조로 바꾸더라도 프로그램의 다른 부분에 전혀 영향을 미치지 않는다. 또한 어떤 함수에 사용된 알고리즘을 바꾸더라도 signature만 바꾸지 않으면 외부 객체들에게 영향을 주지 않는다. 예를 들어, sorting 함수의 경우 처음 사용된 sequence sorting 알고리즘에서 quick sorting 알고리즘으로 바뀔때 외부에 어떤 영향도 주지 않는다. 이러한 장점을 유지보수 용이성(maintainability) 혹은 확장성(extendability)이라 한다.
• HolubOnPatterns/밑줄긋기 . . . . 4 matches
        * 프로그래밍 프로세스는 디자인에서 시작하며 상속, 캡슐화, 디자인 패턴 등을 이용하고 디자은의 실체인 컴퓨터 프로그램을 내놓는다.
        * OO 시스템에서는 데이터 캡슐화가 선택이 아닌 필수이다.
        * Strategy 패턴은 특정 연산을 '어떻게' 수행할 것인지에 대한 전략을 캡슐화한 Strategy 객체를 전달한다.
        * Command 객체가 Observer에 어떻게 통지할 것인가에 대한 정보를 캡슐화하기 때문에, Publisher는 통지 매커니즘을 Command객체에 위임할 수 있다.
• AspectOrientedProgramming . . . . 3 matches
        이해를 돕기 위해, 그리고 설명을 쉽게 하기 위해 예를 들어가며 AOP 개념을 설명토록 하겠다. 어플리케이션의 여러 스레드들이 하나의 데이터를 공유하는 상황을 가정해보자. 공유 데이터는 Data라는 객체(Data 클래스의 인스턴스)로 캡슐화되어 있다. 서로 다른 여러 클래스의 인스턴스들이 하나의 Data 객체를 사용하고 있으나 이 공유 데이터에 접근할 수 있는 객체는 한 번에 하나씩이어야만 한다. 그렇다면 어떤 형태이건 동기화 메커니즘이 도입되어야 할 것이다. 즉, 어떤 한 객체가 데이터를 사용중이라면 Data 객체는 잠겨(lock)져야 하며, 사용이 끝났을 때 해제(unlock)되어야 한다. 전통적인 해결책은 공유 데이터를 사용하는 모든 클래스들이 하나의 공통 부모 클래스(“worker” 라 부르도록 하자)로부터 파생되는 형태이다. worker 클래스에는 lock()과 unlock() 메소드를 정의하여 작업의 시작과 끝에 이 메소드를 호출토록 하면 된다. 하지만 이런 형태는 다음과 문제들을 파생시킨다.
        먼저 ‘Aspect는 꼭 필요한가?’라는 질문에 답해보자. 물론 그렇지는 않다. 이상에서 언급한 모든 문제들은 aspect 개념 없이 해결될 수 있다. 하지만 aspect는 새롭고 고차원적인 추상 개념을 제공해 소프트웨어 시스템의 설계 및 이해를 보다 쉽게 한다. 소프트웨어 시스템의 규모가 계속 커져감에 따라 “이해(understanding)”의 중요성은 그만큼 부각되고 있다(OOP가 현재처럼 주류로 떠오르는데 있어 가장 중요한 요인 중 하나였다). 따라서 aspect 개념은 분명 가치 있는 도구가 될 것임에 틀림없다.다음의 의문은 ‘Aspect는 객체의 캡슐화 원칙을 거스르지 않느냐?’는 것이다. 결론부터 말하자면 ‘위반한다’ 이다. 하지만 제한된 형태로만 그렇게 한다는데 주목하도록 하자. aspect는 객체의 private 영역까지 접근할 수 있지만, 다른 클래스의 객체 사이의 캡슐화는 해치지 않는다.
• Gof/Strategy . . . . 3 matches
       비슷한 문제들을 해결할 수 있는 알고리즘의 군들을 정의하고, 각각의 알고리즘을 캡슐화하고, 그 알고리즘들을 교환할 수 있도록 한다. Strategy는 알고리즘들로 하여금 해당 알고리즘을 이용하는 클라이언트로부터 독립적일수 있도록 해준다.
       이러한 문제는, 각각의 다른 linebreaking을 캡슐화한 클래스를 정의함으로 피할 수 있다. 이러한 방법으로 캡슐화한 알고리즘을 stretegy 라 부른다.
• JavaStudy2003/두번째과제/곽세환 . . . . 3 matches
        캡슐화(Encapsulation):
        캡슐화는 모듈성(modularity)과 정보은닉(information hiding)을 제공한다.
       캡슐화, 메시지, 클래스, 인스턴스, 객체, 상속, 다형성
• 새싹교실/2012/AClass . . . . 3 matches
        * 클래스, 생성자, 캡슐화, default 생성자, this, overloading 등등.
        * [황혜림] - 처음부터, 클래스의 특징에는 캡슐화가 있다. 캡슐화는 왜쓰는가.... 잘못된 접근을 막아야 한다는데. 아,,ㅂㄱㅍ 아 오버로딩이 새로 생각났다. 생성자 - 클래스명과 항상 같게 사용하여야 한다.
• AcceleratedC++/Chapter13 . . . . 2 matches
        protected 레이블로 지정된 멤버들은 자식 클래스에서 직접적인 접근이 가능다. 그러나 클래스의 외부에서는 접근이 안되기 때문에 캡슐화의 장점을 유지시킬 수 있다.
        특정 형의 포인터를 캡슐화시킨 인터페이스를 제공해서, 프로그래머에게 포인터가 보이지 않도록 하는 방법을 제공한다.
• DesignPatternsAsAPathToConceptualIntegrity . . . . 2 matches
       디자인 패턴은 "변화하는 부분에 대해 캡슐화하라"는 1차적인 모듈화 원리에 따라 마이크로-아키텍쳐들을 디자인하는 가이드를 제공한다.
       EDO 와 RDD 는 이 1차 원리인 "변화하는 부분에 대해 캡슐화하라"와 그들의 명확한 룰들에 따라 적용될때 다른 방법들로 만나서, 다른 디자인 패턴들을 생성해 낼 것이다. 예를 들면, RDD는 Mediator, Command, TemplateMethod, ChainOfResponsibility (주로 behavior), EDD 는 Observer, Composite, ChainOfResposibility(주로 structure) 를 생성해낼것이다.
• Gof/Command . . . . 2 matches
       request 를 객체로 캡슐화 시킴으로서 다른 request들을 가진 클라이언트를 인자화시키거나, request를 queue하거나 대기시키며, undo가 가능한 명령을 지원한다.
        * 기본명령어들를 기반으로 이용한 하이레벨의 명령들로 시스템을 조직할 때. 그러함 조직은 transaction을 지원하는 정보시스템에서 보편화된 방식이다. transaction은 데이터의 변화의 집합을 캡슐화한다. CommandPattern은 transaction을 디자인하는 하나의 방법을 제공한다. Command들은 공통된 인터페이스를 가지며, 모든 transaction를 같은 방법으로 invoke할 수 있도록 한다. CommandPattern은 또한 새로운 transaction들을 시스템에 확장시키기 쉽게 한다.
• JavaStudy2003/두번째과제/노수민 . . . . 2 matches
        * 캡슐화 : 변수(상태)와 메소드(행동)를 하나의 묶음으로 캡슐화한다.
• MoreEffectiveC++/Techniques1of3 . . . . 2 matches
       이제, 단일한 객체 만들기 방법에 관한 디자인 방법은 알수 있을 것이다. 그리고, 객체를 숫자로 제어하는 것은 세가지의 생성 상황에 의해서 폭잡한 상황을 만들어 나간다는 것을 알것이다. 이것을 위해서 생성자의 사역(private)역시 설명했다. 캡슐화된 thePrinter함수는 Printer라는 단일한 객체를 제한하고, 그것을 사용할수 있게 한다. thePrinter가 대안일까. 하지만 결국 thePrinter는 C++의 일반적인 방법인 이러한 디자인의 코드를 불가능하게 한다.
       당신이 볼수 있는 것처럼 스마트 포인터는 더미(dumb)포인터를 그냥 사용하는 것과 크게 차이점은 없어 보인다. 그것은 캡슐화에 대한 효율성을 논하는 것과 같다. 스마트 포인터를 사용하는 클라이언트는 그냥 더미(dumb)포인터를 사용하는 것처럼 사용하므로서, 스마트 포인터가 어떤 일을 행하는지 특별히 관심을 쏟을 필요가 없게 만드는 것이 관건이다.
• MoreEffectiveC++/Techniques2of3 . . . . 2 matches
       대단하지 않은가? 누가 객체를 사용하지 않을까? 누가 캡슐화를 반대할까? 하지만, 이러한 신기한 String 클래스에 관한 기반 생각은 클라이언트 측에서 새부사항을 알필요가 없어야 밑이 나는 것이다. 알아야 할것이 없을수록 더 좋은 상태이다. 현재, String을 쓰는 기본 인터페이스는 바뀐것이 없다. 단지 참조세기의 기능이 추가되었을 뿐이다. 그래서 클라이언트는 기존 코드를 고칠 필요가 없다. 단, 재 컴파일(recompile)과 재링크(relink) 과정만이 남아 있을 것이다. 이러한 비용은 참조세기가 주는 이득에 비하면 정말 완전히 없는 비용이나 마찬가지이다. 캡슐화는 정말 좋은거다. (작성자주:뭐야 이 결론은..)
• AcceleratedC++/Chapter12 . . . . 1 match
       그렇다고해서 data가 가리키는 포인터를 바로 넘기면 프로그램에서 그 포인터를 통해서 데이터의 수정을 할 수 잇기 때문에 캡슐화의 장점이 사라진다.
• AcceleratedC++/Chapter9 . . . . 1 match
        접근함수는 캡슐화의 기본개념이 반하는 것으로 다른 인터페이스 일부로서만 사용해야한다.
• Adapter . . . . 1 match
       자 그럼 Adapter를 적용시키는 시나리오를 시작해 본다. ''Design Patterns''(DP139)에서 DrawingEditor는 그래픽 객체들과 Shape의 상속도상의 클래스 인스턴스들을 모아 관리하였다. DrawingEditor는 이런 그래픽 객체들과의 소통을 위하여 Shape 프로토콜을 만들어 이 규칙에 맞는 메세지를 이용한다. 하지만 text인자의 경우 우리는 이미 존재하고 있는 TextView상에서 이미 구현된 기능을 사용한다. 우리는 DrawEditior가 TextView와 일반적으로 쓰이는 Shape와 같이 상호작용 하기를 원한다. 그렇지만 TextView는 Shape의 프로토콜을 따르지 않는 다는 점이 문제이다. 그래서 우리는 TextShap의 Adapter class를 Shape의 자식(subclass)로 정의 한다. TextShape는 인스턴스로 TextView의 참조(reference)를 가지고 있으며, Shape프로토콜상에서의 메세지를 사용한다.; 이들 각각의 메세지는 간단히 다른 메세지로 캡슐화된 TextView에게 전달되어 질수 있다. 우리는 그때 TextShape를 DrawingEditor와 TextView사이에 붙인다.
• D3D . . . . 1 match
       3D점을 캡슐화 하기위한 구조체.
• DPSCChapter5 . . . . 1 match
       '''Command(245)''' 는 요청(request)이나 명령(operation)을 object로서 캡슐화시킨다. 그러함으로써 각각 다른 명령을 가진 클라이언트들을 파라미터화 시키고, 요청들을 queue에 쌓거나 정렬하며, 취소가능한형태의 명령들을 지원한다.
• DesignPatterns/2011년스터디/1학기 . . . . 1 match
        1. 인터페이스를 이용한 캡슐화는 참 편리하다 Java를 만든사람들은 이걸 목적에 두고 만든것일까?
• Gof/AbstractFactory . . . . 1 match
        factory가 객체를 만들어 내는데 대한 수행과 책임을 캡슐화 하기 때문에 상속한 클래스로부터 클라이언트가 독립적일 수 있다.
• Gof/FactoryMethod . . . . 1 match
       Factory Method 패턴은 이에 대한 해결책을 제시한다. 그것은 Document의 sub 클래스의 생성에 대한 정보를 캡슐화 시키고, Framework의 외부로 이런 정보를 이동 시키게 한다.
• Gof/Mediator . . . . 1 match
        4. MediatorPattern은 객체가 협동하는 방법을 추상화 시킨다. Mediation를 독립적인 개념으로 만들고 하나의 객체에 캡슐화하는 것은 여러분으로 하여금 객체의 행위는 제쳐두고 그 interaction에 집중하게 해준다. 이는 객체가 시스템 내에서 어떻게 interact하는 방법을 명확히 하는데 도움을 준다.
• Gof/Singleton . . . . 1 match
        1. 클래스에 대한 접근이 오직 하나의 인스턴스에게로 제한된다. Singleton 클래스는 자기 자신의 단일 인스턴스를 캡슐화하기 때문에, 클라이언트가 언제, 어떻게 접근하던지 그 접근이 엄격하게 제어된다.
• Gof/State . . . . 1 match
        * Context 의 특정 상태와 관련된 행위들을 캡슐화 하기 위한 관련 인터페이스를 정의한다.
• Gof/Visitor . . . . 1 match
       type-checking 의 기능을 넘어 일반적인 visitor를 만들기 위해서는 abstract syntax tree의 모든 visitor들을 위한 abstract parent class인 NodeVisitor가 필요하다. NodeVisitor는 각 node class들에 있는 operation들을 정의해야 한다. 해당 프로그램의 기준 등을 계산하기 원하는 application은 node class 에 application-specific한 코드를 추가할 필요 없이, 그냥 NodeVisitor에 대한 새로운 subclass를 정의하면 된다. VisitorPattern은 해당 Visitor 와 연관된 부분에서 컴파일된 구문들을 위한 operation들을 캡슐화한다.
• HardcoreCppStudy/두번째숙제 . . . . 1 match
        * OOP(객체지향 프로그래밍)의 주요 특징인 데이터 은닉, 캡슐화, 상속성, 추상화, 다형성에 대해서 기술하세요.
• MoreEffectiveC++/Efficiency . . . . 1 match
       C++에 알맞는 lazy evaluation은 없다. 그러한 기술은 어떠한 프로그래밍 언어에도 적용 될수 있다. 그리고 몇몇 언어들-APL, 몇몇 특성화된 Lisp, 가상적으로 데이터 흐름을 나타내는 모든 언어들-는 언어의 한 중요한 부분이다. 그렇지만 주요 프로그래밍, C++같은 언어들은 eager evaluation를 기본으로 채용한다. C++에서는 사용자가 lazy evaluation의 적용을 위해 매우 적합하다. 왜냐하면 캡슐화는 클라이언트들을 꼭 알지 못해도 lazy evaluation의 적용을 가능하게 만들어 주기 때문이다.
• MoreEffectiveC++/Miscellany . . . . 1 match
       당신의 코드를 변화가 필요할때, 그 효과를 지역화(지역화:localized) 시키도록 디자인 해라. 가능한한 캡슐화 하여라:구체적인 구현은 private 하라. 광범위하게 적용해야 할곳이 있다면 이름없는(unamed) namespace나, file-static객체 나 함수(Item 31참고)를 사용하라. 가상 기초 클래스가 주도하는 디자인은 피하라. 왜냐하면 그러한 클래스는 그들로 부터 유도된 모든 클래스가 초기화 해야만 한다. - 그들이 직접적으로 유도되지 않은 경우도(Item 4참고) if-than-else을 개단식으로 사용한 RTTI 기반의 디자인을 피하라.(Item 31참고) 항상 클래스의 계층은 변화한다. 각 코드들은 업데이트 되어야만 한다. 그리고 만약 하나를 읽어 버린다면, 당신의 컴파일러로 부터 아무런 warning를 받을수 없을 것이다.
• OOP . . . . 1 match
        * [Encapsulation](캡슐화)
• ObjectOrientedDatabaseManagementSystem . . . . 1 match
       객체지향형 데이터베이스 시스템은 두 개의 조건을 만족시켜야만 한다 : 그것은 DBMS이어야 하며, 또한 객체지향형 시스템이어야 한다. 즉, 가능한 범위까지 OODBMS는 객체지향형 프로그래밍 언어의 현재 작업과 함께 일관되어야만 한다. 첫 번째 기준은 영속성, 2차 저장관리, 동시성, 회복, 그리고 특별한 편의 등 다섯 개의 특질로 해석된다. 두 번째 것은 복잡한 객체들, 객체 동일성, 캡슐화, 형 또는 클래스, 상속, 지연 바인딩과 결합된 오버라이딩, 확장성과 계산 결과의 완성도 등 여덟 개의 특질로 해석된다.
• ProgrammingPearls/Column3 . . . . 1 match
        * 복잡한 구조는 캡슐화를 하자 -> 클래스
• ProgrammingWithInterface . . . . 1 match
       Stack을 구현하는 다른 방법은 상속 대신 [캡슐화]를 사용하는 것이다.
• WindowsTemplateLibrary . . . . 1 match
       WTL은 객체지향적인, Win32 를 캡슐화하여 만들어진 C++라이브러리로 MS 에서 만들어졌다. WTL은 프로그래머에 의한 사용을 위해 API Programming Style을 지원한다. WTL MFC에 대한 경량화된 대안책으로서 개발되었다. WTL은 MS의 ATL를 확장한다. ATL 은 ActiveX COM 을 이용하거나 ActiveX 컨트롤들을 만들기 위한 또 다른 경량화된 API 이다. WTL은 MS 에 의해 만들어졌디면, MS 가 지원하진 않는다.
• 데블스캠프2009/수요일후기 . . . . 1 match
        * [송지원] - 사실 너무 아쉬웠다. JUnitTest를 위해 예로 제시한 계산기 클래스도 함수 하나 정도밖에 테스트 해볼 수 없는 이상한 설계의 클래스였다(너무 OOP 다음수업이라 캡슐화에만 신경을 썼던듯). 한 마디로 Java도, JUnit도 맛보기만 해준 꼴이 된것 같다. 하지만 '''JUnit은 확실히 강한 라이브러리다'''. 내가 몸소 느끼고 자발적으로 세미나한 이유도 그렇다. 내 세미나는 즈질이였지만 많은 1,2학년 학우들이 Java로 개발을 진행할 때 도움이 되었으면 한다.
• 데블스캠프2010/다섯째날/ObjectCraft . . . . 1 match
       3. 캡슐화

Found 38 matching pages out of 7540 total pages (5000 pages are searched)

You can also click here to search title.