블로그 이미지
yukino

카테고리

분류 전체보기 (56)
내이야기 (11)
좋아하는이야기 (17)
책이야기 (1)
건강정보 (3)
개발이야기 (19)
Hustle Doo (5)
Total
Today
Yesterday

'개발이야기'에 해당되는 글 19건

  1. 2008.11.09 design pattern 정리 스크랩
  2. 2008.07.03 5가지 객체지향의 원칙 1
  3. 2008.07.03 임시저장 1
  4. 2008.07.02 좋은 코드를 만들자 1
  5. 2008.07.02 Coding Rule
  6. 2008.07.02 JAVA Naming Rule 2
  7. 2008.06.17 프로그램 검증 도구 1
  8. 2008.06.17 프로그래밍할 때 주의하자
  9. 2008.05.19 log4sql 1
  10. 2008.04.16 spring과 fitnesse 1
어딘가에서 긁어온.. 내용들....
면접 준비하느라 급하게 긁어와서 출처가 어디인지.. 모르겠네요.. -_-;;;


디자인 패턴 정리

패턴이란 특정 컨텍스트(패턴이 적용되는 상황. 반복적으로 일어날 수 있는 상황) 내에서 주어진 문제(해당 컨텍스트 내에서 이루고자 하는 목적 또는 제약조건)에 대한 해결책(일련의 제약조건 내에서 목적을 달성할 수 있는 일반적인 디자인)이다.

"어떤 컨텍스트 내에서 일련의 제약조건에 의해 영향을 받을 수 있는 문제에 봉착했다면, 그 제약조건 내에서 목적을 달성하기 위한 해결책을 찾아낼 수 있는 디자인을 적용한다."

1. 범주별 분류

생성 관련 패턴(싱글턴, 추상 팩토리, 팩토리 메소드, 빌더, 프로토타입)

객체 인스턴스 생성을 위한 패턴으로, 클라이언트와 그 클라이언트에서 생성해야 할 객체 인스턴스 사이의 연결을 끊어주는 패턴.

행동 관련 패턴(템플릿 메소드, 커맨드, 어터레이터, 옵저버, 스테이트, 스트래티지)

클래스와 객체들의 상호작용 하는 방법 및 역할을 분담하는 방법관 관련된 패턴.

구조 관련 패턴(데코레이터, 컴포지트, 프록시, 퍼사드, 어댑터)

클래스 및 객체들을 구성을 통새허 더 큰 구조로 만들수 있게 해주는 것과 관련된 패턴.

2. 클래스, 객체 분류

■  클래스 패턴(템플릿 메소드, 팩토리 메소드, 어댑터)

클래스 사이의 관계가 상속을 통해서 어떤 식으로 정의되는지를 다룬다. 클래스 패턴에서는 컴파일시에 관계가 결정.

■  객체 패턴(컴포지트, 데코레이터, 프록시, 스트래티지, 브리지, 퍼사드, 커맨드, 이터레이터, 옵저버, 프로토타입, 스테이트, 추상 팩토리, 싱글턴)

객체 사이의 관계를 다루며, 객체 사이의 관계는 보통 구성을 통새허 정의. 객체 패턴에서는 일반적으로 실행중에 관계가 생성되기 때문에 더 동적이고 유연함.

3. 패턴으로 생각하기

■  최대한 단순하게

"이 문제에 어떤 패턴을 적용할까?"가 아닌 "어떻게 하면 단순하게 해결할 수 있을까?"에 초점.
가장 단순하고 유연한 디자인을 만들기 위해서 패턴을 사용해야 한다면 그때 패턴을 적용하면 된다.

■  디자인 패턴은 만병 통치약이 아니다

패턴을 사용할 때는 그 패턴을 사용했을 때 설계한 디자인의 다른 부분에 미칠수 있는 영향과 결과에 대해 주의 깊게 생각해 봐야 한다.

■  패턴이 필요한 경우

- 구상중인 디자인상에 적용이 적합하다 확신이 들 경우.
- 시스템의 어떤 부분이 변경될 것이라고 예측할 수 있는 경우.

■  리팩터링과 패턴

행동이 아닌 구조를 개선하는데 목적.

■  패턴 제거

시스템이 점점 복잡해지면서 처음에 기대했던 유연성이 전혀 발휘되지 않게 되는 경우 패턴을 과감하게 제거해 버리는게 최선책일 수 있다. 즉, 패턴을 사용하지 않은 간단한 해결책이 더 나을 것 같다 싶을 때 패턴을 제거하면 된다.

필요한 경우에만 적용하라

