728x90 개발/일반7 객체 지향의 사실과 오해 - 독후감 전부터 읽고 싶었던 책이었는데, 드디어 시간이 되어 읽었다! 솔직히 말해서 기대감이 높았던지 그 기대감을 충족 시켜주진 못했다. 내가 생각했던 객체지향과 같은 내용을 좀더 명확하게 정리해준 느낌이다. 물론 이것만으로도 충분히 가치가 있다! 기억 나는 내용들을 좀 정리해 보았다. - 객체의 행동 : 객체는 요청을 받으면, 내부상태를 변경하거나, 다른 객체에 요청을 보낸다. (혹은 둘다) - 객체와 현실의 차이 : 현실과 다르게 SW의 객체는 스스로 행동한다. 음료 객체가 스스로 양을 줄이는 행동을 한다. - 설계 : 상태보다는 객체의 행동을 중심으로 설계를 한다. - 개념 그룹 : 공통점들을 뽑아 개념 그룹(객체)을 만든다. ex) 고등어, 광어 등 -> 물고기 - 인터페이스 : 외부에 노출되는 메소드를 .. 2021. 9. 27. 웹 설계 과정 첫 회사에서 프로젝트를 진행하며 설계를 처음부터 경험할 수 있었다. 1. 컨셉 기획 > 개발 기간과 구현 가능여부 등을 함께 논의했다. 2. 기능정의 - execel > 필요한 기능 List를 작성 > 기능 분류까지 진행한다. (즉, 어떤 기능이 어떤 메뉴에 들어가야 할지) 3. 화면설계 - ppt > 말그대로 보여질 웹 화면을 설계한다. 4. 기술스택 결정 > 어떤 언어와 기술들로 개발을 할지 결정한다. 5. 개발 > 일정 산출 및 개발을 시작 > 프론트&디자인 & 백엔드가 동시에 개발을 진행하면서 맞춰 나간다. 이것을 경험하며 배운 것은, 중간에 대략적으로 이정도면 되겠지 하던 것들이 나중에 일을 두번, 세번 하게 만드는 원인이 된다는 것이다. 틀을 확실하게 가져가야지만 뒤에 탈이 없다. 2021. 3. 14. 도메인 패키지 구조 프로젝트를 만들면서 패키지를 만들었다. 본능적으로 아래와 같이 구성했다. 컨트롤러 - 회원 - 상품 서비스 - 회원 - 상품 엔티티 - 회원 - 상품 코드를 작성하던 도중 회원 관련 class 파일들을 찾아 위아래 스크롤 하고 있는 나를 발견했다. 이런 생각이 들었다. 회원 관련된 파일이 한곳에 모인다면 작업하기에 더 편하지 않을까? 회원 - 컨트롤러 - 서비스 - 엔티티 상품 - 컨트롤러 - 서비스 - 엔티티 도메인 패키지 구조 라고 검색해보니 여러 정보들을 얻을 수 있었다. 그 중 인프런의 백기선님의 답변을 볼 수 있었고 납득이 되었다. 프로젝트 패키지를 도메인단위로? - 인프런 | 질문 & 답변 (inflearn.com) 프로젝트 패키지를 도메인단위로? - 인프런 | 질문 & 답변 물어보신 질문에 .. 2021. 3. 14. API URI 설계에 대한 고민 참고할만 문서 : API 디자인 지침 - Best practices for cloud applications | Microsoft Docs URI 설계 도중 고민거리가 생겼다. Q. 여러 회사가 있을 때 "회사에 소속된 팀 조회" & "회사에 소속된 사원 조회" 를 하는 api를 만들 경우 1. /회사/{id}/팀 /회사/{id}/멤버 2. /팀?회사id=1 /멤버?회사id=1 나는 1번이 맞다고 생각했으나, 더많은 정보가 있을 때 /회사/{id}/장비 /팀/{id}/멤버 등 api 개수가 너무 많아지는 문제가 있다고 생각되었다. 2번의 경우도 더많은 검색조건 경우의 수가 생기기에 /멤버?회사id=1&팀id=2&성별=남 처럼 하나의 uri 컨트롤러가 너무 많은 기능을 담당하게 되는 문제가 있다고 생각되었.. 2021. 3. 14. 이전 1 2 다음 728x90
