1. Duplicated Code
2. Long Method
3. Large Class
4. Long Parameter List
5. Divergent Change
6. Shotgun Surgery
7. Feature Envy
8. Data Clump
9. Primitive Obsession
10. Switch Statement
11. Parallel Inheritance Hierarchies
12. Lazy Class
13. Speculative Generality
14. Temporary Field
15. Message Chains
16. Middle Man
17. Inappropriate Intimacy
18. Alternative Classes with Different Interface
19. Incomplete Class Library
20. Data Class
21. Refuse Bequest
22. Comment

어느 프로젝트에서나 난 저위의 것들을 적당히 풍겨가며 개발을 하고 있다.
최근에 그 문제점이 무엇인지 생각을 많이 해보았다.
1. 개발스킬 부족.
    : 난 OOP개념보단 전처리 개념을 먼저 배웠기에..(취업하기전까진 자바가 뭔지도 잘몰랐다.) 코딩스타일이 자바스타일이 아니다...... 게다가 원래 창의적이지 못하다..
2. 업무 분석 미비.
   : 업무를 머리에 완벽히 넣어야 큰틀안에서 코딩해나갈수 있는데.. 부분부분 인계를 받으니 띄엄띄엄 코딩되 앞뒤가 잘맞지 않는다.
3. 기간
  : 나쁜냄새를 맡았으면 리펙토링을 하면된다.. 불가능하지도 않다. 프로젝트 기간 예를 들어 근무일 모두 야근을 한다. 나쁜냄새를 맡지 않더라도.. 그럼 야근이 끝나고. 리펙토링을 해야하는건가? 항상 왜 나쁜 냄새를 맡고 수정하지 않는걸 개발자 책임으로 모는지.. 이해가 가지 않는다. 리펙토링할 시간을 달라. 학교에서 수업끝나고 남는시간에 개발하는게 아니다. 9시부터 10시 11시까지 일정에 따라가기 바쁘다.. 내공이 부족해서? the One이 아니라면 대부분 일정에 쫓긴다. 아니 the One에겐 더많은 일을 주기에 더쫓길걸...

대충 이렇지 않을까....
문제는 알지만 난 개발에 미친사람이 아니기에 어떻게 할수가 없다. 업무분석에 스케쥴기간에 주말을 다 내주고 개발스케쥴끝나면 밤새서 리펙토링하고 이런건 못하겠다.....

나름대로 열심히 하고 싶지만... 이런건 아니라고 본다.

Eolin에서 자바 블로그가 생겼다는 글을보고 들어갔다...
좋은 글들이 많아서...
하나 퍼왔다...

http://sdnkorea.com/blog/167

Singleton 패턴

설계 패턴은 소프트웨어 설계에서 상에서의 공통 문제에 대한 일반적인 솔루션이라 할 수 있는데, 그 기본 개념은 솔루션을 코드로 변환하면 그 코드를 다양한 문제 상황에 적용할 수 있다는 것이다. 설계 패턴에 관한 논의는 Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides 등이 공동 집필한 Design Patterns: Elements of Reusable Object-Oriented Software에서 시작되었다. 이 책에서는 패턴을 생성, 구조, 동작의 세 가지 주요 영역이 포함하여 다양한 주제 영역으로 분류하고 있다. 생성 패턴(Creational patterns)은 객체가 생성되는(객체 지향 용어로는 ‘예시되는(instantiated)’) 방식을 기술한다. 구조 패턴(Structural patterns)은 객체들을 연결하고 결합하는 방식을 도와주고, 동작 패턴(Behavioral patterns)은 알고리즘 또는 통신 메커니즘을 기술한다. 몇 가지 공통 패턴의 이름으로는 생성 영역의 Singleton, 동작 영역의 Observer, 구조 영역 Facade를 들 수 있다. 본 테크 팁에서는 자바 프로그래밍 언어의 맥락에서 Singleton 패턴을 면밀히 살펴보도록 한다.

Singleton 패턴은 흔히 사용되는 생성 패턴의 하나이다. 이는 하나의 클래스에서 오직 하나의 인스턴스만 생성되도록 보장하는 기법을 기술한다. 이는 본질적으로, 클래스 외부의 누구도 객체의 인스턴스를 생성하지 못하게 하는 접근법을 사용한다. 일반적으로 Singleton은 느리게 생성되어 필요 시점까지 메모리의 요구를 줄여준다. 이 접근법은 다양한 방식으로 구현이 가능하다.