지금 당장 변화에 대처하기 위한 디자인을 만들어야 한다면 패턴을 적용해서 그 변화에 적응해야 한다. 하지만 꼭 필요하지 않음에도 불구하고 괜히 패턴을 추가하는 것은 피해야 한다. 괜히 시스템만 복잡해지고 사용률도 현저히 낮거나 없을 수 있다.

4. 패턴을 대하는 마음가짐

초보자들은 언제나 패턴을 사용하는 경향이 있다. 그 과정에서 패턴을 쓰는 연습을 하면서 다양한 경험을 쌓을 수 있는 측면에서는 좋다. 하지만 그러다 보면 반드시 그렇지만은 않다는 것을 배우게 된다. 어떤 디자인이든 될 수 있으면 단순하게 만들어야 한다는 것을 터득하게 된다.
반드시 확장성이 필요한 경우에만 패턴을 써서 조금 복잡하게 만드는 것이 좋다.

경험이 늘어 중급자 수준에 오르게 되면 어떤 상황에서 패턴이 필요하고 어떤 상황에서 패턴이 필요하지 않은지를 파악할 수 있다. 여전히 잘 맞지 않는 패턴을 억지로 적용하려는 경향이 보이긴 하지만, 그 과정에서 정형적인 패턴이 적합하지 않은 상황에서는 패턴을 적당히 변형시켜서 써야 한다는 것을 깨닫게 된다.

달인의 경지에 오르면 패턴을 자연스럽게 구사할 수 있다. 더 이상 패턴을 사용하는 것에 얽매이지 않는다. 문제를 가장 효과적으로 해결할 수 있는 해결책을 찾는데 주안점을 둘 뿐이다. 이는 객체지향 원칙들을 종합적으로 고려함이다. 자연스럽게 패턴이 필요한 상황에 이르면 패턴을 적당히 변형시켜서 적용한다. 그리고 달인들은 유사한 패턴 사이의 관계를 확실히 파악하여 관련된 패턴들의 용도 사이의 미묘한 차이점을 잘 이해하고 활용한다.
달인의 마음가짐은 초보자의 마음자짐이기도 하다. 디자인 과정에서 의사 결정을 할 때 패턴에 대한 지식이 그리 큰 영향을 끼치지 않기 때문이다.

5. 주요 패턴 정리

Posted by yukino
, |
역시나.. 직무교육 중 정리해봅니다.

처음에는 열심히 집중하였으나
시간이 갈수록 집중력이 저하되면서
정리한 내용이 적어지고 있습니다. -_-a

긴 시간동안의 교육이라... 어쩔수가 없네요. 쩝..

아래는.. 또.. 대충.. 적어본 내용들입니다.


* 클래스 상속보다는 객체 합성을 사용하라

#LSP => Liskov Substitution Principle
: IS-A 관계를 만족하도록 상속해야한다.
: DBC 역시 LSP를 위반한다.

void addSuperHeroes(List <String> members) {
 members.add("Superman");
 members.add("Batman");
 members.add("Mr.Hong");
}

String [] members = {"aaa", "bbb", "ccc"};
addSuperHeroes(Arrays.asList(members));

: "정사각형은 직사각형이다."라는 것은 논리적으로는 정상이지만 LSP를 위반하는 결과를 가진다.
:명백한 LSP위반을 제외한 나머지 처리는 연기시키는 것이 최선이다.

#Design By Contract (DBC)
: 계약에 의한 설계
1. 사전 조건
- (입력조건) 메소드를 실행하기 위해 만족해야 하는 조건.
- 원래의 사전 조건과 같거나 더 약한 수준으로만 대체.
2. 사후 조건
- (출력조건) 메소드가 실행된 후 만족해야 하는 조건.
- 원래의 사후 조건과 같거나 더 강한 수준으로만 대체.

#SRP (Single Responsibility Principle)
: 단일 책임의 원칙
: 관계가 없는 것은 따로 떼어내라.
: 서로 연관이 있는 기능이 하나의 클래스로 결합되어야한다. => High cohesion
: 책임을 너무 세분하면 오히려 응집력이 떨어직 된다.
: 미리 변경을 예상하지말고
  변경이 명확하거나 실제 변경이 일어나는 경우에만 분리하도록!


#ISP (Interface Segregation principle)
: 클래스의 재사용성 증가.

Posted by yukino
, |

임시저장

개발이야기 / 2008. 7. 3. 14:10

"유지보수가 쉽다!"라고 말할 수 있는 코드는
1 확장하기 쉽고 2 변경이 적게 추가 개발할 수 있는 코드.

Pattern이란?
=> 특정 context 내에서 주어진 문제에 대한 반복 적용 가능한 해결책
=> library와 같은 정형화되고 구체적인 코드가 아닌 문제 해결을 위한 지침이다.

코드 변경을 최소화 하면서 확장을 쉽게 하자!!

