yongsoocho

journalctl 을 함께 보면 좋은데, 현재 에러 메세지로는 conf 파일 문법이 틀린거 같습니다.&nbsp;<ol><li><code>vi /redis/redis-stable/redis.conf</code> 로 vi 에디터 켜기</li><li><code>:2328</code> 입력으로 2328번째 줄로 이동하기 (이동 키는 <code>G</code> 입니다.)</li><li>주석 미처리, 띄어쓰기, parameter 타입 오류 등... 해결</li><li><code>:wq</code> 로 저장 후 다시 시도</li></ol>&nbsp;해당 방법으로도 안된다면, journalctl 이나 status 상세 옵션으로 로그 부탁드립니다 🙂

systemctl restart redis-study 문제

해당 문법은 데코레이터가 실험적기능으로 타입스크립트에 도입되었을 때 문법이라 에러들을 우회하기 위해서 설명한 문법이였습니다. 특히 지금 데코레이터는 4버전 초반대랑 조금 다를 것 입니다. 그래서, 강의의 타입스크립트 버전이 너무 옛날 버전이라 강의를 재촬영을 계획하고 있습니다.&nbsp;그리고 지금은 Builder를 사용하지 않고 모두 함수를 이용하는 편입니다. 예전에는 디버깅하려고 Builder를 쓰기도 했는데 지금은 보통 쓰지 않습니다. 본 영상의 목적은 Decorator에 이해를 돕기 위한 것 이였으나, 혼란을 드려 죄송합니다.

BuilderInit 사용 이유

맞습니다. 그래서 인터페이스를 주로 사용합니다 :)

enum 질문이 있습니다.

안녕하세요. 데코레이터는 사실 Node.js 진영에서 앵귤러나 Nest.js를 제외하고는 잘 쓰이지 않습니다. JS가 코딩 입문언어로 그 외 언어들은 알지 못합니다. 그래서 데코레이터가 더 이해가 잘 안되는데요. -> 원래 처음에는 난해한 개념입니다. 대한민국에서 개발자를 하신다면 언젠가는 꼭 자바(Java)를 배우실 날이 올 것 인데요. 그때 자세히 배우고 지금은 이런 것이구나 ~ 하고 개념만 잡고 그때 공부하셔도됩니다. 참고할만한 블로그나 기초 개념들을 알려주시면 감사하겠습니다. -> 자바 데코레이터 구글에 검색하시면 됩니다. 파이썬도 데코레이터 많이 쓰긴 하는데, 자바가 공부하기에는 좋겠네요. 아래는 타입스크립트 관련 데코레이터 정리해놓은 링크 두겠습니당. <a target="_blank" rel="noopener noreferrer nofollow" href="https://typescript-kr.github.io/pages/decorators.html">https://typescript-kr.github.io/pages/decorators.html</a> <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.typescriptlang.org/docs/handbook/decorators.html">https://www.typescriptlang.org/docs/handbook/decorators.html</a> 아래의 오류가 떠서 뭐가 문제인지 잘 모르겠습니다. -> 에러 메세지는 인자가 잘못 되었을 때 나타나는 메세지입니다.

색션 2, 데코레이터 개념이 아예 이해가 안됩니다.

본래 UserInfo 상단에 지정된 인자들의 타입을 한번 더 점검해준다는 뜻인가요?? 답) 점검하는 목적은 아닙니다. 객체의 메소드와 변수가 안에 들어있다는 것을 보장하기위해, 자동완성 목적으로 타입을 달아줍니다. 클래스 타입을 지정해주는 이유는 사실 지금은 느끼기 어렵습니다. 나중에 규모가 큰 프로젝트를 하시다보면 다른 파일에 분명 타입을 달았는데도 타입이 인식되지 않는 경우가 종종 있습니다. 또한, 여러명에서 동시에 개발을 하다보면 무슨 타입인지 들어가봐야 아는 경우도 자주 생기므로 달아주는 것이 좋습니다.

변수의 타입에 클래스를 지정해준 것과 지정 안한 것 과의 차이가 어떻게 되는지 궁금해서 질문을 남깁니다.

compilerOption 에서 strict 나 noImplicitAny옵션을 true로 하였는지 한번 확인 부탁드립니다.

섹션4 예제0 질문입니다.

