Facade 패턴

디자인 패턴은 문법이 아니며 방법입니다. 하나의 패턴으로 프로그램 전체를 완성시킬 수는 없습니다. 그리고 완벽하게 룰을 지키는 것보다 유연하게 상황에 따라 여러 패턴들을 조금씩 응용해서 사용할 뿐입니다. 개인적으로 너무 복잡한 패턴을 굳이 사용할 필요가 없습니다. 오히려 유지보수 혹은 한 프로젝트에 다수의 개발자가 협업할 경우 코드를 이해하지 못하는 경우가 발생할 수 있습니다. 게다가 인수인계시에는 왜 이런 패턴을 구현했는지 잘 설명해줘야 합니다. 그렇지 않으며 좋은 구조로 잘 설계된 프로그램이 타인에 의해 조금씩 붕괴되는 광경을 목격할 수도 있습니다. 보통 알고리즘을 구현할 때 복잡한 절차가 있게 마련입니다. 대부분 메모리 할당이라든가, callback 할당, 이벤트 처리 등으로 복잡해지기 쉽습니다. ..

• format_list_bulleted ▶ C Application/디자인 패턴
• · 2024. 2. 12.
• textsms

Message 기반 프로세스

RTOS를 사용하지 않는 베어메탈 Firmware에서는 각각의 기능 프로세스의 처리 시간을 적당히 잘 분배 해야 합니다. 처리 시간이 긴 프로세스는 여러개로 쪼개야 하며, 특히 인터럽트 발생시 인터럽트 인터럽트 루틴에 긴 처리시간을 요구하는(지연이 발생하는)코드를 넣으면 절대 안됩니다. 더욱이 애매한 처리 시간을 요구하는 코드를 넣는 경우는 더욱 위험합니다. 왜냐하면 불규칙적으로 에러를 발생되며 디버깅을 위해 많은 시간이 소요될 수도 있습니다. 인터럽트 서비스 루틴에서는 입력된 데이터를 적당한 자료구조에 적재해놓던가, 특정 플래그를 set하는 수준 혹은 메시지 큐에 쌓는 수준의 처리가 가장 좋습니다. 만약 전체 시스템이 1초단위로 어떠한 처리가 끝나야 한다면, 각각의 프로세스들이 최대 처리되는 시간의 합..

• format_list_bulleted ▶ C Application/디자인 패턴
• · 2023. 12. 10.
• textsms

App state machine 개요

펌웨어를 처음 개발할 때 수많은 절차와 처리들을 어떻게 일목요연하고 보기 쉽게 코딩해야하는지 막막하게 느껴집니다. 이럴 때 보통 디자인 패턴이라는 프로그래밍의 오래된 습관 혹은 관습을 이용하여 해결할 수 있습니다. ​ state machine은 이런 디자인 패턴중에 하나로 아주 사용하기 쉽고 유용하며 소프트웨어 개발자라면 꼭 알아야 할 디자인 패턴 기법입니다. ​ single core 안에서 동작 중인 application은 반드시 하나의 상태(state)안에 있습니다. 각각의 이벤트나 어떠한 처리는 state 안에서 이루어 지며 여러개의 state 끼리 서로 전환하며 프로그램이 동작하게 됩니다. ​ 아래 다이어그램에서 우리가 만들 app state machine 을 좀 더 구체적으로 알아보겠습니다. a..

• format_list_bulleted ▶ C Application/App 만들기
• · 2023. 11. 14.
• textsms