객체 지향 설계 기술을 어떻게 평가 하시겠습니까? [닫은]

어떤 종류의 통찰력이나 질문으로 인해 사람의 OOAD 기술을 결정할 수 있습니다.

간단한 문제에 대한 반쯤 OO 디자인을 보여주고, 그것이하는 일, 그에 대한 좋은 점과 나쁜 점, 융통성, 개선 가능한 점, 방법에 대해 토론 할 수 있습니다.

토론을 진행해야하는 경우 코드의 일부 측면에 대해 사람이 어떻게 생각하는지 물어보십시오.

중요한 것은 토론이 중요하다는 것을 기억하는 것입니다. 괜찮은 개발자라면 이전에는 생각조차 못했던 코드에 대해 무언가를 지적 할 수 있어야합니다.

개인과 개방형 설계 문제에 대해 논의하십시오. 시스템 모델을 구축하는 방법, 질문의 종류, 새로운 정보에 따라 디자인이 어떻게 변하는 지 확인하십시오.

Steve Yegge가 자신의 블로그 게시물 중 하나에서 언급 한 좋은 예는 XML에 대한 객체 모델을 생각해 보도록 요청하는 것입니다.

가장 인기있는 모든 디자인 패턴 에 대해 잘 알고 있으면 응시자가 실제로 디자인 문제에 대한 솔루션을 검색했음을 증명할 수 있습니다.

토론하고 적용시기를 아는 것은 그가 이해한다는 좋은 증거입니다.

과거 경험에서 사용 사례를 물어 보면 도움이 될 수 있습니다.

어휘 퀴즈를주지 마십시오 . "상속 정의 (Define Inheritance)"또는 "OO 디자인의 이름 3 기능 (name 3 features)"은 개인의 기술에 대해 아무 것도 알려주지 않고, 마지막으로 교과서를 읽은 이후 얼마나 오래 지속되는지에 대한 질문입니다. 저는 매일이 기술을 사용하는 몇몇 훌륭한 프로그래머들을 만났지만 공식적인 정의를 요구하면 질식 할 것입니다.

회의실 또는 기타 가상 실체에 대한 비즈니스 객체, 클래스 및 인터페이스 / 방법을 적어달라고 요청합니다.

가능하면 샘플 코드를 요청하십시오.

그렇지 않으면 예제로 사용할 절차 코드 (또는 잘못 설계된 OO 코드)를 찾은 다음 재 설계, 일반화 및 개선 방법을 물어보십시오. 재 설계가 의미를 가질 수 있도록 프로그램에 추가 컨텍스트가 있는지 확인하십시오.

궁극적으로 테스트하고있는 디자인은 주관적입니다. 따라서 단일 솔루션이 아닌 여러 가지 가능한 솔루션을 제공 할 수 있도록 평가를 개방해야합니다. 그런 다음 인터페이스를 강제로 변경하는 요구 사항의 가능한 변경 사항에 대해 생각해보십시오. 어떻게 처리합니까?

Head First Design Patterns 책을 읽으십시오. 이 책의 모든 예제는 객체 지향 문제로 시작하여 디자인 패턴으로 끝나지 않습니다. 또한 특정 OOP의 개념이 제한된 결과를 달성하는 이유와 특정이 다른 것보다 나은 이유를 알려줍니다.

디자인 패턴 책이더라도이 책은 OOP의 문제로 가득 차 있습니다 :-)

간단한 시작 : OOP 란 무엇인가?

추상화, 다형성, 상속 및 캡슐화와 같은 OOP의 기본 전제에 대해 질문함으로써 시작할 수 있습니다. 몸을 따뜻하게하는 좋은 음식.

그들에게 문제를 줘

다음으로, 패턴과 관련된 문제를 제시하십시오. 패턴의 이름을 지정하거나 사용할 필요는 없지만 해당 영역에서 경험이있는 경우 접근 방식으로 일부 결과를 얻을 수 있습니다.

동적 텍스트 입력 유효성 검사일 수 있습니다. 입력 문자를 ISO8601 형식의 유효한 날짜, 시간 또는 날짜 및 시간인지 확인하기 위해 문자별로 입력 문자의 유효성을 검사하려고합니다. 키를 누를 때마다 입력 문자열의 복사본이 제공되며 부울을 반환하여 텍스트가 최소한 하나 이상의 형식으로 유지되는지 여부를 나타냅니다. OO 설계 원칙을 사용하여 설계에 대해 이야기하고 스케치하도록 요청하십시오.

대화를 마칠 때까지

1. 컨트롤러 (변경 이벤트를 발생시키고 응답을 평가하는 것)
2. 관찰자 (검증자가 변경 이벤트에 응답)
3. 전략 (각 유효성 검사기는 입력이 유효한지 확인하는 다른 방법을 나타냄),

그들이 OOD를 이해한다면 아주 좋은 아이디어를 얻게 될 것입니다.

다시 같은 문제를 주지만 이번에는 다른 디자인을 요청하십시오.

이제 관찰자 패턴을 사용하지 않고 시스템을 재 설계하도록 요청하십시오 (설명한 경우). 책임 체인 접근 방식 또는 명령 패턴을 사용하도록 선택할 수 있습니다. 당신은 정말로 어떤 것을 신경 쓰지 않습니까, 당신은 그들이 관련된 원칙을 합리적으로 이해하고 있음을 알고 있습니다.

패턴 기반 접근 방식을 사용하지 않더라도 문제를 관련 기능으로 분류하려는 방식을 듣는 것만 으로도 결과를 얻을 수 있습니다.

나는 사람들에게 잘 알려진 실제 시나리오를 선택하는 경향이있다. 관련된 배우; 그들 사이에 어떤 상호 작용이 있는지; 일반적인 특징들이 추상화 될 수있는 곳; 고려해야 할 특성.

그렇습니다. UML을 앉아서 그릴 것을 요청할 수 있습니다. 그렇습니다. OOP 구현에 대한 질문을 검색하여 "지상 뛰기를"할 수 있는지 확인할 수 있습니다.

그러나 고용주가 팀 내에서 실제로 필요로하는 것은 관련된 개념을 이해하고 모든 개념에 적용 할 수있는 마음입니다. 개념이 임베드되면 세부 사항을 빠르게 학습 할 수 있습니다.

† 친숙하고 코드 도움이없는 관계 : 아침에 가족의 화장실 사용; 저녁 요리; 출근 버스 노선; 자동차 조립.

다소 잘 작동하고 실제로 몇 초 밖에 걸리지 않는 것 : 객체 모델을 설계하도록 요청하십시오. 그것은 중요하지 않습니다. 절대적으로 사소 할 수 있습니다. 실제로, 테스트를 불필요하게 끌지 않는 것은 사소한 것일 것입니다.

그들이 처음 쓰는 것이 대상이라면, OO에 대한 이해에서 이미 동료의 99 %보다 앞서 있습니다. 그들이 쓰는 첫 번째 수업이라면, 학생들에게 나가서 다음 후보자를 보내라고 요청하고 왜 COP가 아닌 OOP라고 불리는 지 생각해보십시오.