프로그래밍 관련 법칙(파레토, 디미터, 콘웨이 법칙)

1. 파레토 법칙 (Pareto principle) 

  80 대 20 법칙, 전체 결과의 80%가 전체 원인의 20%에서 일어나는 현상

  소프트웨어의 개발 80%를 20%의 기능을 개발하는데 소비한다. 프로그램 사용자의 20%가 80%의 부하를 발생시킨다. 등으로 사용이 된다. 프로젝트를 설계할 때 이 법칙을 감안해서 설계를 하면 프로젝트를 위험에 빠트리게 하는 위험요소들을 사전에 파악하고 관리가 가능할 것이다. (예를 들어서 중요한 기능을 먼저 구현하던지 특정 사용자들에게서 집중적으로 자원이 소모되는 것을 감안해서 설계 하고 테스팅한다.)

 

 

2. 디미터 법칙 (The Law of Demeter)

:디미터 법칙은 객체 O의 메소드 m은 다음의 객체들의 타입의 메소드만 호출해야 한다는 법칙이다.

 

1. O 객체 자신의 메소드들. (O itself)

 

2. m의 파라미터로 넘어온 객체들의 메소드들.(M's parameters)

 

3. m 안에서 생성 되거나 초기화된 객체의 메소드들.(Any objects created/instantiated within M)

 

4. O객체의 직접 소유하는 객체의 메소드들.(O's direct component objects)

 

5.O객체의 m에서 접근이 가능한 전역변수의 메소드들.(A global variable, accessible by O, in the scope of M)

 

class Demeter {
	private A a;

	private int func() { return 0; }

	public void example(B b) {
		
        C c = new C();
		int f = func(); // 1번 예시
        
		b.invert(); // 2번 예시
        
		a = new A();
		a.setActive(); // 3번 예시
        
		c.print(); // 4번 예시

		// Static으로 설정된 Setting 변수가 있다고 가정할때.
		string UserID = GlobalValues.Setting.getUserID(); //5번 예시
	}
}

 

 위의 종류에 해당하는 객체의 메소드들만 호출을 해야한다. 그렇지 않으면 유지보수 측면에서 문제점들이 발생한다.

 

아래의 예를 보면,

objectA.getObjectB().doSomething(); 
objectA.getObjectB().getObjectC().doSomething();

 

이렇게 호출을 하면 안된다. 이렇게 구현이 되면 사용하는 클래스의 메소드는  ObjectA가 변경이 되었을때만 코드를 수정하거나 고민해야 하는것이 아니라 ObjectB,ObjectC의 변경에도 모두 검토가 필요하다.

즉, 이런식으로 호출하면 ObjectB에만 노출되어야 할 메소드들이 ObjectA에게도 노출이 된다. 이런경우에 ObjectB,ObjectC의 doSomething에서 문제가 발생하면 ObjectA, ObjectB, ObjectC에 모두 영향을 미치게 된다. 최대한 노출 범위를 제한해서 유지보수가 쉽게 해야한다.

 

3. 콘웨이 법칙(Conway’s law)

 코드 구조는 개발팀의 구조를 따라간다는 법칙. 

 예를 들면, 컴파일러를 4개의 팀에서 만든다면 컴파일러는 네 단계로 구성된다.  이것은 어떻게 보면 당연한 결과인데, 팀의 구조다 다르면 컴포넌트로 분리되서 서로 인터페이스로 연계가 된다.

이것에는 장단점이 존재하게 되는데 적절한 수준에서 구조를 정리하고 팀이 분리되어 있더라도 통합이 필요한 것은 통합을 해서 적정수준으로 코드구조를 관리해야한다.

 

출처: http://hongjinhyeon.tistory.com/138