생성되고 있는 하나의 인스턴스가 서브클래스가 되리라는 것을 알고 있다면, 상위(parant) 클래스를 추상화하고 메소드를 제공하여 현재의 인스턴스를 얻도록 한다. 그 일례로 AWT 패키지의 Toolkit 클래스를 들 수 있으며, Toolkit을 위한 생성자는 public(이 특정 경우에는 디폴트 생성자)이다.

   public Toolkit()

그리고 클래스는 특정 서브클래스(이 경우에는 플랫폼을 따름)를 얻기 위한 getDefaultToolkit() 메소드를 가진다.

   public static Toolkit getDefaultToolkit()

썬 자바 런타임을 탑재한 Linux 플랫폼 상에서 특정 서브클래스는 sun.awt.X11.XToolkit 타입이다. 하지만 사용자는 공통 추상 상위 클래스인 Toolkit을 통해 클래스에 액세스할 뿐이므로 이 부분까지 알아야 할 필요는 없다.

Collator 클래스는 이 패턴의 또 다른 예로, 약간의 차이가 있다. 이 클래스는 2개의 getInstance() 메소드를 제공하고, 무인자(no-argument) 버전은 디폴트 locale을 위한 Collator를 얻는다. 이 때, 사용자는 자체 locale을 전달하여 해당 locale을 위한 Collator 인스턴스를 얻을 수 있다. 동일 locale에 대한 Collator를 여러 차례 요청해도 동일한 Collator 인스턴스를 돌려받게 되며, 생성자 자체는 보호된다. 한편, J2SE 표준 라이브러리 전반에 걸쳐 클래서 생성을 제한하는 유사한 방식을 발견할 수 있다.

이 시점에서 클래스 생성자에 대한 액세스를 제한하면 자동적으로 Singleton이 된다고 생각할 수도 있겠으나, 그렇지 않다. 문제가 되는 케이스는 Calendar 클래스인데, Calendar 클래스 생성자는 보호되며, 이 클래스는 클래스 인스턴스를 얻기 위한 getInstance() 메소드를 제공한다. 그러나 getInstance() 메소드를 호출할 때마다 새로운 클래스 인스턴스가 얻어짐으로 결국 이는 Singleton이 아닌 것이다.

사용자의 자체 Singleton 클래스 생성 시에는 오직 하나의 인스턴스만 생성되도록 유의해야 한다.

   public class MySingleton {
     private static final MySingleton INSTANCE = 
       new MySingleton();

     private MySingleton() {
     }

     public static final MySingleton getInstance() {
       return INSTANCE;
     }
   }

정적 메소드 getInstance()는 단일 클래스 인스턴스를 리턴한다. 단일 인스턴스가 서브클래스일 필요가 있더라도 API를 변경할 필요는 없다는 점에 주목할 것.

이론적으로는 INSTANCE 변수가 public일 수 있으므로 getInstance() 메소드는 필요치 않으나 getInstance() 메소드는 향후에 시스템을 변경할 경우 유연성을 제공한다. 바람직한 가상 머신 구현이라면 정적 getInstance() 메소드에 대한 호출을 즉시 처리(inline)해야 한다.

Singleton 생성 작업은 이것으로 그치지 않는다. 즉, Singleton 클래스를 Serializable로 만들 필요가 있다면 반드시 readResolve() 메소드를 제공해야 한다.

  /**
   * Ensure Singleton class
   */
  private Object readResolve() throws ObjectStreamException {
    return INSTANCE;
  }

readResolve() 메소드가 갖추어진 상태에서 deserialization은 단일(오직 하나의) 객체(getInstance() 메소드에 대한 호출에 의해 생성되는 것과 동일한 객체이다)로 귀결되는데, 사용자가 readResolve() 메소드를 제공하지 않을 경우에는 객체를 deserialize할 때마다 객체 인스턴스가 생성된다.

