소프트웨어에서의 추상화 그리고 상속,다형성,캡슐화

Project 2009/07/01 23:22
 써니님의 추상화에 대한 글에 제글이 인용되어 있기에 다시한번 제 생각을 정리해야할듯 해서
글을 씁니다.   

 1. 추상화는 무엇?

 이전의 글(추상화와 실용주의)에서 언급했듯 추상화란 인간의 본능이자 특성입니다.
우리를 둘러싼 복잡한 환경에서 좀더 현명한 판단을 위해 사물을 단순화 시키는 것을 말합니다.
우리는 추상화를 통해 사물의 특성을 뽑아내고 불필요한 부분을 제거합니다.
하지만 이런 추상화를 하는데 있어 중요한것은 하위 개념을 포함하는 개념을 추출하는데 있습니다.

 2. 객체 지향이란?

 객체지향이란 아래의 두가지 측면으로 생각해볼수 있습니다. 
 
 a. 철학적인 측면
  플라톤의 이데아론에서 말하듯 우리를 둘러싼 모든 것들은 이상의 것(이데아)에서 파생한것(객체)이라
보는데서 클래스와 인스턴스의 관계를 나타낼수가 있고, 또는 모든 사물을 객체로 보고 객체간의 메세지를 
주고받는 개념(세포)으로 보는 관점등이 있습니다.
   
b. 설계와 구현의 측면
-객체지향 분석 및 설계(OOAD (Object-oriented analysis and design))
 실세계를 정의하기위한 기술로서의 객체지향을 말할수 있습니다.
해결하려는 실세계의 문제를 분석, 정의, 분류를 한뒤 구현을 위한 설계까지의 단계를 말합니다.

-객체지향 구현기술
 객체지향적 개념을 구현하는데 있어 도움주는 언어적 지원 , 기술등을 이야기합니다.
객체지향 언어, 디자인패턴등 구현에 관련된 모든 기술을 말합니다. 

 3. 상속 , 다형성 , 캡슐화?

 일반적으로 객체지향적을 이야기하며 말하는 세가지 개념이지만 얼마전 강규영님이 언급했듯 
객체지향이라는 패러다임에서 갑자기 나온 새로운 개념들은 아니라고 생각됩니다.
제가 보는 측면은 실용주의 입니다. 즉 위의 모든것은 개념은 실용적인 측면에서 나왔다고 보는 입장입니다.

 a. 상속은 재사용성?
 상속은 재사용의 측면에서 이해할수 있습니다.
상속은 같은 동작을 하는 코드를 쉽게 재사용하여 수정할수 있도록 도와줍니다.
하지만 일반적으로 재사용은 상속을 이용하지 않아도 가능하며 여러 문제점을 불러 일으키기에
최근에는 구성을 활용하는 것을 추천하지만 상속도 적절히 사용하면 쉽게 문제를 해결하는 
방법이 될수가 있습니다.

b. 다형성은 결합도?
 복잡하게 얽혀있는 소스코드들 사이에 존재하는 결합도를 줄이기 위해서 도입된 개념입니다.
한가지 통로를 통해 같은 행동을 하는 객체들을 제어할수가 있습니다.  


c. 캡슐화는 복잡도
 캡슐화에 대해서는 이전 접근제한자에 대해 쓴 글에서 언급했듯, 다른 소스코드를 이용함에 있어서
알 필요가 없는 정보를 숨기며 필요한 인터페이스만을 제공해 복잡도를 제어하는 기술입니다.
 우리가 다른사람의 소스 코드 및 라이브러리를 사용함에 있어서 인터페이스 정보만 알고도 이용할수
있는 것은 이 개념에 의해서 입니다.


d. 그밖에.. interface , abstract 
 Interface 및 Abstract에 대해서는 예전에 쓴 글에서 언급했듯, 
순전히 다형성과 상속을 구현하기 위해서 도입된 개념입니다.(없어도 객체지향을 구현하는데는 문제없습니다.)
 하지만 앞서언급한 글에 나타나있지않은 다른 측면은 강제구현에 있습니다.
