정리하기에 앞서... 객체지향

객체지향?, 객체지향적으로 프로그래밍을 한다?
그냥 클래스 만들고, 메서드 만들고, 모듈화? 적당히 기능을 Util성 클래스 만들고 메서드 몰아넣고
보통 이런식으로 프로그래밍을 해왔던거 같다.

워낙 닷넷이란 넘이 애초에 나왔을때부터 빠른 구현에 중점을 두었었고, 그런 분위기에 익숙해져 있었던거 같다.
어영부영 시간이 흘러 나이도 먹고, 회사내에서 직급이 올라감에 따라 개발 리딩에 대한 부담감이 증대되고, 기존에 내가 해왔던 방식으로 개발 팀을 리딩한다고 생각해보니? 이건 아닌거 같다..-,.-;;
이대론 안되겠다는 위기의식? 이 생겼고,  
부랴부랴 주의를 둘러 보니 이미 주변에선 온갖 개발 방법론이나 아키텍쳐가 넘쳐나는 시대가 되어버렸고, 
왠지 이런걸 모르면 앞으로 밥벌어 먹기 힘들어 질거 같은 불길함이....

이미 늦었다고 할지라도 어쩌겠나, 
배운게 도둑질이라고 살아 남으려면 공부를 해야할터,

그래도 무작정 공부를 시작하기보단 
어떤 목표를 가지고 체계적? 으로 단계를 밟아 나가면서 최종 결과물을 만들어 내는 것이 좋을것 같다. 

최종목표는 
현재 프로젝트를 진행중인 ERP에 최적화 되도록 어플리케이션 프레임워크를 만드는게 목표! 꿈은 원대하게 가지라고 했으니;;;;

 

GRASP 객체지향

객체 책임에 관한 9가지 원칙
1. Information Expert
> 역활을 수행할 수 있는 정보를 가지는 객체에 책임을 부여
> 객체는 데이타와 처리로직이 함께 묶여 있으므로, 자신의 데이타를 감추고자 한다면 오직 자기자신의
   처리 로직안에서만 데이타를 처리하고 외부에는 기능만 제공
2. Creator
> 객체의 생성은 객체의 컨텍스트를 아는 객체에 부여
 ex) A의 생성을 B에 부여
    2-1 B객체가 A를 포함
    2-2 B객체가 A객체의 정보를 기록하는 경우
    2-3 A객체가 B객체의 일부
    2-4 B객체가 A객체를 긴밀하게 사용
    2-5 B객체가 A객체의 생성에 필요한 정보를 가지고 있는 경우
3. Controller
> 사용자의 요청(이벤트)를 처리할 객체를 만들자.
> 객체간의 커플링을 감소시켜 준다.
4. Low Coupling
> 객체들간, 서브시스템들간 상호 의존도가 낮게 역할을 부여
> 객체,서브 시스템의 재사용성을 높이고, 시스템 관리의 편리성을 높여줌
5. High Cohesion
> 각 객체가 밀접하게 연관된 역할들만 가지도록 역할을 부여
6. Polymorphism
> 객체의 종류에 따라 행동 양식이 바뀐다면 다형성 기능사용
7. Pure Fabrication
> 기능적인 역할은 한곳으로
> 데이타베이스에 정보를 저장하거나, 로그를 기록하는 등의 작업은 Information Expert 측면에서는 각 객체에 있는것이 맞지만
  시스템 전반에 사용되는 기능으로 각 객체에 기능이 있는것은 중복, 수정 발생시 전체를 수정해야 함
8. Indirection
> 두 객체간의 커플링을 감소시키려면 인터페이스를 사용
9. Protected Varation
> 변경될 여지가 있는 곳에 안정된 인터페이스를 정의 하여 사용
> ex) ODBC


객체지향 설계 5 원칙 객체지향

1.SRP( Single Responsibility Principle )
 >클래스를 변경해야 하는 이유는 오직 하나 뿐이어야 함.
2. OCP( Open Closed Principle )
 >인터페이스에 대해서는 개발, 변경에 대해서는 폐쇄
3. LSP( Liskov Substitution Principle )
> Sub 타입은 언제든 자신의 기반 타입으로 교체 할 수 있어야 함.
4. DIP( Dependency Inversion Principle )
> 추상화된것은 구체적인 것에 의존하면 안됨, 구체적인 것보다 추상화에 의존하여야 함
5. ISP( Interface Segregation Principle)
> 클라이언트는 자신이 사용하지 않는 메서드에 의존 관계가 있어서는 안됨


1