1. 변하지 않는 부분과 변하는 부분을 분리하도록.
: 변하지 않는 부분은 인터페이스로, 변하는 부분은 구현 클래스로.

2. 객체들 간의 상호작용을 최소화. (Loose coupling)
: concreate class의 존재 여부조차 알 필요가 없다.
: 객체간의 의존성을 최소화하라.




*인터페이스의 특징
서비스에 대한 명세이며, 그 서비스에 대한 구현이 아니다.
구현에 종속적이지 않음.
하나의 인터페이스에 대해 여러 개의 구현이 존재할 수 있다.

Adapter, Decorator

[인터페이스에 따른 프로그래밍 예]
JDBC
JNDI Java Naming Directory Interface
JAAS

RMI


Posted by yukino
, |
직무 교육 중...
열심히.. 딴 짓을 하다가
간혹 들리는 내용만 적은 거라 내용이 없네요.

중간중간 비는 부분은 웹서핑으로 채워보아야겠습니다.

3년차 개발자이지만
아직 모르는 것들이 무궁무진한 듯 합니다.

기본도 모르면서 넌 어찌 프로그래밍을 하고 있는 것이냐~!!!!!!!
(자책중입니다요.. -_-;;;;;)


#라인 단위까지 블랙 박스 개념을 가지고 코디를 만들도록 하자.
- 블랙박스 형태 : 소스를 들여다보지 않아도 각 코드 블럭마다 유기적으로 연결되어 있어야 함.


#친절한 에러 메시지 (혹은 로그)를 찍어주도록 하자.
오류 발생 시 바로바로 문제를 파악할 수 있도록 상세히 적어주는 것이 좋다.


#Straightforward-IF문
찾아볼 것.


#Internal Error라는 에러 메시지를 사용할 것.


#Tex



[Reference]
1. Effective Java, Programming Language Guide
2. Code Complete Second Edition
Posted by yukino
, |

Coding Rule

개발이야기 / 2008. 7. 2. 16:04
1. 연산자의 우선 순위를 정해줄 때에는 괄호를 아끼지 말자!

2. Error Log에는
그 Log 만으로 발생한 에러의 원인을 충분히 파악할 수 있도록
필요한 파라미터 정보나 리턴값 정보 등을 상세하게 작성하도록 한다.

3. 문자열을 합쳐서 결과값을 표현하고자할 때에는
    기본적으로는 String 보다는 StringBuffer를 사용하는 것이 성능에 좋다.

4. Vector 대신 ArrayList
Vector는 내부적으로 sync 처리를 하도록 되어 있기 때문에 속도에 영향을 주게됨.

5. Synchronized
불가피하게 Synchronized 메소드를 사용하게 된다면
들어가기 전 검사할 수 있는 조건은 모두 검사하여 호출을 자제하도록 한다.
Posted by yukino
, |

JAVA Naming Rule

개발이야기 / 2008. 7. 2. 14:41
직무 교육 중.. JAVA Naming Rule에 대한 것을 대강 적어봅니다.

코딩하면서 많이 들어와오던 내용들이라
많이 와 닫지는 않지만.

헝가리안 노테이션을 이야기할 때에
그런 규칙들을 지양한다는 것을 알고 있었는데
단어는 처음 들어봐서 새롭네요.

1. Class
: 첫 글자를 대문자로.

2. Method
: 첫 글자는 소문자로.

3. 변수
: Hungarian notation은 권장하지 않음.
* Hungarian notation은 변수 이름을 붙일 때 변수 이름만 보고도 그것이 어떤 데이타형인지 알 수 있게 이름 짓는 것.
ex) String szUserName;

4. 메시지
"해요체", "합쇼체"와 같은 존칭어미를 사용한다.
가능한 밝고 가볍고 맑은 느낌을 주는 자음이나 모음을 사용한다.

*삭제, 승인 등의 경우는 사용자에게 확인 메시지를 표시해주도록 한다.
(사용자가 선택한 action이 실제 이루어진다는 것을 알려주기 위해.)


또 하나.. 자료를 찾아보다가 인지하게된 내용은요.

어떤 분이 예를 들어주신 부분이 있는데
errorCheck() 보다는
checkErrors() 또는 checkError() 형태가 더 좋다고 합니다.

Method naming rule중에
'명사' 혹은 '동사+명사' 형태로 만들라고 하는 내용이 있는 것은 알고 있었지만
위와 같이 checkErrors() 형태가 좋은 방법이라고 하니..
제 코딩 습관이 어떠했었는 지 새삼 생각해보고 있는 중입니다.

어떻게 naming을 을 하고...
어떻게 표현하느냐...에 따라 프로그래밍이 새삼 달라지지 않을까..생각해봅니다.
Posted by yukino
, |