즉 많은 사람들이 함께 개발함에 있어서 구현에 제약을 강하거나 , 강제함으로서
개발 생산성과 질을 높일수 있습니다.




 위의 abcd에서 말한 개념들은 객체지향 언어마다 다른 방식으로 구현되어 있습니다.
 또 위의 글은 어디까지나 제가 보는 관점의 이야기입니다. 
사물을 보는 방법은 여러가지가 있을수 있다고 생각합니다.
 객체지향을 IF문의 제거로 볼수도 있고, 단일지점제어의 관점으로 볼수도 있듯 정답은 없다고 생각하네요.


Trackback 0 : Comment 1

정말 다형성(서브타입)이 IF를 줄일수 있을까?

Project 2009/06/25 01:56

 얼마전 강규영님의 글 "OOP란 조건문(if)을 줄이는 것"을 보고
정말 서브타입 다형성(subtype polymorphism) 이 if,else를 줄일수 있는가 생각해보았다.


예를들면 아래와 같은 클래스가 있다고 생각을 해보자.
식사 {
        밥() {
                if (아침) {
                   return 빵과우유;
                } else if (점심) {
                   return 짜장면;
                } else if (저녁) {
                   return 삼겹살;
                }
        }
}
아침 점심 저녁을 비교하는 세개의 IF문이 존재한다.
이 클래스를 아래와 같이 Interface를 이용해 분리를 해보겠다.

// 인터페이스
interface Food {
        eat();
}


// 오전을 나타내는 클래스
class Morning implements Food {
        eat() {
           return 빵과우유;
        }
}

// 오후을 나타내는 클래스
class Afternoon implements Food {
        eat() {
          return 짜장면;
        }
}

// 저녁을 나타내는 클래스
class Evening implements Food {
        eat() {
          return 삼겹살;
        }
}

class Meal {

        Food s;.

        // 식사지정 메소드
        setFood(Food s) {
           this.s = s ;
        }

        // 밥먹기
        eat() {
           return s.eat();
        }
}



public MealMain {
        public static void main(String[] args) {

                Food morning = new Morning();
                Food afternoon = new Afternoon();
                Food evening = new Evening();
                        

                Meal ml = new Meal();

                // 아침                
                ml.setFood(morning);
                print(ml.eat());

                // 점심                
                ml.setFood(afternoon);
                print(ml.eat());

                // 저녁                
                ml.setFood(evening);
                print(ml.eat());


        }
}

간단한 소스코드라서 별로 어렵지 않을것이다 (내가 복잡한걸 못 짠다.-_-)
결과적으로 IF문이 없어져 버렸다.

그런데 정말 다형성으로인해 IF문이 줄었던것일까?

public MealMain {
        public static void main(String[] args) {

                Morning morning = new Morning();
                Afternoon afternoon = new Afternoon();
                Evening evening = new Evening();
                       
                // 아침               
                print(morning.eat());

                // 점심               
                print(afternoon.eat());

                // 저녁               
                print(evening.eat());


        }
}
이 코드또한 다형성을 이용하지 않고도 방금전 코드와 같은 동작을 한다.

다시한번 반문해보자. 정말 다형성이 IF문을 줄였는가?
소스코드의 의도적인 리팩토링으로 인해 나타난 결과는 아닐까?

다형성은 객체간의 결합도 및 의존성을 줄이고
의존성 역전은 그 결과 부수적으로
가능하게된것은 아닐까?


OOP는 IF문을 줄일수가 있다.
(사실 이건 언어적 관점에서 IF문을 줄일수 있는것이다. 결과적으로 비교하는 로직은 없앨 수가 없다.)
하지만 다형성으로 IF문을 줄일수 있다는것은 주객이 전도된 이야기가 아닐까생각한다.
즉 IF문을 줄이기위해(결합도를 낮추기위해) 생겨난 , 필요한 특성이 아닐까?

p.s 강규영님의 의존성역전과 순환참조는 재미있게 읽었습니다.
Trackback 0 : Comments 7

[릴레이] 나의 독서론

Diary 2009/06/15 23:48


 내가 어렸을때 우리집이었으면 하며 상상한 두 가게가 있었는데

