Object Oriented Programming 1 - Properties of OOP

-

1. Beginning

초기 프로그래밍 언어는 하나의 main 함수 속에서 goto 문을  사용하여 점프하는 형식의 Unstructured Programming 방식이었다. 또한 함수나 프로시져의 개념이 없었기에 모두 global data를 사용하였다. 이는 반복되는 코드를 copy&paste 해야 한다는 문제점과, goto문의 poor readability 등으로 긴 코드를 짜기에는 매우 비효율적이었다.


2. C

C는 Procedural programming(절차적 프로그래밍)의 형식으로 구성되어 있다. 이는 프로그램을 여러 개의 procedure call로 정의하고, 각 함수와 데이터 간의 interaction을 통해 문제를 해결하려는 접근 방법이다. 

하나의 큰 문제를 여러 개의 smaller problem으로 나누어 해결한다는 점에서 Divide & Conquer, Top-down approach, Functional decomposition의 형식이라고도 부를 수 있다.

그러나 이런 프로그래밍 방식은 작은 규모의 프로그램을 짤 때는 매우 효율적이지만, 프로그램의 크기가 커질 수록 전체를 컨트롤하기 어려워진다. 가장 큰 원인은 data와 operation의 decouple(seperation) 이다. 

데이터와 해당 데이터를 컨트롤 하는 함수가 서로 분리되어 있다는 것은, 데이터와 함수 사이의 연결고리를 모두 알아야 해당 프로그램을 maintenance 할 수 있다는 것이다. 이는 프로그램의 규모가 커질 수록 매우 어려운 일이 된다. 

 

3. Object Oriented

따라서 이런 문제점을 해결하기 위한 방법이 바로 Object Oriented Programming이다. OOP는 프로그램을 함수와 데이터로 구분짓지 않고, 함수와 데이터를 모두 가지고 있는 하나의 Object를 프로그램의 가장 기본 단위로 생각한다. 그래서 이런 Object의 interaction을 통해 문제를 해결하는 것이 프로그램이 된다.

 

 

 


댓글

댓글 쓰기

이 블로그의 인기 게시물

IIKH Class from Timothy Budd's introduction to OOP

-
 Timothy Budd의 An Introduction to OOP 3ed. IIIKH(Intelligent Interactive Kitchen Helper) 앞서 객체 지향 프로그래밍의 가장 큰 특징은 Separation of implementation and interface라고 하였다. 즉, 사용자는 해당 오브젝트의 기능들이 어떻게 실현되었는지 알 필요 없이 해당 오브젝트가 제공하는 기능들 만 사용할 수 있는 것이다. 그래서 책의 예제에 제공되는 6개의 클래스가 어떤 기능을 가져야 하는지 public / private 에 대해서 attribute와 method를 생성하였다. #pragma once class Greeter { //greeter component that starts at the very beginning of IIKH. It provides several menu for user to choose. private:     void show_menu(); // main display window when IIKH is started and offer several choices. public:     void call_RecipeDatabase(); // if user selects browse, add, edit recipe.     void call_PlanManager(); // if user selects review or create meal plan. }; class RecipeDatabase { // RecipeDatabase component that store recipes and manage them. private:     Recipe recipeList[100]; //store list of recipe components(objects) and can return, edit, add whenever nee...
자세한 내용 보기

Compiler 9 - Efficient Code generation

-
 이전의 코드 생성은 모두 가정(무한한 레지스터 등)에 의해 리소스를 낭비하였다. 따라서 이를 개선하는 방법이 필요하다. 따라서 memory access의 횟수를 줄여 실행속도를 증가시키고, 쓸모 없는 register의 사용을 줄여 리소스의 낭비 또한 방지한다. 이는 각 레지스터에 가능한 많은 변수를 가지고 있게 하는 방식으로 구현할 수 있다. 이를 위해서 서로 겹치지 않는 live variable을 하나의 레지스터가 공유하여 저장하도록 하면 된다. (덮어씌워도 더이상 사용되지 않는 변수라면 필요 없으므로) 이를 위해서 앞서 진행했던 live variable analysis를 global scope에서 모두 실행한다. 그리고 각 variable을 노드로 가지고, 동시에 존재하는 live variable 사이에 edge가 존재하도록 graph를 그린다. (Register Interference Graph - edge가 존재하는 노드 끼리는 서로 같은 레지스터를 공유하면 안된다) 이 RIG를 통해 연결되지 않은 노드는 같은 레지스터에 할당되어도 문제가 없다는 것을 알 수 있다. 따라서 전체 노드 수보다 적은 레지스터에 모든 변수를 저장할 수 있다. 그리고 TAC로 표현된 각 노드 변수에 서로 연결되지 않았다면 같은 레지스터를 할당하여 어셈브릴 코드를 완성할 수 있다. - k colorable (transform into graph coloring problem) 서로 연결되지 않은 노드에 같은 색을 할당하여 색칠할 때 k개의 색이 필요하다면, k개의 레지스터에 모든 variable을 저장할 수 있다. 따라서 이를 그래프 색칠 문제로 확장하여 이해할 수 있다. 그러나 해당 문제는 NP-hard problem이므로 답은 존재하지만, 효율적으로 풀 수 있는 방법이 없다. (가장 간단한 것이 O(n*2^n)) 따라서 이를 직접적으로 해결하기보다는 heuristic을 사용해야 한다. - Heuristics for graph coloring (not optimal, ...
자세한 내용 보기

Software Engineering 10 - V&V, SOLID principle

-
 Verification & Validation(V&V) - Verification : inspection 과 review를 통해 우리가 올바르게 제품을 만들고 있는지 각 스텝을 검사하는 것 inspection(static) : system의 실행이 필요하지 않고 코드나 requirement, design 등등 representation에 대해서 검사 가능. 소프트웨어의 퀄리티를 올리기 위한 가장 좋은 방법(Best Known Method) -Validation : 만들어낸 artifact가 requirement를 만족하는가? 주로 testing을 통해서 올바른 제품을 만들고 있는지 확인하는 것. testing(dynamic) : 현재 존재하는 에러를 입증 (에러가 없다는 것을 보장해주지 않음) 가장 cost가 많이 필요한 단계. inspection과 testing은 서로 상호보완적인 관계. inspection은 고객의 requirement를 만족하는지 실제로 확인하기 어려움. development testing - release testing - user testing의 stage로 구성된다. - Development testing = unit testing + component testing + system testing 각 unit의 functionality를 먼저 테스트하고, 이들을 합친 component의 interface를 확인한 다음 전체를 합쳐 integration된 시스템이 잘 작동하는지 확인하게 된다. Black box & White Box 내부 작동원리를 모르고 주어진 시스템에 대한 input/output만 구현하는 것이 black box, 내부 작동 원리와 유닛들 사이 interaction, 코드 등을 알고 수행하는 테스트가 white box이다. 주로 development 과정에서 개발자들에 의해 시행되는 테스트는 white box test가 되고, 제 3자가 테스트하는 경우(user / release tes...
자세한 내용 보기