가끔 쌩뚱맞게 개발환경을 처음부터 다시 설치해야 할때가 있습니다. 아름아름 찾아서 각각 다운받아서 설치하는데, 플러그인 설치시 이클립스가 버전업 되면서 해당 URL로 바뀌는 경우가 있는데, 이를 하나 하나 찾아다니기 귀찮아서 여기에 백업용으로 기록합니다.

아래는 이번에 새로 설치할때 설치한 플러그인 환경 입니다. 플러그인 설치 순서는 차례대로 하는것이 충돌 또는 선 요구사항 플러그인 규칙에 어긋나지 않습니다.  베스트한 케이스는 아니고, 그냥 무난히 쓰는 정도인데, 추가적인 것들은 그때 그때 프로젝트 마다 필요할때마다 설치하곤 합니다.
기타 프로젝트 옵션으로 Trac 관련된 플러그인을 설치 했습니다.


이렇게 설치된 이클립스 로드 속도 정말 빠릅니다. 아마도 링크된 프로젝트가 없기 때문인듯 합니다. 아무튼 깨끗한 상태에서 다시 시작한다는 마음으로 시작하는것 같아서 좋습니다. ^^*






Welcome!                     145 Sessions,1856 Registered

Code Camp is a new type of community event where developers learn from fellow developers. All are welcome to attend and speak. Code Camps have been wildly successful, and we’re going to bring that success to Northern California.

The Code Camp consists of these points:

  • by and for the developer community
  • always free
  • community developed material
  • no fluff – only code
  • never occur during working hours

Sessions will range from informal “chalk talks” to presentations. There will be a mix of presenters, some experienced folks, for some it may be their first opportunity to speak in public. And we are expecting to see people from throughout the Northern California region and beyond.


까먹을 것 같아서 @_@) 기록을 남겨둔다.

The second small change from coin project, new numeric litterals has been integrated to jdk7/tl workspace and will be soon promoted into jdk7 main workspace.

The patch introduces two new notations for numeric litterals:

  1. Binary litteral
    Litteral coded in binary starting with prefix 0b. This prefix can be prefixed by minus for negative number.
         0b11 == 3

    -0b11 == -3
    More examples here.

  2. Underscores in litterals
    Allow to use underscore ('_') to separate digits in litterals. Underscore can be used anywhere between two digits.
         long aBankAccountBalance = 1_000_000_000;

    long aVisaCardNumber = 1234_1234_1234_1234;

    long aFrenchPhoneNumber = 01_60_95_77_33;
Of course, these two new syntax can be mixed:
    int value = 0b11111111_00000000_11111111_00000000;


JDK7 에는 기본 자료형 중 숫자와 관련된 표현식이 두개가 추가가 될 것으로 보여집니다.
첫번째로는, 접두사 '0b'입니다. 접두사 '0b'는 2진수를 표현하기 위한 접두사입니다. 접두사 '0b'앞에 '-'를 붙여서 '-0b'를 접두사로 붙이면 음수를 표현할 수도 있다고 합니다.

두번째로, '_'를 이용하여 각기다른 숫자를 표현할 수 있게 된다고 합니다. 예제는 위에서 보시는 2번 항목과 같습니다. 그렇다면, 언더바의 차이를 이용해서 각기다른 값에 대한 표현이 가능해지겠습니다. 그런데 왜 그렇게 할까요? ㅡ_-)?

전화번호 같은 경우
01099998888 로 객체를 표현할 경우 이를 010_9999_8888 로 해서 구분할 수 있도록 만들려는 것일까요?
개발하여 사용하는 국가들의 양식에 맞춰서 쓸 수 있도록 유연성을 높인 표현방식일 수도 있겠다라는 생각을 해봅니다.