프로그램 검증 도구란..
1. 정적으로 프로그램을 실행하지 않고,
2. 소스 코드를 자동으로 분석하고
3. 오류를 검출하는 프로그램

따라서, 컴파일러도 프로그램 검증 도구의 하나라고 할 수 있다고 합니다.

컴파일러보다 좀 더 테스트에 적합한 도구들이 상용 및 연구용으로 많이 존재하는데...
(도구들은 찾아보시길 ^^;;;)

자바 언어는
개발자의 실수 정도는 런타임시에 오류를 발생시키며, 상당히 제약적인 언어이므로
검증도구가 따로 필요하지 않다고 합니다.

---> 강사님께서 자주 자바를 좋아하시는 듯...한 발언을 하시네요.
       저는 자바 개발자이므로 별다른 감흥은 없었지만요~~

Posted by yukino
, |

직무교육 - 고급프로그래밍 강의 중 생각나는 것 세 가지만 적어봅니다.

1. 수식을 사용할 때에는 순서를 명시해주어라.

2. 누가 봐도 똑같이 해석할 수 있는 코드를 짜라.
(실행 비용이 커도 추상화된 코드가 좋다.)

3. assert 함수를 사용하여 코딩하라.
(오류 검출에 큰 도움이 된다.)
=> 자바에서는 Exception 처리로 해결할 수 있다.
    Exception 발생 후 처리하지 않으면
    사용자 입장에서는 Exception 처리하지 않은 것과 별반 다르지 않다.


소프트웨어 개발자에게 가장 중요하다고 생각하는 것은
2번으로 적어놓은 내용입니다.

물론 1번, 3번의 내용도 중요하겠습니다만....

한번 개발해 놓은 제품은 향후 몇 년은 유지보수 해야하는 경우가 다반사므로..
유지보수를 위해서는 (!!!)
언제. 누가 보던지 이해할 수 있는 코드를 작성하는 것이 중요하다고 봅니다.

자신이 작성한 코드조차도 한 달만 지나 다시 보면
썩.. 눈에 잘 들어오지 않는 경우도 많으니까요.

또한 여러 명이 개발하는 경우..
소스로 다른 사람과 의사소통을 하기 위해서
역시나 알아보기 쉬운 코딩이 중요하다고 봅니다.


요새 느낀 부분을 강의 도중 듣게되어
주저리주저리 적어보았습니다. ^^


기억에 남는 단어들.. : 추상화, Comparable type, Generic

Posted by yukino
, |

log4sql

개발이야기 / 2008. 5. 19. 18:34

이름이 log4j와 비슷하길래... 후딱 프로젝트에 적용!!!!

하지만. 원하는 파일로 log를 떨구는 것은 안되는 듯.
was console에 log가 찍히네요.. 쩝.. -_-;;
혹시.. 아직 제가 설정 방법을 모르는 걸까요..
(좀 더 연구가 필요해.. 으흐으흠.)

머.. 여하튼 코드 한 줄 추가 안하고
실행되는 query며.. parameter value 모두 확인할 수 있고.

설정 자체도 아주 편해서
개발시에 트레이스용으로 유용한 library인 것 같습니다.


[설정방법]
1. 관련 파일 이동
- log4sql.jar : 프로젝트 lib 폴더
- log4sql_conf.jsp

2. jdbc driverClassName 설정값 변경
<property name="driverClassName" value="core.log.jdbc.driver.OracleDriver" />
value값에서 oracle.jdbc.driver.OracleDriver를  core.log.jdbc.driver.OracleDriver로 변경.
(value값은 db 종류에 따라 알맞게 설정.)

3. 설정 변경
log4sql_conf.jsp 실행시켜 원하는 설정값 변경.

[log4sql 프로젝트 홈]
http://log4sql.sourceforge.net

Posted by yukino
, |

spring과 fitnesse

개발이야기 / 2008. 4. 16. 09:44
spring기반 어플리케이션을 fitnesse에서 쉽게 테스트할 수 없을까..............
고민하던 중에 발견하게 된



소스 변경 이력을 뒤져보았는데
가장 최근이 16개월 정도.

ActionFixture, ColumnFixture는 테스트 코드를 작성하기 쉽게 구현되어 있어서
제품에 적용하기 쉬웠는데
RowFixture는..... 어렵군요.

아직 Fixture에 대한 이해도가 낮아서 그런 건지.....

여하튼!!
Spring 기반에서 꼭 필요한 config를 읽어들이기 위한 방법으로는 아주 편리하긴 합니다 ^^

오픈 소스 프로젝트는 역시.. ㅎㅎ


하지만... 아직...... 갈 길이 멀기만 하군요. ㅠ.ㅠ


Posted by yukino
, |