그중 하나는 숯불갈비집이고 나머지 하나는 서점이었다.


 그만큼 냔 고기와 책을 좋아했었는데, 용돈이 생기면 그 당시 500원 , 1000원짜리 잡다한 

책을 사다보고 심지어는 생일선물로도 도서상품권을 달라고 말할 정도였다.  


 내가 책을 좋아하기 시작한건 정확히 언제부터인지는 기억하지 못하지만 지금 생각해보면 

집에 오래된 백과사전 있었는데 그걸 읽으며 시간을 보낸것이 지금의 버릇이 되었던 것 같다. 


 내가 책을 읽으며 처음 받은 충격은 ,지금도 기억에 남지만 아마 초등학교였던걸로 기억한다.

그날도 집에서 백과사전을 보고있는데 내가 좋아하던 과학 및 수학부분을 읽었던것같다..


 책에는 직각삼각형이 그려져 있었고 삼각형의 빗변을 변으로 이루는 큰 정사각형과

나머지 직각을 이루는 두변을 각각 변으로 이루는 정사각형이 이루는 면적이 서로 같다는

것이 그림으로 표현되어있었다. 즉 쉽게말해 피타고라스 정리의 기하학적 증명이었다.


 난 그걸 깨닭았을때 처음 머리가 짜릿하며 즐거운 기분이 드는걸 알게된것같다.

그때 이후로 독서란 나에게 즐거움 이었다.

 사실 독서란 한두단어로 쉽게 표현되지 못할 큰 의미를 담고있다.

다른 많은 후보들 예를들면, 독서는 저자와의 대화이며, 새로운 세계와의 만남이며,  

과거를 통한 미래를 위한 준비이며 등등등 수많은 후보들이 있었지만, 

나에겐 책하면 가장 먼저 떠오르는 단어는 즐거움이다.

 

 인간의 가장 원초적인 본능중 하나는 호기심인것같다.

 나를 포함한 세상에 대한 궁금중.

 세상을 발전한것은 이런 본능에서가 아니었을까?







다음 릴레이 주자는 제가 아는 분이 그렇게 많지 않고 또 지금은 블로그를 그만두신분들도 많고 

그리고 시간도 얼마 남지 않은듯 해서 일단 부탁드려보지만 그냥 넘어가셔도 괜찮습니다.^^


 먼저 제게 많은 영향을 주었고 지금도 배울 부분이 많이 있는 아스트랄님께 부탁드려봅니다.

아스트랄님은 제가 아는 분중 가장 논리적이며 분석적인 글을 쓰시고 또 알고 계신 지식의 깊이를

헤아릴수 없을 만큼 많이 알고 공부하신 지식인입니다.


 그리고 또 한분은 자주 왕래는 못해 잘 알지는 못하지만 구스님 께 부탁들 드려봅니다.

구스님은 정말 뛰어난 디자이너이자 예술가이며 해박한 지식을 가지고 계십니다.

깊이 있는 한국어는 물론 영어 및 일본어에도 능통하신듯해요.


 갑자기 너무 실례되는 부탁이아닌지 모르겠네요, 크게 부담을 안가지셔도 됩니다^^;


p.s 


이 릴레이는 Inuit님을 시작으로 buckshot님, 고무풍선기린님, 류한석 님, mahabaya님, 어찌할가님, 벼리지기님, 바람의노래님, 모노피스님, 꼬미님, 김형규님, 꼬날님, yuno님, BKLove님,  한날님 그리고 저를 추천하신 아이롱님 을 통해 

저에게 까지 온 독서론 릴레이 입니다.  



이 릴레이의 규칙은 다음과 같습니다.
1. 독서란 [ ]다. 의 네모를 채우고 간단한 의견을 써주세요. 
2. 앞선 릴레이 주자의 이름들을 순서대로 써주시고 
3. 릴레이 받을 두 명을 지정해 주세요.  
4. 이 릴레이는 6월 20일까지만 지속됩니다.기타 세칙은 릴레이의 五常 참조
Trackbacks 2 : Comments 3
◀ PREV : [1] : [2] : [3] : [4] : [5] : ... [91] : NEXT ▶