당연히, 두가지의 표현식을 합쳐서 사용할 수도 있다고 합니다.
  1. cannot find symbol 또는 cannot resolve symbol
    지정된 변수나 메서드를 찾을 수 없다는 뜻으로 선언되지 않은 변수나 메서드를 사용하거나, 변수 또는 메서드의 이름을 잘못 사용한 경우에 발생한다. 자바에서는 대소문자 구분을 하기 때문에 철자 뿐 아니라 대소문자의 일치여부도 꼼꼼하게 확인해야 한다.
  2. ';' expected
    세미콜론';'이 필요한 곳에 없다는 뜻이다. 자바의 모든 문장의 끝에는 ';'을 붙여주어야 하는데 가끔 이를 잊고 실수하기 쉽다.
  3. Exception in thread "main" java.lang.NosuchMethodError : main
    'main 메서드를 찾을 수 없다.'는 뜻인데 실제로 클래스 내에 main 메서드가 존재하지 않거나 메서드의 선언부 'public static void main(String[] args)'에 오타가 존재하는 경우에 발생한다.
      이 에러의 해결방법은 main 메서드가 클래스에 정의되어 있는지 확인하고, 정의되어 있다면 main 메서드의 선언부에 오타가 없는지 확인한다. 자바는 대소문자를 구별하므로 대소문자의 일치여부까지 정확히 확인해야 한다.
      - args 는 매개변수의 이름이므로 args 대신 arg와 같은 다른 이름을 사용할 수 있다.
  4. Exception in thread 'main' java.lang.NoClassDefFoundError : Help
    'Hello라는 클래스를 찾을 수 없다.'는 뜻이다. 클래스의 'Hello'의 철자, 특히 대소문자를 확인해보고 이상이 없으면 클래스파일(*.class)이 생성되었는지 확인한다.
      예를 들어 'Hello.java'가 정상적으로 컴파일 되었다면 클래스파일 'Hello.class'가 있어야 한다. 클래스파일이 존재하는데도 동일한 메시지가 반복해서 나타난다면, 클래스패스(classpath)의 설정이 바르게 되었는지 다시 확인해보자.
  5. illegal start of expression
    직역하면 문장(또는 수식, expression)의 앞부분이 문법에 맞지 않는다는 의미인데, 간단히 말해서 문장에 문법적 오류가 있다는 뜻이다. 괄호'(' 나 '{'를 열고서 닫지 않거나, 수식이나 if문, for문 등에 문법적 오류가 있을 때 또는 public 이나 static 과 같은 키워드를 잘못 사용한 경우에도 발생한다. 에러가 발생한 곳이 문법적으로 옳은지 확인하라.
  6. class, interface or enum expected
    이 메시지의 의미는 '키워드 class 나 interface 또는 enum가 없다.' 이지만, 보통 괄호 '{' 또는 '}'의 개수가 일치하지 않는 경우에 발생한다. 열린 괄호 '{'와 닫힌 괄호 '}'의 개수가 같은지 확인하자.

이 글은 스프링노트에서 작성되었습니다.

  잘 만들어진 코드란 요구사항을 정확히 만족하는 코드이다. 그런데 현실에선 요구사항들이 끊임없이 변하기 때문에 만족시키기란 쉽지 않다. 결론적으로 변화하는 요구사항을 안정적으로 잘 동작시키는 코드가 잘 짠 코드라고 말 할 수 있다. 그런 의미에서 객체지향이 관심의 대상이 되고 각광받는 이유는 구조적 프로그래밍으로 대변되는 기존의 방식들에 비해 요구사항을 보다 유연하고 안정적으로 만족시키기 때문이다.


개발하기에 가장 좋은 방법은 수준 높은 개발자들 여럿이서 서로 원하는 수준에서 활발히 커뮤니케이션을 하면서 일하는 것이다. 하지만 우리가 일하는 현실을 돌아보자. 회사 내에서 모든 개발자가 같은 수준에서 개발할 수는 없다. 중급 개발자와 초급 개발자가 똑같은 수준에서 개발을 할 수는 없을 것이다.


