본문 바로가기

Develop

[C#] 비동기 프로그래밍 비동기 프로그래밍 비동기 프로그래밍은 중앙처리장치(CPU)를 효율적으로 사용하기 위한 기술이다. 중앙처리장치는 매 초마다 정말 많은 작업을 요청받고 처리한다. 데이터를 읽거나 쓰거나, 네트워크 통신을 주거나 받거나, 화면 픽셀을 계산하거나 모두 중앙처리장치의 허가와 지도가 필요하다. 이렇게 바쁜 중앙처리장치에게 현재 입출력 작업이 완료되길 기다리게 하는건 정말 비효율적이다. 그래서 개발자는 중앙처리장치가 비효율적으로 낭비되지 않도록 비동기 프로그래밍 기술을 사용하여, 중앙처리장치가 입출력을 기다리는 대신 다른 업무를 처리하도록 하고 입출력이 완료되었다는 메세지를 받은 뒤에 기존 작업을 다시 시작하도록 프로그래밍한다. 등장 배경 기본적으로 프로그램은 코드 순서에 따라 순차적으로 실행된다. 그래서 코드 중간..
[SOLID] Dependency Inversion 원칙 목차 Single Responsibility 원칙 Open/Closed 원칙 Liskov Substitution 원칙 Interface Segregation 원칙 Dependency Inversion 원칙 Dependency Inversion (의존관계 역전) 원칙 상위 모듈과 하위 모듈은 추상적인 약속을 기반으로 소통해야 한다. 자세한 구현은 추상적인 개념에 기반해야 한다. Dependency Inversion (의존관계 역전) 원칙은 객체지향 설계의 핵심인 모듈 간 의존관계 해소를 강조하는 원칙이다. 모듈 간의 의존 관계가 낮아져야 모듈 세부사항을 변경하더라도, 전체 코드에 미치는 영향을 최소화하고 적은 양의 코드로 최대의 효과를 누릴 수 있다. 구체적으로 이야기하자면, 상위 모듈이 하위 모듈의 함수..
[SOLID] Interface Segregation 원칙 목차 Single Responsibility 원칙 Open/Closed 원칙 Liskov Substitution 원칙 Interface Segregation 원칙 Dependency Inversion 원칙 Interface Segregation (인터페이스 분리) 원칙 인터페이스를 구현하는 클래스는 필요한 함수만 구현할 수 있도록 설계하자. 원칙에 따라 인터페이스는 최소한의 크기로 설계해야 한다. 그래야 클래스가 필요한 부분만 구현할 수 있다. 예제 청바지 가게에서 아래와 같이 상품을 구현한다고 하자. public interface IProduct { int ID { get; set; } double Weight { get; set; } int Stock { get; set; } int Inseam { ..
[SOLID] Liskov Substitution 원칙 목차 Single Responsibility 원칙 Open/Closed 원칙 Liskov Substitution 원칙 Interface Segregation 원칙 Dependency Inversion 원칙 Liskov Substitution (리스코프 치환) 원칙 자식 클래스를 부모 클래스처럼 사용할 수 있도록 설계해야 한다. Liskov Substitution 법칙는 상속과 관련된 규칙이다. 자식 클래스가 만약 부모 클래스에서 기대하는 기능과 달리 동작한다면, 같은 부모 클래스를 상속하더라도 자식 클래스마다 기대하는 결과가 달라지는 어처구니없는 사태가 발생한다. 따라서 자식 클래스는 사용자가 부모 클래스로부터 기대하는 정도에서 너무 멀어지지 않도록 구현해야 한다. 예제 아래 예제 코드는 Circle-e..
[SOLID] Open/Closed 원칙 목차 Single Responsibility 원칙 Open/Closed 원칙 Liskov Substitution 원칙 Interface Segregation 원칙 Dependency Inversion 원칙 Open/Closed (개방-폐쇄) 원칙 기능의 확장 가능성은 열려 있는 반면, 기능의 변경 가능성은 닫혀있어야 한다. 반드시 필요한 경우가 아니라면 기존 클래스의 기능을 변경하는 작업은 피해야 한다. 기존 코드가 어디에 어떤 방식으로 사용되고 있는지 모두 파악하기 어렵기 때문에 기존 코드의 변경이 어떠한 결과를 초래할지 정확히 예상할 수 없다. 그러므로 기능의 변경이나 확장이 요구될 때는 기존 클래스를 상속하는 방법으로 기존 코드는 유지하면서 요구사항을 만족시킬 수 있도록 설계해야 한다. 그래야 요구..
[SOLID] Single Responsibility 원칙 목차 Single Responsibility 원칙 Open/Closed 원칙 Liskov Substitution 원칙 Interface Segregation 원칙 Dependency Inversion 원칙 Single Responsibility (단일 책임) 원칙 모든 클래스는 하나의 책임만을 부여받으며, 단 하나의 이유만을 바탕으로 변경되어야 한다. 클래스가 제공하는 모든 기능은 클래스가 부여받은 책임에 기반하여 작성되어야 한다. 만약 모든 기능을 하나의 클래스가 책임진다면, 접근하지 말아야 할 변수에 엉뚱한 함수가 접근하여 내부를 부패시킬 수 있다. 반대로 여러 클래스가 하나의 기능을 책임진다면, 기능에 변경이 있을 때마다 각각의 클래스를 변경에 맞추어 완벽하게 작업해야 하는 부담이 발생한다. 특히 ..
[SOLID] SOLID 원칙이란 SOLID 원칙이란 로버트 마틴의 다섯가지 기본 원칙에서 알파벳을 합쳐 만들어진 객체 지향 설계론이다. 원칙의 목적은 시간이 지나도 유지 보수와 확장이 쉬운 시스템을 설계하기 위함이다. Single Responsibility 원칙 Open/Closed 원칙 Liskov Substitution 원칙 Interface Segregation 원칙 Dependency Inversion 원칙 Exception Not Found 블로그를 참고하여 시리즈를 손쉽게 작성할 수 있었다.
[C#] 코드 문서화 코드 문서화는 필요할 수도 있고, 아닐 수도 있다. 코드가 어떻게 작동하는지 그리고 코드를 어떻게 활용하는지 파악해야 할 때, 코드 문서는 유용하다. 코드 문서가 있으면 동료 개발자의 업무를 방해하지 않으면서, 코드를 이해할 수 있다. 즉 코드 문서는 코드와 작성자 간의 결합도를 줄여준다. 하지만 코드 문서는 생산성을 저하시키는 행정 업무로 변질되기 쉽상이다. 코드가 변경되면 문서를 같이 업데이트해야 한다. 즉 코드와 문서가 서로 결합된다. 코드 문서화는 생산성 증가를 보장하지 않는다. 따라서 문서화를 진행하기 전에 과연 코드를 문서화하는 작업이 생산성을 증가시킬 수 있는지 충분한 검토가 필요하다. 왜냐하면 코드 문서로 업무를 올바르고 정확하게 하는 것도 중요하지만, 업무를 기한 안에 적은 노력으로 완료..

티스토리툴바