본문 바로가기

전체 글

 (84)
객체지향의 사실과 오해 - 다시 읽어보기 "객체지향이란 실세계를 직접이고 직관적으로 모델링할 수 있는 패러다임" 실제로 존재하는 개념이든, 추상적으로 존재하는 개념이든 코드로 옮겼을 때, 해당 개념을 '객체'로 옮길 수 있고, 그렇다면 해당 개념과 코드상에 존재하는 객체가 일치하면 일치할수록 개발자는 코드를 이해하기 쉬워지고, 개발의 속도가 엄청 빨라질 수 있다. 옛날에 읽었을 때는 이해가 잘 안가고, 그냥 그렇구나 했지만, 이제는 이해가 간다. 그러나 이게 다시 유연하고 실용적인 관점에서는 객체지향 분석, 설계를 설명하기에 적합하지 않다구?? 7장에서는 이거라고 했잖아요.. 그렇지만 클린 아키텍쳐책에도 비슷하게 나와있는 걸로 봐서는 실용적인 측면에서는 이렇게 설명하는게 적합하지 않다고 하는 듯하다. 객체지향의 목표는 실세계를 모방하는 것이 아..
리액트 공부중 - 2~3주차 후기 회사업무차에서 실시간 차트 개발을 담당하게 되어 리액트를 공부하고 있다. 리액트는 벨로퍼트의 블로그에서 쉽게 쫓아갈 수 있었으며, 역시 직접 따라 코딩해봐야 이해가 빠르게 된다. 리액트가 어렵다면 어렵다고 할 수 있는 이유는, 사실 기존의 html보다 훨씬 편하지만, 편하게 하기위하여 리액트 특유의 문법이 존재한다. 리액트에는 state가 존재한다. state를 직접적으로 변경할 수 없으며, 아예 새로운 객체를 만들어서 바꿔치기는 할 수 있다. useEffect와 같은 특수문법이 존재한다. 렌더링이 완료되면 최초 실행되며, [deps]에 있는 값이 비어있으면, 더 이상 실행되지 않는다. 만약 [deps]에 특정값이 있다면, 해당값을 구독하여 값이 변경될때마다 호출된다. context라는 것이 존재한다. ..
클린 아키텍처 7장~11장 SOLID SRP 하나의 모듈은 하나의, 오직 하나의 액터에 대해서만 책임져야 한다. 서로 다른 액터를 책임진다면 병합이 발생할 가능성은 확실히 더 높다. 해결책: 메서드를 각기 다른 클래스로 이동. 그러나 각기 다른 클래스로 관리하기가 어렵다면? 퍼사드로 관리하자 단일 책임 원칙은 메서드와 클래스 수준의 원칙이다. 상위의 두 수준에서도 다른 형태로 다시 등장. 컴포넌트 수준에서는 공통 폐쇄 원칙, 아키텍처 수준에서는 아키텍처 경계의 생성을 책임지는 변경의 축이 된다. OCP 확장에는 열려있어야하고, 변경에는 닫혀 있어야함 → 다형성을 사용하여, 기능을 변경시, 다른 모듈로 갈아끼우라는 뜻. 아키텍처 컴포넌트 수준에서 OCP를 고려할 때, 훨씬 중요한 의미를 가진다. 처리 과정을 클래스 단위로 분할하고, 컴포넌트 ..

티스토리툴바