분류 전체보기 (8) 썸네일형 리스트형 AWS SAA 합격 후기(26/01/22) 1. 취득 동기 및 베이스엔지니어쪽으로 취업을 준비하면서 짧은 기간 안에 벤더사 자격증을 취득하고 싶었습니다. CKA, CCNA 등 여러 자격증을 고민하다 SAA로 결정했고, 인프런에서 박재성 강사님의 강의를 발견했습니다. Udemy 강의들이 유명하다고 하던데 아무래도 귀에 안 들어오는 외국인이 말하는걸 듣는것보단 인프런이 낫겠다 싶었고, 이전에 Docker 강의를 수강했을 때 만족스러웠던 경험이 있어 이번에도 재성님 강의를 선택했습니다. 실제 공부 기간은 약 5일 정도 소요됐고, 양질의 강의 덕분에 예상보다 빠르게 합격할 수 있었습니다. 베이스는 AWS 주요 서비스들 사용 경험 및 이해 네트워크 기본 지식 정도였습니다! 2. 학습 방법먼저 인프런으로 해당 강의를 수강한 시간입니다. 공부 기간은 2주를 .. 오브젝트 챕터7<객체 분해> 기능 관점에서 하나의 시스템을 구현 가능한 수준으로 분해하는 예시가 소개되었습니다. 비록 이 방식이 정답은 아니지만, 설계 관점에서 인사이트를 얻었습니다. // 시스템에 대한 추상적인 최상위 문장을 기술.직원의 급여를 계산한다.-----// 최상위 문장을 다음과 같이 좀 더 세부적 절차로 구체화.직원의 급여를 계산한다. 사용자로부터 소득세율을 입력받는다. 직원의 급여를 계산한다. 양식에 맞게 결과를 출력한다.-----// 프로그램 언어로 구현 가능한 정도까지 기능을 분해.직원의 급여를 계산한다. 사용자로부터 소득세율을 입력받는다. "세율을 입력하세요:" 라는 문장을 화면에 출력한다. 키보드를 통해 세율을 입력받는다 직원의 급여를 계산한다. 전역 변수에 저장된 직원의 기본급.. 오브젝트 챕터6<메시지와 인터페이스> 이번 장에서는 훌륭한 퍼블릭 인터페이스를 만드는 데 도움이 되는 설계 원칙과 기법을 배웁니다.전 장에서 배운 RDD가 여기에 속하지만 이로는 부족하기 때문입니다. 애플리케이션은 클래스로 구성되지만, 메시지를 통해 정의된다. 용어 정리메시지객체들이 협력을 위해 사용하는 의사소통 수단메시지 전송, 메시지 패싱하나의 객체가 다른 객체에게 도움을 요청하는 것클라이언트, 메시지 전송자메시지를 전송하는 객체서버, 메시지 수신자메시지를 수신하는 객체 메시지 구성 요소오퍼레이션명 + 인자 + (메시지 수신자(메시지 전송시 추가)) 메시지와 메서드의 구분??메서드를 실행하는 객체의 타입을 고려하지 않아도 된다는 말인가? 퍼블릭 인터페이스와 오퍼레이션책의 설명만으로는 둘의 개념 차이가 이해되지 않아서 추가적으로 정.. 오브젝트 챕터5<책임 할당하기> 4장에서 데이터 중심 설계의 문제점을 살펴보았습니다.이를 통해 객체지향 설계에서 가장 중요한 과정 중 하나는 객체에 올바른 책임을 할당하는 것임을 배웠습니다. 5장은 책임 중심 설계의 본질과,, 이를 실현하는 데 필요한 GRASP 패턴이 등장합니다.책임 중심 설계의 기본 원리를 살펴보고, GRASP 패턴을 통해 객체 간 협력을 효과적으로 설계하는 방법을 학습합니다. 객체지향 설계의 본질을 다시 한번 이해할 수 있는 기회가 되었던 것 같습니다. 데이터 중심 설계와 책임 중심 설계의 차이데이터 중심 설계는 객체의 책임보다는 데이터를 먼저 고려하는 방식이라고 했습니다.겉보기에 간단해 보이지만, 이 방식은 캡슐화를 해치고, 객체 간의 결합도를 높이며, 설계를 복잡하게 만듭니다.반대로 책임 중심 설계는 "이 객체.. 오브젝트 챕터4<설계 품질과 트레이드오프> 4장에서는 데이터 중심 설계(Data-Driven Design)와 책임 중심 설계(Responsibility-Driven Design, RDD)의 차이를 비교하며, 책임 중심 설계의 중요성을 강조합니다.2장에서 영화 예매 시스템을 주제로 책임을 적절히 분산하여 시스템을 설계했습니다.이번에는 같은 주제로 데이터를 기준으로 시스템을 설계하는 절차적 방식을 소개합니다. 저자는 이를 통해 나쁜 설계에서 배울 수 있는 통찰력을 제공하며, 데이터 중심 설계의 한계를 설명합니다. 3장에서 학습했던 RDD(Responsibility Driven Design)라는 이름에서 알 수 잇듯 가장 중요한 것은 책임입니다.역할은 책임의 집합으로서 생성되기 때문에 기초가 되는 책임이 적절하지 못한다면, 상위 구조도 불안정해 좋은.. 오브젝트 챕터3<역할, 책임, 협력> 챕터 3는 지난 챕터에서 설명했던 영화 예매 프로그램을 예시로 재활용합니다. 이번 글에서는 역할, 책임, 협력, RDD에 대해서 간략하게 정리했습니다. 협력객체는 사회적인 존재다.메시지 전송은 객체 사이의 유일한 커뮤니케이션 수단이다.메시지를 수신한 객체는 메서드를 실행해 요청에 응답한다. 역할객체가 특정한 협력 안에서 수행하는 책임의 집합을 역할이라고 부른다. 유연하고 재사용 가능한 협력이 역할을 통해 얻을 수 있는 장점이라고 했습니다. 역할은 대부분 인터페이스나 추상 클래스를 통해 구현된다는 것을 알면 이해가 쉬울 것 같습니다. 책임협력에 참여하기 위해 객체가 수행하는 행동을 책임이라고 부른다.책임이란 객체에 의해 정의되는 응집도 있는 행위의 집합으로, 객체가 유지해야 하는 정보와 수행할 수 있는.. 오브젝트 챕터2<객체지향 프로그래밍> 챕터2는 영화 예매 프로그램을 예시로 설명합니다.진정한 객체지향으로의 전환을 위한 두 가지 중점사항.첫째, 어떤 객체들이 어떤 상태와 행동을 가지는지 먼저 결정해야 한다.둘째, 객체를 독립적인 존재가 아닌 기능을 구현하기 위해 협력하는 공동체의 일원으로 봐야한다. 챕터2를 읽고 복기하며 오버라이딩(Overriding)과 오버로딩(Overloading) 사이에서 헷갈리는 느낌을 받았습니다.각각의 개념을 정리하며 정립하겠습니다. 오버라이딩부모 클래스에서 정의된 같은 이름, 같은 파라미터 목록을 가진 메서드를 자식 메서드에서 재정의하는 경우.따라서 외부에서는 부모 클래스의 메서드가 보이지 않는다. 오버로딩이름은 같지만 제공되는 파라미터 목록이 다르다.따라서 부모 메서드를 가리지 않으며, 메서드들은 공존한.. 오브젝트 챕터1 <객체, 설계> 객체지향이라는 개념에 대한 정립이 필요했는데 "오브젝트"스터디 기회를 통해 공부해보려고 합니다.부족해서 깊이있는 이해는 힘들지만, 최대한 많이 배울 수 있도록 노력하겠습니다. 챕터1은 티켓 판매 애플리케이션을 예시로 설명합니다. 모듈의 세 가지 목적실행 중에 제대로 동작하는 것.변경을 위해 존재.코드를 읽는 사람과 의사소통. 하나의 클래스가 다른 클래스의 내부에 대해 더 많이 알면 알수록 해당 클래스를 변경하기 어렵다고 한다. 이는 객체 사이의 "의존성"과 관련된 문제라고 하고 여기서의 의존성은 SW공학에서의 "결합도"로 생각하면 된다.SW공학에서 정의하는 우수한 sw를 만들기 위해서는 응집도를 높이고 결합도는 낮춰야 한다. 반대로 높은 응집도란 본 개체와 연관있는 작업만을 수행하고 연관성 없는 작.. 이전 1 다음
