C로 만든 프로그램의 설계 방법?
글쓴이: geekforum / 작성시간: 화, 2001/07/10 - 9:52오전
안녕하세요? 전 주로 Unix/Linux에서 네트웍 서버 프로그래밍을 주로 하고 있습니다. 그런데, 최근 리눅스의 OpenSource들을 보다가 문득 떠오른 궁금증이 있어서 이렇게 질문을 올려 봅니다.
최근 하는 일과 관련되어 리눅스에서 사용되는 데몬 프로그램이나, telnet, ftp등 C로 만들어 져 있는 소스들을 보고 있습니다. 그런데, App를 설계하는 단계를 고려하다 보니, 이런 기존의 리눅스 데몬이나 App들이 작성 될때는 어떤 식으로 설계 문서가 작성되었을까 하는 궁금증 입니다.
OOP 언어들로 코딩을 하게 되는 경우는 UML등을 사용하여 클래스, 오브젝트를 중심으로 설계를 하게 되는데, C언어로 코딩을 하게 되는 경우, 설계라는 것은 결국 고전적인 플로우 차트에 의한 방법 밖에 없는지요.
그렇다면, 리눅스의 데몬들과 같은 OpenSource를 만드는 사람들도 그러한 플로우차트에 기반을 둔 설계를 하고 있을까 하는 궁금증.... 그래서, C로 만들어진 데몬들과 같은 OpenSource들에 대한 소스가 아닌, 설계 문서를 찾아 보려고 했는데 찾지를 못했습니다.
혹시 이러한 C코드로의 설계 관련해서 플로우차트 이상의 좋은 방법을 참고해볼 만한 곳이 있으면 알려주시면 감사하겠습니다.
댓글
저도 아직 허접 프로그래머 이지만...앞에서 어느분이 말씀 하신것 같
저도 아직 허접 프로그래머 이지만...
앞에서 어느분이 말씀 하신것 같은데...
OOP나 SP나... 뭐 별다른 차이가 있겠습니까...
그리고...
누구나 다 아는 내용이지만 무시하고 넘어가는 경우가 많은것 같은데...
OOP는 사물(Object)중심이고,,,
SP는 행동(Action)중심이죠...
설계하실때 이거만 생각하면... 될듯 한데...
지도 C만 줄곳 한 사람입니다... 쑥쓰럽지만...OOP가 유용하고
지도 C만 줄곳 한 사람입니다... 쑥쓰럽지만...
OOP가 유용하고 C가 가지지 못하는 많은 부분을
소화해내고 있는 것도 사실이구요... 하지만
전통 c 만 해온 저로서는
함수 Pointer 및 nested 구조체, Precompiler를 이용하여 극복하고 있읍니다. Precompiler를 이용한 방법은 최근 Opensource를 분석하다 발견한 건데... OOP의 overriding과 비슷하게
처리할 수 있는 방법을 제시하고 있읍니다...
물론 함수 Pointer사용은 Apache source를 보면
줄기차게 나옵니다. module들을 탑재하는데 모든것들이 함수 Pointer죠...상당히 유용합니다. 저도 도움이 많이 됐구요...지금은 대부분을 함수 Pointer와 List를 이용해 코딩합니다...쩝...
그리고 플로우챠트..그거..
저는 일단 가지고 있는 library 검증하고 Data의 흐름을 check할 수 있는 그림만 그립니다. 그리고 library상단에서 그냥 날코딩합니다.
물론 새로운 방법론을
찾거나 새로운 library를 만들기 위해 줄기차게 opensource를 보고 다니고요...
Precompliler를 이용한 방법은
http://61.33.30.40/imsi/msg 을
참고해 보세요... 정말
재밌읍니다...
그럼 이만...쩌비...
헤겍 --;정말 어렵네.....
헤겍 --;
정말 어렵네.....
크크.. 함수 포인터 구조체가 편하긴 하죠.. ^^윈앰프 플러그인
크크.. 함수 포인터 구조체가 편하긴 하죠.. ^^
윈앰프 플러그인들이 다 그렇게 되어있더군요...
dll 파일에는 구조체 하나 return 하는 함수만 있고, 그 struct를 이용하여 모든 것을 처리하는...
(물론 함수 포인터에 지정해 줘야 할 함수들이 꽤 되죠..)
Consider the ravens: for they neither sow nor reap; which neither have storehouse nor barn; and God feedeth them: how much more are ye better than the fowls?
Luke 12:24
저는...C로 짤때는... 음...함수 네이밍으로 해결하는데...
저는...
C로 짤때는... 음...
함수 네이밍으로 해결하는데...
OOP개념이 조금(?)필요하다면..(상속같이 복잡한거 빼버리구 ㅋㅋㅋ)
걍 구조체로 짜놓구 함수앞에 구조체 인수로 넣어버림 --;;
Train_go(train<==구조체임, 10,10)
이런식으로요 ^^;;
참고로 JNI가 이거 비스무리하게 해놧음 --;; 맞나??
Let's be engineers!
결국, 관점의 차이인것 같은데요.C, C++의 정확한 이해와..
결국, 관점의 차이인것 같은데요.
C, C++의 정확한 이해와..
상용프로그램 개발과 다양한 시스템프로그램의 개발은
같다고 봅니다
(구체적인 예는 생략합니다.)
하지만, 프로그램 설계도를 작성할때
무게 중심을 어디에다 두느냐가 문제 아닐까요?
다시 말하면
기능중심이냐?, 재사용 중심이냐?(간단하게)
한가지 더 시간의 문제가 포함되는군요.
이러한 것들을 주축으로 얼마나 잘 설계를 하느냐 가 문제죠.
완벽이란 없으까요?!
(경험에서)
표준화된 도구는 도구일 따름 아님니까?
그냥 편리하게 사용하는거죠..!
그냥 지나가다 이런말을 하고 싶어서 올립니다
그럼 모두 수고를....
음...제가 보기에는 가장 좋은 설계방법은 글쎄요....아마도
음...
제가 보기에는 가장 좋은 설계방법은 글쎄요....
아마도 자신과 주위사람들이 가장 잘 이해하기 좋은 방법을
사용하는 것이라 생각되어집니다..
물론 요즘 좋다는 방법들이 있습니다. 예를 들면 UML을 사용하여 CBD등 기타등등의 방법론들이 나오고 있으나 해석하지 못하믄 땡이죠.. ^^
그리고 리눅스 관련 프로젝트의 프리젠테이션을 보니 기본적인 플로우 차트를 사용하더군요...
아마도 가장 오래되고 모든 사람들(컴에서 개발하는 사람들)이 가장 많이 배우고 싶게 이해하기 때문이것 같습니다...
개인적인 생각을 좀 더 붙인다면,
좋은 개발 방법론들이 많이 있습니다. 하지만 그것은 일종의 교과서적인 내용입니다. 즉, 실제 개발하실때는 이를 기초에 두고 응용을 하셔야 합니다. 개발 방법론 자체를 그대로 따라 프로젝트를 수행하지는 않습니다. 자신의 프로젝트에 맞게 필요한 부분을 뽑아내고, 그리고 추가할 것은 추가해서
방법론을 활용하죠...
그럼...
이쁜 난이...
난이 아버님......^^ 공감합니다!!!!!!~~~~~
난이 아버님......
^^ 공감합니다!!!!!!~~~~~
사실 제가 OOP에 익숙치 않아서 클래스 라이브러리를 사용하여 C++로
사실 제가 OOP에 익숙치 않아서 클래스 라이브러리를 사용하여 C++로 코딩을 하긴 했습니다만, 전체적인 흐름은 여전히 structured 프로그래밍 입니다.-_-;;
사실 단순히 TCP,UDP메시지 받아서 간단한 처리만 해주는 모듈 경우는 그냥 하던데로 C로 면 뚝딱 해 버릴 수 있지만.., OOP로 한번 해 보겠다고 대충 폼을 잡고 있는데 전체 구조는 그냥 structured 프로그래밍 구조가 되 버리더군요.. -_-;;
결국 전체 형태는 그냥 structured 프로그래밍 구조에서 오브젝트 만들고 오브젝트의 메소드를 그냥 C의 펑션 불러다 쓰듯이 불러쓰고마는 그런 어정쩡한...형태가 되다 보니..
UML을 써서 설계 문서를 작성하기도 어정쩡하고..실제 업무가 진행중인데 OOP도 익숙하지 않은 지금 상태에서 UML 공부해서 설계 문서 만들기도 시간이 그렇고..
결국 그냥 플로우 차트에다 의사코드정도를 써야 되겠군요.. 이것참.. 제가 대충 구상한 소스를 보니 정말 C++과 C의 딱 중간 형태인것 같군요.. -_-;;
그런데, 처음 질문에 있는 내용처럼.. C로 리눅스 데몬등을 코딩 하는 사람들이 작성한 설계 문서를 좀 봤으면 좋겠구나 하는 생각이 드는게, 막상 플로우차트를 써 가면서 설계 문서를 작성하려 하니, 요즘 시대에 뒤떨어진것 같은 느낌만 들고.. -_-;;
뭐 지금 구조가 어정쩡하니 제가 완전한 형태의 OOP를 설계 할 단계가 되면 그때나 되야 UML로 설계를 하던지 해야 겠군요..
여하튼 의견 주신분들 감사하고요... 뭐.. 또 도움이 될 만한 의견 있으시면 계속 올려주시면 감사하겠습니다..
그럼..
저도 그런 단계를 겪어봤기 때문에 어떤 말씀을 하시는지 잘 알겠습니다.
저도 그런 단계를 겪어봤기 때문에 어떤 말씀을 하시는지 잘 알겠습니다. :)
그런데, 개념을 확실히 잡을 필요가 있을 것 같아요. 일단, 말씀하신 것처럼
struct stack; void push_stack(stack* s, int data);
이걸
class stack; void stack::push(int data);
이렇게 바꿔 쓴다고 해서 그것이 OOP가 될 수 있는 것은 아닐 것 같습니다. 즉, 단지 클래스를 쓴다고 해서 OOP는 아니라는 것이지요. 그건 단지 abstraction 정도가 되지 않을까요?
OOP의 핵심을 나타내는 키워드는 'virtual'이라고 어디선가 본 적이 있습니다. 즉 interface와 implementation을 분리하여 interface를 abstract class로 나타내고, 구체적인 implementation은 이를 상속한 class에서 해결하고, dynamic binding을 통해서 client는 implementation의 영향을 받지 않고 주어진 interface만으로 프로그래밍을 하는 것.. 뭐 대충 이런 얘기가 되겠지요.
그리고 말씀하신 structured programming이 꼭 object-oriented programming과 배치되는 개념이라는 생각은 안 드는데요. (이건 확실히는 잘 모르겠습니다.) '진정한' OOP를 하더라도 함께 SP 기법이 사용될 수 있는 것 아닌가요?
또한 말씀하신 것이 OOP에 상대되는 개념이 아니라 윈도우에서 프로그래밍할 때 쓰는 message-driven (or event-driven) programming과 상대되는 개념이 아닌가 싶기도 합니다. 뭐라고 하는지 모르겠지만 굳이 이름을 붙이자면 '순차적 프로그래밍' 정도가 될까요?
정말 많은 개념들이 나오는데, 정확한 의미와 범주를 모르겠네요..
이런 거 어디 정리되어 있는 자료가 없을까요?
참고 1. http://www.its.bldrdoc.gov/fs-1037/dir-035/_5154.htm
structured programming: A technique for organizing and coding computer programs in which a hierarchy of modules is used, each having a single entry and a single exit point, and in which control is passed downward through the structure without unconditional branches to higher levels of the structure. Three types of control flow are used: sequential, test, and iteration.
참고 2: http://www.research.att.com/~bs/oopsla.pdf
A language or technique is object-oriented if and only if it directly supports:
[1] Abstraction - providing some form of classes and objects.
[2] Inheritance - providing the ability to build new abstractions out of existing ones.
[3] Run-time polymorphism - providing some form of run-time binding.
구조적 방법론에 따라 문서작성합니다.기능분석하고 플로우 차트 그리
구조적 방법론에 따라 문서작성합니다.
기능분석하고 플로우 차트 그리고, 의사코드 만들어서
코딩을 하지요.
C는 3G 언어로 분류가 되고, 3G언어에 가장 많이 쓰이는
방법론이 구조적 방법론인 관계로...
그리고
UML을 C로 구현한 예를 말씀하신 분이 계신데
나름대로 좋은 발상이라고 생각합니다.
하지만 객체지향의 가장 기본적인 발상
( 현실을 있는 그대로 옮긴다. 다시 말해 데이타와
액션을 일체화시켜 취급한다. 클래스의 가장 기본적인
개념은 여기에 있습니다. 변수와 메소드가 일체화 되는것 )을 C가 충족시킬 수가 없기 땜시로 임시방편이라고
생각합니다.
>>그리고 >>UML을 C로 구현한 예를 말씀하신 분이 계신데 >
>>그리고
>>UML을 C로 구현한 예를 말씀하신 분이 계신데
>>나름대로 좋은 발상이라고 생각합니다.
>>하지만 객체지향의 가장 기본적인 발상
>>( 현실을 있는 그대로 옮긴다. 다시 말해 데이타와
>>액션을 일체화시켜 취급한다. 클래스의 가장 기본적인
>>개념은 여기에 있습니다. 변수와 메소드가 일체화 되는것 )을 C가 충족시킬 수가 없기 >>땜시로 임시방편이라고
>>생각합니다
함수 포인터를 사용하고, C++에서 implicit하게 인자로 받는, this포인터를
explicit하게 넘겨 주면(structure 자신의 포인터..), 변수와 메소드가 일체화 되는것은
*어느 정도*는 해결될 듯하군요..
문제는 상속, 생성자, 소멸자 등인 것 같은데...
상속은 내포 클래스로 *어느 정도* 해결될 듯도 한데, 생성자, 소멸자는,,, 잘 모르겠네요.. ^^;;
dynamic binding은 거의 힘들 것 같구요..
그런 식으로 하고자 하면, 어차피 지저분해진 코드, 구조체 내에 flag
그런 식으로 하고자 하면, 어차피 지저분해진 코드, 구조체 내에 flag를 둬서 생성자에서 이 flag를 set하고 소멸자에서 이 flag를 clear하도록 한 다음 모든 function call시에 이 flag를 먼저 check하도록 하면 되지 않을까요. 물론 이럴 경우 변수에 대한 보호는 불가능 하지만 어차피 c로 oop를 할 생각이라면 이건 convention의 영역이겠죠. 상속의 문제는 생성자에서 자기의 super를 같이 생성하고 나머지는 이 놈에 대한 pointer만 적절히 배치하면 되지 않나요. 그리고 super 역할을 하는 구조체가 어떻게 자기 떨거지들을 대표할 것인가에서는 super 내에 sub object를 가르킬 때 쓸 (char *) 변수하나 두고 또 각 class들 마다 고유한 id를 const로 정해서 이걸 저장해놓는 변수 하나 두고해서 그때그때 그 id에 따라서 casting해서 쓰면 되지 않을까요. 뭐 지금 잠깐 생각한거라 좀 무리야 있겠지만 하고자 하면 안될리야 없겠죠. 그래서 c죠...^^;
써놓고 보니 정말 c다운 해결책이군요...^^; 근데 왜 c로 oop를 할려고들 하실까? 억지 춘향으로 oop 방법론에 껴맞출 수 있을지는 모르겠지만 제 생각엔 c의 장점도 살리지 못하고 oop의 장점도 살리지 못하는 난잡한 코드가 될 것 같은데. 목적이 눈에 보이는 간결한 자료구조도 만들지 못하고 그렇다고 재활용 가능한 black box도 만들지 못하는 온갖 컨벤션과 암호화된 매개변수와 flag들로 가득한 괴물이 탄생할 것 같은 예감.
그러게요..C로도 vtbl 같은 것도 직접 구현해서 dynamic b
그러게요..
C로도 vtbl 같은 것도 직접 구현해서 dynamic binding을 쓸 수도 있긴 있겠지요. (C로 C++ 컴파일러는 왜 못 만들겠습니까? ^^)
근데 이미 잘 쓰이고 있는 C++라는 언어를 두고 굳이 C로 그런 걸 구현하는 방법을 논의하는 것은 그저 호기심 충족의 차원은 될 수 있을지 몰라도 실제적인 효용성은 별로 없다고 봅니다. 그냥 C++ 쓰는 게 낫겠지요.
속도와 실행파일 크기가 중요하다면, 해볼만한 작업이라고 생각합니다.
속도와 실행파일 크기가 중요하다면, 해볼만한 작업이라고 생각합니다.
오히려 C++ 컴파일러가 더 최적화된 코드를 생성할수(!)도 있습니다.
오히려 C++ 컴파일러가 더 최적화된 코드를 생성할수(!)도 있습니다.
>>>그러게요.. >>>C로도 vtbl 같은 것도 직접 구현해서 dy
>>>그러게요..
>>>C로도 vtbl 같은 것도 직접 구현해서 dynamic binding을 쓸 수도 있긴 있겠지요. (C
>>>로 C++ 컴파일러는 왜 못 만들겠습니까? ^^)
그래두 method, data통합보다는 힘들잖아요 ^^;;;
>>>근데 이미 잘 쓰이고 있는 C++라는 언어를 두고 굳이 C로 그런 걸 구현하는 방법을 논>>>의하는 것은 그저 호기심 충족의 차원은 될 수 있을지 몰라도 실제적인 효용성은 별
>>>로 없다고 봅니다. 그냥 C++ 쓰는 게 낫겠지요.
그건 그런거 같네요 ^^;;;
함수 포인터가 dynamic binding 할려고 쓰는거 아닙니까?
함수 포인터가 dynamic binding 할려고 쓰는거 아닙니까?
음.. 상속하고도 관계 있는 듯한데요,제가 말하려고 했던 것은,
음.. 상속하고도 관계 있는 듯한데요,
제가 말하려고 했던 것은, C++같은 경우에, virtual로 선언하면,
runtime에 bottom up search를 해서 알맞은 method가 선택되잖아요?..
그걸 말하려고 한 건데...
근데 상속 자체가 안되니까 좀 말이 안되긴 하는군요.. ^^;;;
예.. 상속이 안되니까 그렇긴 한데요.함수포인터도 원래 런타임시에
예.. 상속이 안되니까 그렇긴 한데요.
함수포인터도 원래 런타임시에
함수가 결정되서 실행 할 수 있는거 아닙니까?
어차피 하나의 함수이름으로 실제의 여러 함수 내용을
런타임시에 동적으로 불러다 쓸수 있다는건
c 나 c++ 이나 같은거 아닌지요..
c++ virtual 도 내부적으로는 함수 포인터 개념을 쓰지 않을까요?
>>>예.. 상속이 안되니까 그렇긴 한데요. >>>함수포인터도 원
>>>예.. 상속이 안되니까 그렇긴 한데요.
>>>함수포인터도 원래 런타임시에
>>>함수가 결정되서 실행 할 수 있는거 아닙니까?
예
>>>어차피 하나의 함수이름으로 실제의 여러 함수 내용을
>>>런타임시에 동적으로 불러다 쓸수 있다는건
>>>c 나 c++ 이나 같은거 아닌지요..
>>>c++ virtual 도 내부적으로는 함수 포인터 개념을 쓰지 않을까요?
아마 그렇겠지요.
어쨋건 제가 말하고자 한 것은 C++에서의 polymorphism(함수 overriding이나, class의 subclass로 instance를 만들 수 있는 것등...)
같은게 C에서 흉내내기 힘들 것 같다는 말이었습니다..
둘다 틀린말을 하고있는 것 같지는 않군요.. ;-)
CPP의 객체는 결국 구조체를 확장한것이기 때문에 C만 사용할 수 있
CPP의 객체는 결국 구조체를 확장한
것이기 때문에 C만 사용할 수 있는 경우는
다음과 같은 방법을 이용합니다.
class ClassName
{
void Func();
}
typedef ClassName struct {
}
void Func(ClassName* cls)
{
}
세상에나 함수포인터를.. 이거 쓴 코드 첨 보네요..정말로 이거
세상에나 함수포인터를.. 이거 쓴 코드 첨 보네요..
정말로 이거 실전에 쓰세요..??
예전에 생각해본적은 있지만,, 아무리 생각해도 증말 절정의 엽기라서..
cls 라는 변수이름 대신 차라리 this 가 훨 낳지 않을까요??
몰르면 가만히나 있지...
몰르면 가만히나 있지...
c로도 c++객체지향적 요소를 거의 다 구현할 수 있습니다그리고
c로도 c++객체지향적 요소를 거의 다 구현할 수 있습니다
그리고 함수포인터는
실제로 많이 쓰는 기법입니다
계속 C를 C++처럼 쓰는 방법에 대해 말씀들 나누시길래 잠깐 저도 남깁
계속 C를 C++처럼 쓰는 방법에 대해 말씀들 나누시길래 잠깐 저도 남깁니다.
초기 C++ 컴파일러가 나왔을때 그놈은 native 컴파일러가 아닌 거의 preprocessor
수준이었습니다. 뭐였나믄.. C++을 컴파일하믄 C소스가 나오고 이를 컴파일해
바이너리를 생성했었드랬습니다. 문제는 Binding time이나 runtime에서
어떻게 동작할 지가 아니라, Complile time이전에 어떠한 제약을 두고
그 제약에 따르게 할 것인가.. 로 직결될 것 같습니다.
OOP가 Class를 통해 업무나 사물을 객체로 모델링하고, 그 모델의 한계내에서
접근하는 방식을 취하는데.. 문법과 Compiler의 제약조건들은..
이렇게 모델링에 도움을 주거나 모델이 오류없이 이용될 수 있도록 하는
방편일 겁니다. C를 C++처럼 쓴다는 것은 결국 컴파일러가 수행해야 할
많은 작업들을 자신의 머리로 하고, 거기서 발생할 수 있는 오류의
가능성을 작업자가 감수해야 함을 뜻하지 않을까 싶네요.
C++을 컴파일해서 Obj로 만들 때 의 과정을 보면 어떨까요? ^^
C++을 컴파일해서 Obj로 만들 때 의 과정을 보면 어떨까요? ^^
명쾌한 답은 거기에 있을 것 같네요.
함수포인터가 어느 거죠.저한테는 안 보이는데요.그리고 C++
함수포인터가 어느 거죠.
저한테는 안 보이는데요.
그리고 C++ 에서도 this를 멤버함수의 인자로 해서 넘깁니다.
보이지 않을 뿐이죠...
뭐 꼭 stack을 쓰지 않고 레지스터를 쓰는 경우도 있지만 여하튼.
void ClassName_Func(ClassName *cls);
이런 식으로 쓰면 이쁘지 않나요... :)
그러면 GTK+ 코드는 궁극의 엽기겠군요.
그러면 GTK+ 코드는 궁극의 엽기겠군요.
함수 포인터는 많이 사용되는 편 아닌가요?음.c 로 c++
함수 포인터는 많이 사용되는 편 아닌가요?
음.
c 로 c++ 처럼 작성한 코드의 대표적 예로..
gtk/gnome 을 들 수 있겠죠..
위와 같은 방식은 아니지만..
살짝 본일이 있었는데 ..
괜찮다구 생각했었던듯..
실제로 gtk+ 로도 잘되구요....
(잘 몰라서 말꼬리를 늘인 흔적들 ㅡ.ㅡ)
제가 알기로는 최초의 C++ 컴파일러는 단순히 C의 프리프로세서 형태였던
제가 알기로는 최초의 C++ 컴파일러는 단순히 C의 프리프로세서 형태였던 것으로 알고있는데요....
한마디 더 붙이자면.. 다들 C++, Java 하면 OOP라고 생각하지만 그런말이 있더군요.. C++, Java가 OOP를 해주는 것이 아니라 C++나 Java는 단지 OOP를 쉽게 해주는 언어일 뿐이라구요. C가지고도 얼마든지 객체 지향적인 프로그래밍을 할 수 있을꺼라는 생각이 드는데요.. 예를 들면 X-Kernel 소스의 경우에는 C로 되어있지만 소스를 보면서 객체 지향적이라는 생각이 들더군요..
저 역시 동일한 일로 고민한 적이 있습니다.저 같은 경우에는 UM
저 역시 동일한 일로 고민한 적이 있습니다.
저 같은 경우에는 UML로 하고요... (주위에선 엽기라고 하지만 나름대로 만족하고 있습니다)
Class 는 file로, method 는 function 으로 대체 시키고 있습니다.
기타 상속등은 include로 처리하고요...
대충 그려보니, 꽤 유용하던데 한번 해 보시기를 권해 드립니다.
남들은 c 가 고전적인 언어라고 하는데, 자꾸 쓰다보면 객체지향이고 나발(?)이고 전부 구현해 낼 수 있습니다.
님께서 하시는 것과 방법상의 차이는 있지만, C 언어의 용도와 유용성에
님께서 하시는 것과 방법상의 차이는 있지만, C 언어의 용도와 유용성에 대해서는 동의합니다.
펑션중심, 라이브러리중심으로 모듈화를 하시면 되겠습니다. OOP
펑션중심, 라이브러리중심으로 모듈화를 하시면
되겠습니다. OOP 언어코딩과 어떻게 보면 크게
다를 것이 없습니다. 단지 관점이라던가 중심이
바뀌었을뿐이죠.
댓글 달기