19,800원
다른 수강생들이 자주 물어보는 질문이 궁금하신가요?
- 미해결객체 지향 프로그래밍 입문
강의 수준 질문드려요
완강하긴 했는데 이해를 50% 정도 밖에 못한 것 같아요.자바의 정석 한번 다 보고, 스프링이랑 스프링부트 이제 막 공부하는 시점인데, 제가 부족한 건지 아직은 이 강의가 어렵네요.어느정도 공부한 시점에서 수강하는게 좋을까요?
- 미해결객체 지향 프로그래밍 입문
6분 26초에 말하는 객체의 안에 있는 프로시저란 객체의 메서드를 말하는건가요?
6분 26초에 말하는 객체의 안에 있는 프로시저란 객체의 메서드를 말하는건가요?
- 해결됨객체 지향 프로그래밍 입문
객체의 기능보다 속성을 먼저 추출하는 것에 대해 의견을 여쭤보고 싶습니다.
안녕하세요. 강사님.객체는 제공하는 기능으로 정의된다!=> 회원 객체 (암호 변경하기 기능) 대부분의 프로그램은 정보 표현을 위한 데이터(구조체, 객체)는 존재하기 마련일텐데요. 제가 생각하기에 회원이라는 객체는 초기 설계 과정에서 제공해야 될 기능에 중점을 두기보다는 "일반적으로 표현해야 될 정보에 기반(표현 정보 = 관리해야 될 데이터)해서 추출되지 않나?" 가 저의 생각입니다.여기서 궁금한점은 표현해야 될(관리해야 될 데이터) 정보를 구조화한 것에 관련된 데이터를 조작하는 기능을 추가해도 외부에 제공하는 기능으로 정의된다는 말씀은 만족한다고 볼 수 있을까요 ?제가 강의를 듣고 정리하자면 객체를 설계할 때는 외부에 제공할 기능에 중점을 두고 설계를 해야되는 것이라고 받아들였는데 기능보다 데이터가 중심이 되는 구조체성 자료에 기능을할당하는 것도 올바른 방향인건지 여쭤보고 싶습니다. 감사합니다!
- 해결됨객체 지향 프로그래밍 입문
의존 대상 객체를 직접 생성했을 때 문제에 대해 질문드립니다.
안녕하세요. 강사님.영상 4:40초쯤 생성 클래스가 바뀌면 의존하는 코드도 바뀐다고 하셨는데 이게 어떤 경우인지 예시가 잘 안 그려집니다.추상화 파트를 다시 봐도 이해가 잘 안 가서 그러는데 예시나 추상화 강의에서 나왔던 부분 좀 언급하셨던 곳 좀 알려주실 수 있을까요?
- 미해결객체 지향 프로그래밍 입문
책임 분리 및 할당 관련 질문이 있습니다.
안녕하세요. 강사님.객체지향에서 시스템단에서 책임져야할 기능을무엇을 기준으로 해서 세부적으로 하위 기능들을 추출하고 각 객체(역할)에 할당한다고 하셨는데 궁금한점이분해된 책임을 적절한 객체에 할당하기 전에객체의 엔티티 구조에 대한 정의가 어느정도 나와 있어야 되는거지요 ?방법1 > 책임 분해 → 책임을 적절한 역할에 할당 → 책임 할당받은 객체 구현(해당 과정에서 필요한 정보들 셋팅)방법2 > 책임 분해후 할당하기전에 이미 엔티티 구조에 대해서 어느정도 구조가 완성되어 있어 책임을 수행하는데 필요한 정보가 많은 객체에 책임 할당.객체의 엔티티 구조가 어느 시점에 정의가 되는게 맞는걸까요 ?
- 미해결객체 지향 프로그래밍 입문
객체지향 프로그래밍과 캡슐화의 차이가 궁금합니다.
선생님 안녕하세요, 강의를 보다가 궁금한 점이 있어 질문드립니다.절차 지향과 객체 지향의 차이를 설명해주실 때, 절차 지향은 프로시저에서 데이터가 공유되는 반면,객체 지향은 프로시저와 데이터를 함께 묶는 것이라고 이해했습니다. 그런데 캡슐화 역시 프로시저와 데이터를 함께 묶는 것으로 보이는데, 그러면 객체 지향 프로그래밍이랑 결국 캡슐화이다(?) 정도로 이해하면 좋을 지 궁금합니다.
- 해결됨객체 지향 프로그래밍 입문
추상화 예제의 추상화하지 않은 구현 부분에서 질문있습니다.
2분 55초의 CloudFileManager 클래스의 DropboxClient dc = ...; List<DbFile> dbFiles = db.getFiles(); 해당 부분의 db.getFiles() 이 dc.getFiles()인가요? 혹시 오타인지 궁금해서 여쭤봅니다!
- 해결됨객체 지향 프로그래밍 입문
캡슐화 하는 이유에 대해서
클래스 메서드를 사용하는거랑 클래스선언없이 함수를 만들어서 사용하는거랑 어떤 차이가 있나요?요구사항이 변경됬을 때 클래스선언없이 함수만 사용해도 여러곳의 코드를 일일이 변경하지 않아도 되는 장점이 있다고 생각됩니다.이게 캡슐화랑 어떤 관련이 있나요?
- 미해결객체 지향 프로그래밍 입문
캡슐화 연습 2번
강의 수강 중 캡슐화 2번을 리팩토링 하는 과정에서 궁금한 점이 있습니다! getFrequentRenterPoints()를 Movie에서 구현을 해주셨는데 daysRented를 파라미터로 넘겨서 RenterPoints를 계산하는 과정에서 대여기간 조건을 2일, 3일 이런식으로 변경점이 생겼을 때 Movie 클래스에서 변경하면 된다고 하셨는데 대여기간 조건 변경이 생겼는데 Movie에서 로직을 변경하는게 맞는가? 라는 의문점이 들었습니다. 저의 생각은 renterpoint를 계산할 때 Rental 클래스에서 기존의 방식처럼 구현하는게 나중에 변경점이 생겼을 때 더 쉽게 찾을 수 있지 않을까 생각합니다.혹시 제가 놓치고 있는 부분이 있을까요??
- 미해결객체 지향 프로그래밍 입문
추상화 예제에서 추상 클래스를 사용하지 않고 인터페이스를 사용하신 이유가 궁금합니다.
좋은 강의 감사합니다. 추상화 예제 강의를 보다가 추상 클래스를 사용하지 않고 인터페이스를 사용하셔서 질문드립니다. 예제에서는 cloudFile, cloudFileSystem을 인터페이스로 만드셨는데, dropBox, nCloud, sCloud가 같은 동작을 한다면 추상 클래스로 만들어서 상속받는것도 괜찮지 않을까란 생각이 들었습니다. 추상 클래스와 인터페이스를 어떠한 경우에 사용해야 하는지 강사님만의 기준이 있으신걸까요?
- 미해결객체 지향 프로그래밍 입문
캡슐화 예제 4 질문입니다.
- 학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요! - 먼저 유사한 질문이 있었는지 검색해보세요. - 서로 예의를 지키며 존중하는 문화를 만들어가요. - 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. ========== 안녕하세요. 최범균 강사님. 예제 4번 관련해서 질문이 있습니다. 예시로 들어주신 캡슐화 코드를 사용한다면 verifyEmail() 메서드를 호출하기 전에 isEmailVeritifed() 메서드로 한 번 확인하는 로직은 불필요 것인지 궁금합니다. if (!,mem.isEmailVeritied() {mem.verifyEmail(); } 감사합니다. :)
- 미해결객체 지향 프로그래밍 입문
범균님 안녕하세요 강의 수강중 궁금한점이 있어 질문 남겨 봅니다.
강의를 수강 중 '모듈'이라는 단어가 나와서 정의를 좀 찾아봤는데요.정의가 와닿지 않아서 어떻게 해석해야 할지 궁금합니다.일반적인 애플리케이션에서 하나의 클래스도 모듈이 될 수 있는 건가요?모듈을 정하는 기준이 궁금합니다. https://ko.wikipedia.org/wiki/%EB%AA%A8%EB%93%88_(%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D)#cite_note-1
- 미해결객체 지향 프로그래밍 입문
캡슐화 질문
안녕하세요 강의 정말 흥미롭게 잘 보고 있습니다. 다름이 아니라 정답을 보기전 강의를 멈추고 제가 생각했던 캡슐화랑 비교해가면서 보고 있는데요 질문1 연습문제 1번에서 저는 두번째 if문만이 아닌 if 문 3개를 한꺼번에 메서드로 만들어서 캡슐화를 진행하려 했었는데 이렇게 해도 괜찮은가요?? 질문2 연습문제 3번 같은 경우에도 elapasedTime 메서드에 start() 와 stop() 메서들 넣어 아예 하나의 메서드로 캡슐화 시켜버리고 호출시 elapasedTime메서드만 호출하도록 캡슐화 하는 방법을 생각 했었는데 이방식도 괜찮은건가요??
- 미해결객체 지향 프로그래밍 입문
DIP 관련해서 궁금한게 있습니다.
DIP 예제의 답을 보기 전 제가 생각한 상위 정책은 상세 정보를 추출하는 기능, API를 호출하는 기능, 상품을 구하는 기능으로 나눠서 생각했습니다. 정보 추출과 상품을 구하는 기능은 유사했지만 Daara API를 통해 상품을 구하는 기능은 하위 모듈로 분류되어 있었서 질문을 하게 되었습니다. API 호출 또한 추후 다른 API를 통해 상품을 구한다고 가정하면 API 호출 또한 상위 수준의 정책으로 볼 수 있지 않나 라고 생각을 했습니다. 하지만 범균님 분류를 보니까 API 호출이라는 구현 방식(하위 관점)에서 생각한 접근 방법이라고도 생각을 하게 되네요... API 호출을 상위 모듈로 분류한 것은 하위 관점(구현 관점)에서 추상화를 진행한 것인지 궁금합니다.
- 해결됨객체 지향 프로그래밍 입문
기능 분리 기준에 대한 질문이 있습니다.
계산 분리 및 연동 분리에서 보면 분리 단위를 별도 객체를 통해 분리를 예시로 들어주시고 있으십니다.별도 객체로 분리하는 게 1장에서 배운 측면에서 유리하겠지만 어떠한 특정한 경우에는 별도 객체가 아닌 별도 메서드로 분리하는 게 유리하지 않을까란 생각이 듭니다.문제는 그게 어떠한 특정한 경우인지 모르겠습니다. 강사님께서는 무조건적으로 분리 시 객체 단위로 분리하시나요 아니면 특정한 경우에 대해서는 메서드를 통해 분리를 하시는 지 궁금합니다.감사합니다.이상입니다.
- 해결됨객체 지향 프로그래밍 입문
서로 다른 구현 추상화에 대해서 질문이 있습니다.
서로 다른 구현 추상화에 대한 예시로 SCP로 파일 업로드, HTTP로 데이터 전송, DB 테이블에 삽입이 존재하는데요이것이 모두 푸시 발송 요청을 위한 기능이므로 추상화를 한다고 하는데 조금 더 구체적인 추상화가 어떤 추상화인지 알 수 있을까요?추상화는 공통화로 볼 수 있을 것 같은데요SCP로 파일 업로드와 HTTP로 데이터 전송, DB 테이블에 삽입은 인풋 데이터를 아웃풋에게 전달하는 부분밖에 추상화 포인트가 떠오르지 않습니다. 이 경우는 추상화라고 표현하는 게 옳을지 잘 모르겠습니다.감사합니다.이상입니다.
- 해결됨객체 지향 프로그래밍 입문
의존 주입 예제 관련 질문입니다.
의존 주입 관련 질문입니다. (동영상 5:13초)코드 예제에서 오른쪽 하단에 schSvc.setCalculator(cal); 코드가 존재하고 있습니다.Q1. 왜 SchSvc.setCalculcator(cal);은 굳이 생성자를 통해서 의존 주입을 하지 않나요? Q2. 혹시 SchSvc.setCalculator(cal);의 이유가 생성된 이후에도 여러 번 setCalculator을 통해 ScheduleService의 cal 필드 변경이 필요해서 일까요? Q3. Q2의 질문의 답변이 만약 맞는 경우(생성된 이후 여러 번 setCalculator를 통해 계산법 변경이 필요하다) setter는 지양해야 된다는 한 블로그를 보게 되었습니다.(출처: https://velog.io/@sezeom/Getter-Setter-%EC%A7%80%EC%96%91%ED%95%98%EA%B8%B0) 혹시 setCalculator 방식 말고 ScheduleService 객체가 이미 생성된 이후에도 private Calculator cal을 변경 시킬 수 있는 다른 방법이 있을까요? 지금 떠오르는 것은 setter로 cal을 갱신하는 것이 아닌 계산과 관련된 메소드를 만들고, 메소드의 파라미터를 계산 기능과 관련된 추상화를 통한 객체 다형성을 통해 해결하는 방법 밖에 생각이 나지 않습니다. 그 외 다른 방법이 존재할까요? Q4. Q3과 연관된 질문인데 만일 조립을 통해 생성된 객체가 생성된 이후 특정 상황에 따라 조립을 통해 생성된 객체가 다른 객체로 변경이 필요한 경우에는 setter(조립된 객체를 저장한 특정 필드를 변경) 말고 다른 방법을 통해 조립을 통해 이미 생성된 객체를 변경이 가능할까요? 기존 강의의 여러 내용을 훑어보았지만 마땅한 해결책이 떠오르지 않습니다. 이 경우는 조립을 쓰지 않는 게 답일까요? 아니면 다른 좋은 해결 방법이 존재하는 지 궁금합니다. Q5. 어떤 특정한 경우에는 새로운 객체를 생성하지 않고 기존 생성한 객체를 계속 사용하면서 setter 등을 통해서 기능을 바꾸어야 할 때가 있을 것 같습니다.(억지 예시로 생성에 비용이 큰 객체는 매번 재생산 시 비용의 부담이 있을수도 있어서 static을 통해 한번만 생성하고 여러 상황에 맞게 setter 등을 통해 기능을 바꾼다. 기능 기능과 책임의 분리 측면에서는 맞지 않지만 아주 억지적인 가정을 한다면요...) 이 때 setter 방식보다는 메소드의 파라미터를 통해서 기능을 메소드 내에서만 사용하도록 하는 방식이 객체지향에 알맞지 않을까 싶습니다. 근데 위 내용의 반론으로 만약 동일한 기능을 여러 메소드에게 공통적으로 전달하여 사용하고 setter 변경 주기가 짧은 편이 아니라면 어쩌면 setter 한번 쓰고 메소드의 파라미터로 기능을 전달하지 않고 메소드를 사용하는 게 옳을수도 있겠다는 생각이 듭니다. 하지만 또 생각해보면 setter를 통해 객체를 전달한 것 자체가 setter로 전달된 객체는 private일지라도 캡슐화 된 객체 내에서 다른 메소드가 접근이 가능해서 오류가 발생하지 않을까 싶기도 합니다.혹시 강사님이 생각하시는 좋은 해결법이 존재할까요?이상입니다.감사합니다.[기타 잡소리]강의 잘 보고 있습니다. 벌써 마지막에 강의에 가까워지네요.객체지향이 이렇게 신기한 건지 몰랐습니다. 강사님 책 중 개발자가 반드시 정복해야 할 객체 지향과 디자인 패턴 책을 오늘 서점에서 구매했습니다.해당 강의 다 보고 책 다시 정독하고 싶네요.좋은 하루 되세요
- 해결됨객체 지향 프로그래밍 입문
상속 재활용 단점 중 상위 클래스 변경 어려움에 대해서 질문이 있습니다.
상속 재사용 단점 중 상위 클래스 변경이 어렵다는 부분에서 "상위 클래스가 어떤식으로 동작 하는지 어느정도 파악 후 하위 클래스가 기능 재사용이 가능하다"고 구두로 설명해주셨는데요, 여기에 추가적으로 상위 클래스는 하위 클래스에 대해 캡슐화가 약해지는 문제가 발생한다고 추가로 설명을 해주셨습니다.여기서 상위 클래스는 하위 클래스에 대해 캡슐화가 약해진다는 게 구체적으로 어떤 의미 일까요?제가 파악하기에는 예시로 계층 관계의 깊이가 깊어질 수록(루트와 단말 사이에 많이 상속 객체가 존재할 경우) 최상위 클래스와 최하위 클래스의 기능이 많이 다른 경우 최상위 클래스는 최하위 클래스를 캡슐화 하기 어렵다고 보는게 옳을까요?감사합니다.이상입니다.
- 해결됨객체 지향 프로그래밍 입문
캡슐화 연습4 질문 있습니다.
개선 후 예제에서 mem.verifyEmail() 시도 후 수정사항을 DB에 반영하고 있습니다. 궁금한 점은 DB 반영 완료 후 verifyEmail() 내부의 this.verificationEmailStatus = 2를 하는 게 맞지 않는가 궁금합니다.이유는 DB 반영 전에 this.verificationEmailStatus = 2를 진행 후 DB 반영을 한다면, 만약 DB 반영 실패 시 다시 verificationEmailStatus를 2가 아닌 값으로 바꿔주는 작업이 필요로 해 보입니다. 만약 DB 반영 실패를 검출하지 못한 경우 this.verificationEmailStatus를 이전 값으로 바꿔주지 못하고 DB 혹은 서버가 죽은 경우, 다음 verifyEmail을 시도 시 this.verificationEmailStatus는 2가 된 상태인데 DB에는 반영이 되지 않은 상태가 존재할 수 있다고 생각이 듭니다.혹시 이 경우 좋은 해답이 존재하는 지 궁금합니다.이상입니다.감사합니다.
- 미해결객체 지향 프로그래밍 입문
의존하는 대상이 많을 때 질문 드립니다.
1분 58초 부근을 보게 되면 X 는 A, B, C, D, E, F에 의존하고 있습니다. 이 때 만약 A를 수정하면 의존하고 있는 X에도 변경의 여파가 미치게 됩니다. 저는 보통 이럴 때 X와 A의 의존관계를 없애게 되더라도 A는 결국 남은 B, C, D, E, F 중에 하나와 의존관계를 갖게 되더라구요. 그래서 만약 X와 A의 의존관계를 끊고 B가 A에 의존하게 되었다고 가정하겠습니다. 이 때 A를 수정하면 X에는 변경의 여파가 미치지 않지만 새롭게 의존하게된 B에게 변경의 여파가 미치는데요. 이렇게 된다면 A와 X의 의존관계를 끊고 A와 B의 의존관계를 설정한 것이 좋은 선택인가요??