Singleton 패턴은 오직 단일한 리소스만 가지고 있고 그 단일 리소스의 상태 정보에 대한 액세스를 공유할 필요가 있음을 알고 있을 경우에 유용하다. 설계 시에 Singleton 패턴의 필요성을 파악하면 개발을 간소화할 수 있다. 하지만, 때로는 성능 문제로 코드를 refactor하고 나중에 패턴을 사용하게 되기까지 필요성을 인식하지 못하는 수가 있다. 예를 들어, 프로그램이 동일한 클래스의 인스턴스를 반복 생성하여 상태 정보와 함께 전달하기 때문에 시스템 성능이 저하되는 경우가 발생할 수 있다. Singleton 패턴으로 변경하면 동일한 객체가 반복되는 것을 방지할 수 있는데, 이는 시스템이 객체를 재생성하는데 드는 시간을 제거해줄 뿐 아니라 garbage collector가 인스턴스들을 삭제하는 데 소요되는 시간을 줄여준다.

간단히 말해서, 단일의, 그리고 오직 하나의 클래스 인스턴스만 생성되도록 하고자 할 때 Singleton 설계 패턴을 이용하면 된다. 생성자가 연산을 요구하지 않을 경우에는 빈 private 생성자(또는 서브클래스가 필요할 경우에는 보호된 생성자)를 제공한다. 그렇지 않으면 디폴트값으로 시스템이 public 생성자를 제공하게 되는데, 이는 Singleton으로 작업 시 바람직하지 않은 결과라 할 수 있다.

Singleton은 주어진 클래스 로더 내에서만 고유성이 보장된다는 점에 유의할 것. 복수의 서로 다른 엔터프라이즈 컨테이너에 걸쳐 동일한 클래스를 사용할 경우에는 각 컨테이너에 대해 하나의 인스턴스를 얻게 된다.

Singleton 패턴은 종종 Factory 패턴이라 불리는 다른 패턴과 함께 사용되는데, Factory 패턴도 Singleton 패턴과 마찬가지로 생성 패턴의 일종이다. 이 패턴은 특정 객체의 서브클래스, 또는 보다 일반적으로 특정한 인터페이스의 구현이 어떻게 실제로 객체를 생성하는지 기술한다. Factory 패턴의 좋은 보기로 Swing BorderFactory 클래스를 들 수 있다. 이 클래스는 다양한 종류의 Border 객체를 리턴하는 일련의 정적 메소드를 가지는데, 서브클래스의 구현 세부사항을 숨겨서 factory가 인터페이스 구현을 위한 생성자를 직접 호출할 수 있게 해준다. 다음은 BorderFactory의 사용 예제이다.

   Border line = BorderFactory.createLineBorder(Color.RED);
   JLabel label = new JLabel("Red Line");
   label.setBorder(line);

여기서 BorderFactory가 LineBorder를 생성한다는 사실이나 그 생성 방법은 숨겨져 있다. 이번 특정 예제에서는 LineBorder 생성자를 직접 호출할 수 있지만 Factory 패턴을 이용하는 대부분의 경우에는 직접 호출이 불가능하다.

Singleton 패턴을 구현하는 클래스는 다른 클래스의 인스턴스를 생성하기 위해 Factory로 사용할 객체를 리턴하는 경우가 흔히 있는데, 이는 PopupFactory 클래스에 의한 Popup 객체 생성 방식에 의해 예증된다.

Singleton factory를 얻으려면 PopupFactory의 getSharedInstance() 메소드를 호출한다.

   PopupFactory factory = PopupFactory.getSharedInstance();

그런 다음 factory의 getPopup() 메소드를 호출하여 factory에서 Popup 객체를 생성하고, 상위 컴포넌트, 그 콘텐츠, 포지션을 전달한다.

   Popup popup = factory.getPopup(owner, contents, x, y);

보안 컨텍스트에서 Factory 패턴이 자주 사용되는 것을 볼 수 있을 것이다. 다음 예제에서는 특정 알고리즘에 대한 certificate factory를 획득한 다음 stream certificate를 생성한다.

   FileInputStream fis = new FileInputStream(filename);
   CertificateFactory cf = 
      CertificateFactory.getInstance("X.509");
   Collection c = cf.generateCertificates(fis);

BorderFactory에서 본 것처럼, Factory 패턴이 반드시 Singleton 패턴과 함께 사용되어야 하는 것은 아니지만 실제로는 두 패턴이 함께 사용되는 경우도 종종 볼 수 있다.

You have already made a choice. Now you have to understand it.

Somebody tell me.
Why it feels more real when I dream than when I'm awake.
How can I know if my senses are lying?

There is some fiction in your truth,
and some truth in your fiction.
To know the truth, you must rist everything.

Architect: Hello, Neo.

Neo: Who are you?