질문주셔서 감사합니다 :)object는 객체일 뿐 어떠한 프로퍼티, 메서드도 보장하지 않습니다.<pre class="hljs"><code>interface ITest {
 hello: any
}

test<ITest extends object></code></pre>예를 들어서 위와같이 타입을 적으면 hi가 없다는 것을 알 수 있습니다. 이는 협업에서도 마찬가지입니다.작성자 분께서만 알고 있을 뿐, 같이 일하는 동료가 test<T extends object>를 보면서 test.hi( )를 유추할 수는 없습니다.제가 클래스로 대입해서 설명을 하자면,<pre class="hljs"><code>class ObjectTest {}

class Test extends ObjectTest {}

const test = new Test();
test.hi();</code></pre>예를 들자면 위와 같은 상황인데 hi()가 있는 인터페이스를 상속해야만 100% 보장된다는 것을 아셔야합니다.타입스크립트 엔진 자체가 100% 보장되는 것을 추구한다고 생각하면 편합니다. 뒤에서 배우시겠지만 타입가드를 통해서 100% 타입을 보장해서 써야만 오류가 안납니다.

제네릭 extends관련질문 있습니다.

저는 다음과 같은 익스텐션을 사용합니다.<ul><li>Bracket Lens</li><li>Bracket Pair Colorization Toggler</li><li>ESLint</li><li>indent-rainbow</li><li>Material Icon Theme</li><li>Prettier - Code formatter</li><li>REST Client</li><li>Tabnine AI Autocomplete</li></ul>

안녕하세요 정말 좋은 강의 감사합니다

버전이 변경될 때마다 불필요한 리소스를 잡아먹는 작업인 것 같아 옳지는 않은 방향인 것 같아 질문드려요! -> 저도 예전에 똑같은 생각을 갖고 있었습니다. 왜 클래스를 그냥 구현하면 되지 귀찮게 인터페이스를 두지..? 라는 생각이였습니다.일단 이 개념은 컴퓨터공학과(혹은 소프트웨어공학과)에서 배우는 "소프트웨어공학", "객체지향 설계" 등의 과목 중 일부입니다.A 클래스가 B 클래스를 호출한다고 할 때 인터페이스를 통하여 호출하면 B 클래스가 어떻게 생겼는지 안이 어떻게 구현되어있는지 모르지만 정상적으로 호출하고 실행이 됩니다. 여기서 객체지향 설계의 은닉화, 캡슐화 등 여러 개념을 같이 배우게 되는데요. 사실 매우 거대한 개념이고 하나의 강의로 풀어낼 개념은 아닙니다. (파고들면 정말 밑도 끝도 없습니다.)&nbsp;정리를 하자면<ol><li>인터페이스는 설계도 같은 것 입니다. 웬만해서 크게 변하지 않습니다. 하지만 인터페이스를 꼭 만들어라!!! 는 아닙니다. 100층 짜리 고층 건물을 설계할 때는 설계도가 필요하지만, 작은 모래성을 쌓는데 설계도가 필요하지는 않습니다.</li><li>A클래스가 -> B클래스(타켓 클래스)를 호출하는데 인터페이스를 통해서 호출하면 A 클래스는 B 클래스가 어떤 구현을 갖고있는지 모르지만 파라미터와 리턴타입 정보만 갖고 호출하고 사용할 수 있습니다. B클래스가 은닉성을 갖으면서 A-B 커플링(객체지향설계에서는 클래스간 의존도를 낮춰야합니다..!)이 낮아지게 됩니다.</li></ol>&nbsp;지금은 굉장히 비효율적으로 느끼실 수 있는데, 애초에 대규모 애플리케이션에서 많이 쓰는 형태입니다.

하나의 인터페이스와 여러 버전의 클래스에 관한 질문

examples2 type을 object 선언후 as 로 IExam 을 감싸는 이유가 따로 있을까요-> 같은 파일 안에서는 타입추론이 맞지만, 외부 모듈이나 파일이 많아지면 추론이 잘 안될 때도 있습니다. 또한, 웹(document) 에 접근 할 때는 타입이 추론이 잘 되지않아 종종 단언을 합니다&nbsp;저렇게 했을경우 value 프로퍼티 접근을할경우 빨간줄이 뜨는데 이럴땐 해결하는 방법이 따로 있을까요??-> 위 방법은 "타입 단언"이고 뒤에 "타입 캐스팅"이 나옵니다!

yongsoocho

投稿