통일성이나 수정의 용이성 같은 말은 사실 아주 쉬운 의미이다. 함수들의 공통점을 묶고 나아가 클래스간의 공통점을 묶고 컴포넌트간의 공통점을 묶고 이렇게 잘 묶어서 정리하다보면 그게 바로 객체지향 프로그래밍이고 컴포넌트 프로그래밍이다. 물론 프로그램의 크기가 커질수록 묶는 개념도 커지고 요구사항이나 제품의 방향에 따라 고려해야할 것도 많아지지만 언제나 기본에 충실하라. 공통점 묶기가 객체지향의 초석임을 잊지 말자.


공통점 묶기와 조금만 알기는 객체지향 언어에서 상속, 다형성, 캡슐화보다 더 중요한 개념이다. 공통점을 묶고 조금만 알기 위해 노력하다 보니 상속, 다형성, 캡슐화가 필요하게 되고 더불어 추상화(Abstaction), 일반화(Generalization)라고 세분화(Specialization)도 이루어지는 것이다.

  모든 이론이나 개념은 경험적 발전과 필요에 의해 탄생한 것이고 왜 필요하게 된 것인지를 이해하는 것이 단순히 그 정의와 내용을 공부하는 것보다 훨씬 중요하다. 객체지향의 결정판이라고 알려진 디자인 패턴을 어렵게 느끼는 이유 중 하나는 경험의 산물로 보지 않고 공부해서 익혀야 되는 것으로 인식하기 때문이다. 또 캡슐화에 관해 모든 변수를 반드시 private으로 선언해야 한다는 법이 있는 것은 아니다. 모든 개발자가 어떤 변수는 직접 접근하고 어떤 변수는 접근하면 안된다는 것을 안다면 왜 안되겠는가? 하지만 현실적으로 모두가 똑같은 지식과 레벨에서 개발할 수 없으므로 언어가 이런 점들을 지원해주는 것이다.

  언어는 개발자의 실수를 언어가 최대한 막아주어 생산성을 높이는 방향으로 발전한다는 점을 기억하자.


  모든 클래스는 하나의 책임만을 가진다.


  "이 클래스가 무슨 일을 하는 클래스입니까?" 라는 질문에 "이 클래스는 A라는 일을 합니다." 라고 간단히 대답할 수 있어야 한다. "이 클래스는 맑은 날엔 A라는 일을 하고 비오는 날엔 B라는 일을 하고 안개 낀 날에는 C라는 일을 합니다."라고 대답한다면 클래스의 의미를 정확히 파악할 수 없다. 우리가 클래스를 만드는 이유가 관련된 데이터를 하나로 묶어서 이해하기 쉽도록 하는 것인데 클레스가 너무 많은 책임을 가지면 이해하기가 쉽지 않다. 만약 이렇게 여러가지 책임을 가져야 한다면 클래스를 나눌 것을 강력 추천한다. 객체지향에서 제일 어려운 일 중 하나는 관련된 정보로만 클래스를 구성하는 일이다. 변수 하나, 함수 하나를 넣을 때 "과연 이 기능이 이 클래스에 들어가는 것이 맞을까?"에 대해 고민해야 한다. 클래스 하나가 이일 저일 다하게 되는 신(GOD) 클래스가 된다면 그건 그냥 거대한 코드 덩어리일 뿐 어떠한 방법론의 코드도 아니다.

  클래스는 하나의 책임만을 가진다라는 대명제를 중심에 놓는다면 상속으로 이루어진 클래스 트리 전체는 하나의 책임으로 묶인다고 볼 수 있다. 이런 이유로 Java는 단일 상속만을 지원하지만 부족함이 없는 것이다(Java의 상속은 extends 키워드를 사용한다).


  인터페이스 상속(Java에서는 implements)에 대해 알아보자. 앞서 클래스는 하나의 책임을 가짐과 동시에 상속받는 클래스 트리는 하나의 책임으로 묶여진다고 이야기 했다. 하지만 C++의 다중 상속이나 Java의 인터페이스 구현은 필요하기 때문에 존재하는 것이다. 여기서 혼란이 올 수 있다. 두 클래스에서 상속을 받으면 상속받은 자식 클래스는 두 개의 책임을 지는 것이 되니 하나의 책임을 지는 룰에 위배된다고 생각할 수 있다. 하지만 클래스 상속과 인터페이스 상속은 그 의미가 분명히 다르다. 클래스 상속은 분명 부모와 자식간에 같은 책임을 가지지만 작동하는 형태가 다른 것을 의미한다. 반면 인터페이스 상속기능을 추가하거나 클래스 간의 통신을 하기 위한 방법을 제공한다는 의미이다.

  모든 클래스는 하나의 책임만을 가지고 이런 클래스들이 서로 통신하면서 동작하는 것이 객체지향 프로그래밍이다. 이 때 클래스들이 만나는 방법(사전에서 경계면, 접점으로 표현한 부분)을 인터페이스라고 부른다.   Java에서는 모든 함수가 가상 함수(Virtual Function)로 동작하므로 virtual 키워드를 붙이지 않아도 된다. 어쨌든 Java에서는 class 키워드 대신에 더 의미가 분명한 interface 키워드를 제공한다.


  객체지향에서는 클래스 하나를 작성하는 것보다 클래스 사이의 관계를 작성하는 것이 더 중요하다. 클래스 자체가 문제라면 문제 범위를 클래스로 좁힐 수 있지만 클래스 사이의 관계가 문제가 되면 관련된 모든 클래스의 동작 방식이 문제가 되기 때문이다.


  완전한 클래스와 인터페이스 사이에 있는 개념이 추상 클래스이다. 추상 클래스는 인터페이스 개념을 잘 이해하였다면 쉽게 이해할 수 있다. 추상 클래스는 그 이름에서 알 수 있듯이 클래스의 한 종류이다. 하지만 클래스 전체를 다 구현하지 않고 자식 클래스에서 구현의 일부를 위임하기 때문에 실제(Concrete) 클래스라고 부르지 않고 추상(Abstract) 클래스라고 부르는 것이다. Java에서는 추상 클래스를 위한 키워드로 abstract라는 키워드를 지원하여 의미를 더욱 분명히 하였다. 엄밀히 따지면 인터페이스를 작성할 때 구현을 하지 않는 것을 원칙으로 한다. 하지만 인터페이스를 잘 정의하지 못한 상황에서 인터페이스 구현을 하다 보면 자식 클래스들에서 중복으로 구현되는 기능들이 있다. 이런 기능들의 공통점 묶기를 써서 부모 클래스, 즉 인터페이스에 일부 구현하는 경우가 있다. 이 때 java에서는 명백히 인터페이스를 추상 클래스로 변경하도록 컴파일러가 요구한다. 정석대로라면 추상 클래스는 상속 계층에서 책임을 지는 부모 클래스로만 만드는 것이 좋고 인터페이스는 다른 클래스와의 관계만을 기술하므로 구현이 없는 것이 좋다. 하지만 개발을 하다 보면 편의상 인터페이스에 일부 구현을 할 수 있으며 이때는 구현이 있다고 추상 클래스로 보는 것보다는 원래 목적대로 인터페이스로 보는 것이 타당하다.

 

정리

  객체지향 프로그래밍의 기본 단위는 클래스이다. 모든 클래스는 단 하나의 책임을 가지는 것이 좋다. 레고 부품을 조립하는 것처럼 각자의 책임을 가지는 클래스를 우리가 어떻게 조립하는가에 따라 결과물이 달라진다. 객체지향을 통한 재사용의 강력함은 이 분해와 조립에 있다고 할 수 있다. 클래스를 조립할 때 서로 다른 책임의 클래스를 연결하는 방법은 클래스들을 직접적으로 연관시켜서 할 수 있지만 이 방법은 결합도와 복잡도를 증가시키므로 좋은 방법이 아니다. 결합도와 복잡도는 클래스를 연결시켜주는 인터페이스 사용을 통해 낮출 수 있다. 한편 결합도와 복잡도를 낮춘다는 의미는 확장성을 높인다는 의미로 해석할 수 있다. 인터페이스도 클래스 사이를 연결시켜 주는 책임을 가지는 또 다른 클래스의 형태라고 할 수 있다.

이 글은 스프링노트에서 작성되었습니다.

+ Recent posts