프로젝트 질문 문의

안녕하세요.말씀해주신 내용관련하여 답변드립니다. "혼자 진행한 프로젝트이지만, 그 과정에서 요구사항 분석 → 모듈 설계 → 구현 → 테스트까지 전 사이클을 직접 담당했습니다. 특히 [구체적인 설계 결정 예: 모듈 간 의존성을 낮추기 위해 인터페이스를 분리했다, 예외 상황을 고려해 에러 처리 구조를 설계했다 등]를 고민하며 진행했고, 혼자이기 때문에 오히려 각 결정의 근거를 명확히 문서화하는 습관을 갖게 됐습니다." 위와 같은 답변의 형태가 좋을 것으로 보입니다. 두괄식이며, 기술적인 부분을 많이 넣은 답변이 좋은 답변으로 보일 것 같네요. 최근 방산 SW 개발도 애자일 방법론을 사용하기 위해 연구과제까지 진행되고는 있지만, 아직은 워터풀인 경우가 다반사이기에, 이를 고려해서 위와 같은 답변으로 제공드립니다. 감사합니다 :)

다형성 개념 문의

좋은 질문 감사합니다!다형성을 오버로딩/오버라이딩으로만 설명하는 것은 사실 다형성의 일부만 다루는 것입니다. Cardelli & Wegner(1985)의 분류에 따르면 오버로딩은 임시적 다형성(ad-hoc polymorphism) 의 한 종류이고, 객체지향 설계에서 핵심으로 다루는 것은 서브타입 다형성(inclusion polymorphism) 입니다."부모 타입으로 다룬다 = 구현이 아닌 추상에 의존한다"는 GoF의 "Program to an interface, not an implementation" 원칙과 동일한 맥락으로, 코드가 구체적인 클래스가 아니라 인터페이스/추상 타입에만 의존하면 새로운 구현체를 추가해도 기존 코드를 수정할 필요가 없습니다. 이것이 OCP가 다형성/추상화와 연결되는 이유입니다. 1. 다형성(Polymorphism)의 정의 — 오버로딩/오버라이딩을 넘어서Luca Cardelli & Peter Wegner (1985), "On Understanding Types, Data Abstraction, and Polymorphism" (ACM Computing Surveys, Vol. 17, No. 4)이 논문은 다형성을 다음 네 가지로 분류한 가장 권위 있는 원전입니다:Parametric polymorphism (제네릭)Inclusion polymorphism (서브타입 다형성 — 상속/인터페이스)Overloading (임시 다형성)Coercion (강제 변환)오버로딩은 다형성의 한 종류일 뿐이며, 객체지향에서 핵심으로 다루는 다형성은 Inclusion polymorphism(서브타입 다형성) 입니다. 2. "부모 타입으로 다룬다" = "구현이 아닌 추상에 의존" — 이게 무슨 뜻인가?Barbara Liskov (1987), "Data Abstraction and Hierarchy" (SIGPLAN Notices)리스코프 치환 원칙(LSP)의 원전으로, 핵심 개념은 이것입니다:"If S is a subtype of T, then objects of type T may be replaced with objects of type S without altering any of the desirable properties of that program."즉, 코드가 구체적인 자식 클래스(구현)를 몰라도 부모 타입(추상)만 알면 동작해야 한다는 것이고, 이것이 "구현이 아닌 추상에 의존"의 의미. 3. OCP와 다형성/추상화의 관계Robert C. Martin (1996), "The Open-Closed Principle" (C++ Report)"A module should be open for extension but closed for modification."Martin은 이 원칙을 달성하는 핵심 수단으로 추상화(abstraction) + 다형성(polymorphism) 을 명시합니다. 새로운 구현체를 추가할 때 기존 코드를 수정하지 않아도 되는 이유가 바로 부모 타입(인터페이스/추상클래스)에 의존하기 때문입니다.GoF (Gang of Four), "Design Patterns" (1994) — Erich Gamma 외"Program to an interface, not an implementation."위 문장이 "추상에 의존"의 유명한 표현. 4. DIP(의존성 역전 원칙)와의 연결Robert C. Martin, "Agile Software Development" (2002)"High-level modules should not depend on low-level modules. Both should depend on abstractions.""구현이 아닌 추상에 의존"과 정확히 같은 맥락. 참고 자료:Cardelli & Wegner (1985) — "On Understanding Types, Data Abstraction, and Polymorphism"Barbara Liskov (1987) — "Data Abstraction and Hierarchy"Robert C. Martin (1996) — "The Open-Closed Principle"GoF (1994) — "Design Patterns: Elements of Reusable Object-Oriented Software"

안녕하세요. 수업 자료 링크 제공은 어디인가요?

https://gitlab.com/kmmom591-group/uml-basics상기 URL으로 접속하시면, 수업 진행에 사용한 자료 및 실습 자료 확인 가능하십니다.감사합니다 :)

진로가 큰 고민입니다...

안녕하세요 :) 자바·백엔드 포트폴리오, 방산에서 불리할까?결론부터 말하면 마이너스는 아닙니다.다만 직무에 따라 핏이 다를 뿐이에요.방산 기업 안에도 크게 보면임베디드/제어 SW (C/C++)시스템·플랫폼 SW시험·시뮬레이터·도구 개발내부 서버·데이터 처리이렇게 나뉩니다.자바 백엔드 경험은 후자의 영역에서 충분히 의미가 있고,“SW를 구조적으로 설계하고, 문제를 끝까지 해결해본 경험”은 어떤 직무에서도 공통으로 봅니다. 그럼 C/C++을 꼭 새로 파야 할까?지금까지 한 백엔드를 버릴 필요는 전혀 없습니다.대신 “주력은 자바 백엔드,방산을 고려해 C/C++과 Linux를 이해하는 수준까지는 가져가자.”추천은C/C++로 작은 프로젝트 1~2개리눅스 환경에서 빌드·실행 경험네트워크, 메모리, 프로세스 개념 이해이 정도만 있어도 면접에서는“주 언어는 자바지만, 방산 환경을 고려해 C/C++ 기반 시스템도 학습했습니다.”라고 충분히 설득력 있게 설명할 수 있습니다. 3학년 지금 시점에서의 방향 제안지금 하던 자바 백엔드 프로젝트는 계속 완성도, 구조, 설명력을 높이세요동시에C/C++ + Linux는 깊이보다 ‘경험’ 위주방산 SW가 돌아가는 환경을 이해하는 데 초점4학년 때 방산 / 대기업 / 금융권 동시에 지원 가능한 포트폴리오 완성 물론 제가 제시한 방향이나 조언이 100프로 맞다는 보장은 없지만, 미약하게나마 도움이 되시길 바라겠습니다.감사합니다.