#02파일분할과 헤더파일

View Comments

#02파일분할과 헤더파일


*컴파일러는 파일단위로 컴파일!! 정의되어있지 않다면 에러를 뱉을수밖에없다.


*외부선언 및 정의사실을 컴파일러에게 알려줘야한다. 그 예약 키워드는 ? ==>  extern

fun.c
     extrn int num;//==>extern때문에 컴파일러가 num이 외부에있음을 인지한다. 에러를 발생시키지않는다.

"외부에  정의되어 있을테야. 그러니 일단 넘어가자"

**static

*함수내에서만 접근 가능. 전역변수와 마찬가지로 한번 메모리에저장되면 종료시까지 소멸되지 않음.

*함수 밖에 static 변수가 선언되면 외부소스파일에서 접근이 불가능한다. 현재 파일에서만 접근가능하다
     -static int num =0;//외부에서접근 불가 extern안먹힘

*함수자체에 static선언이 가능하다. 변수와 기능이동일하다.
     -static void MinCnt(void) =>외부에서 호출 불가.


**헤더파일을 include하는 두가지 방식

*#include<헤더>
=>표준헤더파일을 포함시킬때, 파일이 저장된 디렉토리에서 헤더파일을 찾음.

*#include "헤더"
=>프로그래머가 정의한 헤더파일을 포함할때, 문장을 포함하는 소스파일이 저장된 디렉토리에서 파일을 찾게됨

*절대경로로 접근도가능하긴함.

*구조체의 정의는 파일단위로만 그선언이 유효. 
=>즉 다른고셍서 필요하면 다른소스에서 꼭 선언해줘야됨.==>구조체 헤더파일 하나만들고 그거 include해서 사용

*헤더를 중복삽입할수있어,다음과같이 체크를 해주는 매크로를 적용한다.

#ifndef __CALCUS_H__


#define __CALCUS_H__


(definition for Calcus)


#endif


'C Language > C basis' 카테고리의 다른 글

#04 typedef  (0) 2016.04.27
#03 구조체와 포인터  (0) 2016.04.27
#01 선행처리기  (0) 2016.04.27

0 Comments (+add yours?)

Leave a Reply

Tracbacks (+view to the desc.)

#01 선행처리기

View Comments



#01선행처리기 


**선행처리기 => 컴파일 이전의 처리

*소스 -> 선행처리기-> 선행처리된 소스 -> 컴파일러 -> 오브젝트파일 -> 링커 -> 실행파일

*선행처리기에서 단순히 #define 된 정보를 치환한다.

*모든 매크로에는 괄호가 들어가는게 선행처리될때 오해의 소지가 없다.

*두줄에 정의되려면 \ 를 사용하면 되고 아래와같이사용하면됨
     #define SQUARE(Z) \

     ((Z)*(Z))


**특징
*매크로함수는 일반함수에비해 속도가 빠름. 
     -함수의경우 별도의메모리공간 & 호출된함수의 이동 및 반환, 그러나 매크로는 바로치환.

*자료형에따라 별도로 함수를 정의하지 않아도도미.
     -전달되는 인자의 자료형에 구분받지 않아 의존적이지 않음.

*정의하기 까다롭다.
*디버깅하기 쉽지않다. => 선행처리후 컴파일러에의해 에러가감지됨으로, 값이 잘못됬지만 찾기위해선 논리적 혹 계산적 이슈를 체크해야함.

**뭐가 적당하냐
-작은크기의함수
-호출빈도수가 높은함수


**매크로 if문
#if num==0 //num 이 0 이면

#elif num==1

#endif


#ifdef Add //Add가정의되어있다면.

#endif


#ifndef Add //Add가 정의되어 있지 않다면

#endif



*문자열 치환
#define JOBS(a,b) #a "job is" #b

=>JOBS(pk,coder)


*##

#define setNum(a,b) a##00##b

=>setNum(10,20) ==> 100020




'C Language > C basis' 카테고리의 다른 글

#04 typedef  (0) 2016.04.27
#03 구조체와 포인터  (0) 2016.04.27
#02파일분할과 헤더파일  (0) 2016.04.27

0 Comments (+add yours?)

Leave a Reply

Tracbacks (+view to the desc.)

[설계] 소프트웨어의 설계 기본.

View Comments

객체지향 소프트웨어 설계에 많은 원칙들이 존재.

그중 5가지 원칙을 중심으로 살펴본다.


그전에 알아야할 것들


*의존관계

소프트웨어는 변한다는 것을 받아들이고 변경을위한 디자인이 항상 필요해왔다.

변화에 유동적으로 반응하기위해 새로운 의존관계를 생성 또는 변경시킨다. 

이러한 개념을 쉽게 적용 및 이해하기위해 응집도와 결합도라는 개념이 있다.


응집도란?

'하나의 클래스가 하나의 기능을 온전히 담당하는 정도'를 의미한다.

응집도가 높아질수록.

프로그램은 단순 명쾌해진다. 


결합도란?

'클래스간의 서로 다른 책임이 얽혀있는 정도'를 뜻한다. 결합도가 높을수록 코드가 연결고리가 많아짐으로 코드 보기가 복잡하고 힘들다. 


즉 높은 응집도와 낮은 결합도를 갖는 원칙은  고전적 개념이자 원리인것이다.



그럼 상세히 프로그램 5대원칙을 정리해 보자.


1. 단일 책임의 원칙(SRP;Signle Responsibility Principle)

- *객체는 하나의 책임만 맡아야한다*

- 하나의 클래스는 하나의 책임만 맡아야한다. 하나이상을 맡게되면 결합도가 커지며 변경이 어려워진다. 

- 예로 DB클래스가 있다면 이 클래스는 오직 데이터베이스와 관련하여 수행되어야된다.



2. 의존관계 역전의 원칙(DIP;Dependency Inversion Principle)

     - *클라이언트는 구체 클래스가 아닌 인터페이스나 추상클래스에 의존해야한다*

- 왜? 인터페이스에 의존하도록하면 향후 변화개셩겼을때 객체 생성부분만 수정하여  유동적으로 처리할 수 있기때문이다.



3. 인터페이스 분리의 원칙(ISP;Interface Segragation Principle)

- *클라이언트에 특화된 여러개의 인터페이스가 하나의 범용 인터페이스보다 낫다*

- 쉽게말해 인터페이스를 어느정도 세분화 할 필요가 있다는 것이다. 이말은 결합도를 낮추는 방법이 될 수 있다. 언제나 그렇듯이 적당한 세분화가 필요하다



4. 리스코프대체(치환) 원칙(LSP; Liskov Subtitution Principle)

- *기반 클래스는 파생 클래스로 대체 가능해야한다"

- 자식이 부모의 메서드 중 일부를 거부하면 안된다는 의미다. 부모클래스의 메서드를 받지않으면 그것 자체가 올바른 상속구조가 아니라는 것을 말해준다.



5. 개발폐쇄의 원칙 (OCP;Open Closed Principle)

- * 모듈은 확장에는 열려있어야하고 변경에는 닫혀있어야한다*

- 은닉화 라는 표현이 존재한는 이유중 하나일 거란 생각이든다. 변경하려는 것을 getter/setter로 보호하는것은 변경에는 닫혀있는 경우 일 것이다. 허나 수평적인 확장은 용이해야 한다는 의미다.예를 들면 인터페이스 추가로 손쉽게 새로운 기능을 추가하는 것이다.



간단하게만 설계원칙을 알아보았다. 정리하는 수준.

0 Comments (+add yours?)

Leave a Reply

Tracbacks (+view to the desc.)

Newer Entries Older Entries