티스토리

Simple & Clear

검색하기

블로그 홈

Simple & Clear

simplear.tistory.com/m

Go언어에 대한 전반적인 것을 다룹니다.

구독자: 6

방명록 방문하기

주요 글 목록

파이프라인 패턴 들어가기에 앞서... 해당 패턴은 동시성 프로그래밍에 기반한 디자인 패턴이기 때문에 동시성 프로그래밍을 지원하는 언어가 아닌 경우 이 글이 별로 도움이 되지 않을 것이다. 또한 해당 글은 Go언어만의 문법을 쓰기 때문에 동시성 프로그래밍을 지원한다 하더라도 다른 언어에서는 구현 방법이 다를 수 있다. 즉, 해당 글은 Go언어 사용자 중 동시성 프로그래밍에 대한 기본 개념(고루틴, 채널)에 대한 기본 지식이 있는 독자를 대상으로 한다. 파이프라인 패턴은 디자인 패턴 중 실행 패턴이다. 디자인 패턴 목록에 나열한 글에 없다고 의아해할 수 있다. 맞다. 해당 패턴은 전통적인 디자인 패턴('GoF의 디자인 패턴'에 포함된 패턴)은 아니다. 이는 해당 패턴이 일반화되지 않았다거나 바람직하지 않다는 것을 뜻하는 것.. 공감수 1 댓글수 0 2021. 9. 23.
DIP 원칙의 한계 들어가기에 앞서... 지난 글에서는 DIP 원칙이란 무엇인지, 또 DIP의 장점과 적용하는 방법에 대해서 설명했다. 해당 원칙대로 작성한 코드는 순환 참조 문제에 빠질 일이 없고 객체지향적으로써 바람직한 코드가 될 것이다. DIP 원칙 그 자체로써는 단점이 거의 없다.(아주 없지는 않다. 코드의 길이가 살짝 늘어난다. 물론 이러한 단점은 장점에 비하면 매우 사소하다.) 이 글의 제목이 '단점'이 아닌 '한계'라는 사실에 주목하라. 그렇다면 이 글에서 설명하고자 하는 한계는 무엇인가? 바로 DIP 원칙을 적용할 수 없는 경우이다. 상위 폴더에 인터페이스를 두기만 하면 DIP 원칙이 적용된다고 생각할 수 있고 또 어느 정도는 사실이지만, 이것이 불가능한 경우가 존재한다. 이 글에서는 DIP 원칙을 적용할 수.. 공감수 0 댓글수 0 2021. 6. 24.
Go 언어에서의 DIP 들어가기에 앞서... 해당 글은 독자가 Go 언어(혹은 C언어 계열)의 문법에 대한 기본 지식이 있다고 가정하고 설명하겠다. 객체지향적 설계에 관해 집중적으로 공부한 적이 있다면 'SOLID 원칙'이라는 용어는 들어봤을 것이다. SOLID 원칙은 로버트 마틴이 그의 저서 '클린 소프트웨어'에서 제창한 용어로 다섯 가지 객체지향 소프트웨어 디자인 원칙의 약자를 모은 것이다. 이번 글에서는 이 다섯 가지 원칙 중 마지막 원칙인 DIP(의존성 역전 원칙)에 대해 설명할 것이다. 해당 원칙은 이해하기가 어려운 대신, 이해만 한다면 (특히 Go언어에서)바로 적용하기 쉬운 유익한 원칙이다. 정의 상위 모듈은 하위 모듈에 의존해서는 안 된다. 상위 모듈과 하위 모듈 모두 추상화에 의존해야 한다. 추상화는 세부 사항에.. 공감수 2 댓글수 0 2021. 4. 22.
[Go with TDD] 테이블 주도 테스트 개요 이전에 '깔끔하게 go test의 테스트케이스를 짜는 법'이라는 글을 쓴 적이 있다. 오늘 설명할 테이블 주도 테스트는 해당 글의 내용을 정형화한 기법이다. 테이블 주도 테스트 테이블 주도 테스트(table-driven test)는 메소드에 대한 여러 개의 테스트 케이스를 하나의 테이블로 구성하는 테스트 기법이다. 테스트할 메소드 하나에는 여러 개의 테스트 케이스가 존재한다. 일반적으로 테스트를 작성하면 하나의 테스트 함수는 하나의 테스트 케이스를 실행한다. 이렇게 작성하는 것이 잘못된 것은 아니지만 호출할 메소드가 같기 때문에 코드의 중복이 생긴다. 테이블 주도 테스트는 하나의 테스트 함수에 테스트할 메소드의 테스트 케이스를 묶어 테이블로 만든 후 해당 테이블을 순회하며 테스트를 진행하는 구조이다.. 공감수 0 댓글수 0 2021. 4. 8.
[Design Go] 가교 패턴 들어가기에 앞서... 필자는 해당 패턴이 디자인 패턴에서 제일 중요하다고-적어도 Go언어에서는-생각한다. 만약 독자가 해당 시리즈를 정주행하고 있다면 한 번 쉬고 오기를 바란다. 아, 해당 패턴이 어렵다는 뜻은 아니니 걱정하지 않아도 된다. 해당 패턴에서는 도형을 그리는 예제를 이용할 것이다. 도형을 그리는 방식으로 Raster 방식과 Vector 방식을 들 수 있는데, Raster 방식은 점을 일일히 찍어서 표현하는 방식이고 Vector 방식은 그래프를 이용해 수학적 방식으로 표현하는 방식이다. 예제에서 구현할 도형은 원과 직사각형 두가지로 한정한다. 모든 경우의 수를 고려한다면 각 경우의 수를 담당하는 클래스를 만드는 방법을 떠올릴 수 있다. RasterRactangle, VectorRactangle.. 공감수 0 댓글수 2 2021. 1. 28.
[Design Go] 적응자 패턴 들어가기에 앞서... 이번 글 부터는 구조 패턴에 관해 설명할 것이다. 구조 패턴은 연관된 객체를 합성하는 방법에 관한 디자인 패턴이다. 생성패턴과는 다르게 구조패턴은 서로 연관성이 없는 경우가 많기 때문에 각 글마다 예시가 다를 것이다. 해당 예시는 외부에서 위치를 표현하는 Point 구조체와 글을 표현하는 TextView 인터페이스 및 클래스를 들여왔다고 가정한다. 그리고 우리는 도형을 표현하는 Shape 인터페이스를 작성했다. 우리가 원하는 작업은 위의 TextView를 Shape 처럼 이용하는 것이다. 즉, TextView 클래스를 Shape 인터페이스에 맞추는 것이다. //point.go package main import "fmt" type Point struct { X, Y int } fun.. 공감수 0 댓글수 0 2021. 1. 21.
[Design Go] 단일체 패턴(동시성 프로그래밍을 중심으로) 들어가기에 앞서... 드디어 마지막 생성 패턴이다. 예제는 지난 글과 동일하다. 이번 글은 동시성 프로그래밍의 내용을 포함하고 있기 때문에 해당 내용에 관해 알고 있으면 좋다. 패턴 단일체 패턴은 객체(Singleton)를 단 하나만 생성하도록 하는 패턴이다. 프로그램 내에서 Singleton 객체는 오직 하나이며 프로그램 실행 중 처음 접근할 때만 초기화가 이루어진다. 프로그램 어느 곳에서든지 Singleton 객체에 접근 가능하며 어느 곳에서 접근해도 같은 객체를 가리킨다. 즉, 전역 변수와 같은 기능을 한다. 장점 전역 변수의 상위 호환이다. 전역변수를 쓸 때에는 여러가지 부작용을 감수해야 한다. 단일체 패턴은 이런 전역변수의 부작용을 최소화한다. 이에 관해서는 아래의 장점들에 자세히 풀어놓았다. .. 공감수 1 댓글수 0 2021. 1. 14.
[Design Go] 원형 패턴 들어가기에 앞서... 예제는 전과 마찬가지로 지난 글의 예제를 이용했다. 원형 패턴 원형 패턴은 미리 만들어진 객체(prototype)의 복사를 통해 새로운 객체를 생성하는 패턴이다. prototype 객체는 보통 팩토리 객체(factory) 내부의 인스턴스로 존재하며, factory 객체는 요청한 prototype 객체의 복사본을 반환한다. prototype 객체를 복사할 때에는 깊은 복사를 이용해야 한다. 장점 런타임 단계에서 새로운 객체의 생성자를 만들 수 있다. 이는 컴파일 단계에서 생성할 객체의 클래스를 정해야 하는 다른 생성 패턴에 비해 유연성이 보장된다. 클래스의 개수가 줄어든다. 다른 생성 패턴은 인터페이스를 만족하는 다양한 클래스들을 생성해야 하지만 원형 패턴은 하나의 클래스에 내부의 p.. 공감수 0 댓글수 0 2021. 1. 7.
[Design Go] 팩토리 메소드 패턴 들어가기에 앞서... 이번 패턴의 설명 역시 지난 패턴의 예제를 이용했다. 팩토리 메소드 패턴 팩토리 메소드 패턴은 함수에게 다른 객체(product)의 생성을 맡기는 디자인 패턴이다. creator 함수는 product 객체의 일종의 생성자 역할을 한다고 볼 수 있다. 장점 객체의 생성과 구현을 분리해낸다. 이전의 생성 패턴들과 같다. 코드의 가독성이 높아진다. 빌더 패턴과 비슷한 이유이다. 빌더 패턴이 거대한 객체의 생성을 목적으로 한다면 팩토리 메소드는 작은 객체의 생성을 목적으로 한다. 다른 패턴과 쉽게 연동된다. 기존의 클래스에 해당 메소드만 추가하면 되는 만큼 다른 패턴에 적용하기 쉽다. 추상 팩토리 패턴은 여러 팩토리 메소드를 묶어 객체화한 패턴이다. 단점 코드가 난잡해질 수 있다. 팩토리 .. 공감수 0 댓글수 0 2020. 12. 24.
[Design Go] 추상 팩토리 패턴 들어가기에 앞서... 이번 패턴의 예제는 지난 글을 참조하자. 추상 팩토리 패턴 추상 팩토리 패턴은 한 객체(factory)에게 서로 연관되어 있는 각 객체(product)들의 생성을 맡기는 패턴이다. 우선 factory 객체가 상속할 인터페이스(Factory)에는 하나 이상의 product 객체들을 생성하는 메소드가 정의되어 있어야 한다. factory 객체는 Factory 인터페이스를 상속하여 해당 인터페이스의 메소드를 구현한다. 사용자는 factory 객체를 생성하고 해당 객체의 메소드를 통해 product 객체들을 생성한다. 장점 연관된 객체들(객체군)끼리 생성할 때 문제의 여지가 없어진다. 추상 팩토리 패턴을 사용하는 가장 큰 이유이다. 예를 들어 여러 사이즈의 나사와 볼트가 있을 때 추상 팩토.. 공감수 1 댓글수 2 2020. 12. 17.
[Design Go] 빌더 패턴 들어가기에 앞서... 지난 글에서 언급했듯 해당 시리즈의 이번 글부터는 각 디자인 패턴에 대해 설명하면서 Go언어로 만들어보도록 하겠다. 책 'GoF의 디자인 패턴'에서는 생성 패턴들을 설명할 때 아래의 미로를 만드는 예제를 사용했다. 이 시리즈도 해당 예제를 이용할 예정이다. package main import "fmt" type Direction int const ( East Direction = iota West South North ) type MapSite interface { Enter() } type Room interface { MapSite GetSide(d Direction) MapSite SetSide(d Direction, s MapSite) GetNo() int } type roo.. 공감수 1 댓글수 0 2020. 12. 10.
[Design Go] 좋은 코드와 디자인 패턴 좋은 코드? 농부는 좋은 작물을 얻기 위해 노력한다. 책 저자는 좋은 책을 쓰기 위해 노력한다. 프로그래머는 좋은 코드를 짜기 위해 노력한다. 그렇다면 '좋은 코드'라는 것은 대체 무엇일까? 좋은 코드란? 다양한 의견이 있을 수 있다. 일단 성능이 좋을 수록 좋은 코드이다. 블로그 이름처럼 단순하고 깔끔한 코드는 대부분 좋은 코드이다. 이런 맥락으로 가독성이 높은 코드는 좋은 코드이다. 하지만, 혼자서든 여러 사람과 함께든 작업을 이어가다 보면, 유지보수하기 쉬운 코드는 좋은 코드의 필요 조건이라는 것을 알게 된다. 왜 유지보수하기 쉬운 코드인가? 프로젝트를 진행하다 보면 당연히 처음에는 새로운 기능을 추가하는 데에 시간을 많이 쓰게된다. 그렇게 그 프로젝트의 기본적인 요구 기능들이 완성되고 배포까지 완.. 공감수 1 댓글수 0 2020. 12. 3.
[Go with TDD] TDD란? 소프트웨어 공학, 개발 방법론 등에 관해 조금이라도 알고 있다면 TDD(Test-driven development, 테스트 주도 개발)라는 용어를 들어봤을 것이다. 잘 아는 사람도 많겠지만 모르는 사람들을 위해서 우선 용어부터 정리해보자. TDD 단어 그대로 테스트를 통해서 개발하는 방식이다. 즉, 테스트 케이스를 작성한 후 그 테스트를 통과하기 위한 코드를 짜는 방식을 TDD라고 부른다. 회귀 테스트 회귀 테스트는 이전에 동작 했던 기능 및 함수가 다른 부분의 코드 수정 후에도 일관성 있게 동작하는 것을 검증하는 테스트이다. 회귀 테스트는 일단 작성되면 새로운 기능을 테스트할 때마다 실행된다. 회귀 테스트의 핵심은 기존의 코드가 새로운 기능에 의해 문제를 일으키지 않는다는 것을 검증하고 보증하는 것에 .. 공감수 0 댓글수 0 2020. 9. 11.

문의안내

티스토리
로그인
고객센터

티스토리는 카카오에서 사랑을 담아 만듭니다.