Architect: I am the Architect. I created the Matrix. I have been waiting
for you. You have many questions and although the process has altered
your consciousness you remain irrevocably human, ergo some of my answers
you will understand and some of them you will not. Concordantly, while
your first question maybe the most pertinent you may or may not realize
it is also the most irrelevant.

Neo: Why am I here?

Architect: Your life is the sum of a remainder of an unbalanced equation
inherent in the programming of the matrix. You are the eventuality of an
anomaly which despite my sincerest efforts I have been unable to
eliminate from what is otherwise a harmony of mathematical precision.
While it remains a burden deciduously avoided it is not unexpected and
thus not beyond a measure of control. Which has led you inexcerably here.

Neo: You haven’t answered my question.

Architect: Quite right. Interesting, that was quicker then the others.

Neo: Others? (What others? How many? Answer me)

Architect: The Matrix is older then you know. I prefer counting from the
emergence of one integral anomaly to the emergence of the next. In which
case this is the sixth version.

Neo: Then there are only two possible explanations, either no one told
me, or no one knows.

Architect: Precisely, as you are undoubtedly gathering the anomaly is
systemic. Creating fluctuations in even the most simplistic equations.

Neo: Choice, the problem is choice.

Architect: The first matrix I designed was quite naturally perfect; it
was a work of art, flawless, sublime. A triumph equaled only by its
monumental failure. The inevitability of its doom is apparent to me now
as a consequence of the imperfection inherent in every human being. Thus,
I redesigned it, Based on your history to more accurately reflect the
varying grotesqueries of your nature. However I was again frustrated my
failure. I have since come to understand that the answer eluded me
because it required a lesser mind a mind less bound by the parameters of
perfection. Thus the answer was stumbled upon by another, and intuitive
program, initially created to investigate certain aspects of the human
psyche. If I am the father of the matrix, she would undoubtedly be its
mother.

Neo: The Oracle

Architect: Please, as I was saying she stumbled upon a solution whereby
nearly 99 percent of all test subjects accepted the program as long as
they were given a choice, even if they were only aware of the choice at
an unconscious level. While this answered function it was obviously
fundamentally flawed thus creating the otherwise contradictory systemic
anomaly. That if left unchecked might threaten the system itself, ergo
those that refuse the program while the minority if unchecked would cause
an escalating probability of disaster.

Neo: This is about Zion

Architect: You are here because Zion is about to be destroyed. Its every
living inhabitant terminated, its entire existence eradicated.

Neo: *beep*

Architect: Denial is the most predictable of all human responses. But,
rest assured, this will be the sixth time we have destroyed it. And we
have become exceedingly efficient at it. The function of the One is now
to return to the source allowing a temporary dissemination of the code
you carry reinserting the prime program after which you will be required
to select from the matrix 23 individuals, 16 female 7 male, to rebuild
Zion. Failure to comply with this process will result in a cataclysmic
system crash killing everyone connected to the matrix. Which, coupled
with the extermination of Zion will ultimately result in the extinction
of the entire human race.

Neo: You won’t let it happen, you can’t. You need human beings to
survive.

Architect: There are levels of survival we are prepared to accept.
However the relevant issue is whether you are ready to accept the
responsibility for the death of every human being in this world. It is
interesting reading your reactions. Your 5 predecessors were by design
based on a similar predication a contingent affirmation that was meant to
create a profound attachment to the rest of your species facilitating the
function of the One. While the others experienced this in a very general
way your experience is far more specific, Vis a vie love.

Neo: Trinity

Architect: Apropo, she entered the matrix to save your life at the cost
of her own.

Neo: No

Architect: Which brings us at last to the moment of truth, wherein the
fundamental flaw is ultimately expressed and the anomaly revealed as both
beginning and end. There are two doors, the door to your right leads to
the source and the salvation of Zion, the door to your left leads back to
the matrix to her and to the end of your species. As you adequately put,
the problem is choice. But we already know we you are going to do don’t
we? Already I can see the chain reaction the chemical precursors that
signal the onset of an emotion designed specifically to overwhelm logic
and reason. An emotion that is already blinding you from the simple and
obvious truth, she is going to die and there is nothing you can do to
stop it. Hope, it is the quintessential human delusion simultaneously the
source of your greatest strength and your greatest weakness.

Neo: If I were you, I would hope that we don’t meet again.

Architect: We won’t.

문서작업중이라. 정리가 하나도 안된다...(사실 언제나 이렇다.)

이전다음

0