개발 기록

README.md에 클래스 다이어그램을 올리려고 했는데 도저히 마크다운으로는..할게많다. 그래서 이미지 업로드 방법을 찾아보게되었다.issues 클릭 후 New issue를 눌러 이슈생성한 후 원하는 이미지를 넣는다.깃허브는 이슈나 PR에 이미지를 드래그 해서 업로드 하면 다음과 같이 HTML태그 형태로 변환한다. README 파일에 넣기 위해서는 마크다운 형태가 필요한데 다음과 같은 형태로 수정하면 된다.[ ] : 이미지의 대체 텍스트(alt text)( ) : src의 주소이후 README 파일에 해당 코드를 복사해 넣으면..

제네릭(Generics) 제네릭은 클래스, 메서드, 인터페이스에서 타입을 파라미터로 사용할 수 있게 해주는 기능타입 안정성(type-safety) 제공 + 코드 재사용성을 높임문법class Box { private T value; public void set(T value) { this.value = value; } public T get() { return value; }} 는 타입 매개변수(Type Parameter)T 자리에 실제 타입이 들어감제네릭과 Map/CollectionMap 구조에서 Key와 Value를 일반화 가능K와 V를 제네릭 타입으로 선언하면 다른 타입도 재사용 가능Map map = new HashMap();직접 활용해보기Car..

상황 요약Cart 클래스에서 Map 구조로 장바구니 관리.MenuItem은 이름(name)과 가격(price)을 가진 단순한 객체.같은 메뉴 이름을 여러 번 담을 때 수량이 합쳐져야 하는데, 서로 다른 MenuItem 인스턴스로 인식되어 중복 저장되는 문제가 발생할 수 있음.MenuItem m1 = new MenuItem("Americano", 2000);MenuItem m2 = new MenuItem("Americano", 2000);cart.addCartItem(m1, 1);cart.addCartItem(m2, 1); // ❌ 중복 추가됨 원인 분석자바에서 HashMap은 Key를 비교할 때 동일성(==)이 아니라 동등성(equals)을 사용하지만 다음과 같은 두 단계가 필요하다hashCode() →..

[Error] 키오스크 트러블 슈팅 1 - 상태 패턴enum 상수과 switch문으로 관리하던 상태에서 상태 패턴 적용 해보는 것도 괜찮을 것 같다고 하셔서 검색 후 내 코드에 적용해 보았다. 기존에 키오스크 실질적인 기능을 담당하는 start() 메소드가devz0.tistory.com [Error] 키오스크 트러블 슈팅 2 -책임 분리이전 글에서 이어지는 내용 [Error] 키오스크 트러블 슈팅 1enum 상수과 switch문으로 관리하던 상태에서 상태 패턴 적용 해보는 것도 괜찮을 것 같다고 하셔서 검색 후 내 코드에 적용해 보았다. 기devz0.tistory.com오래되긴 했지만 API 만들어본 경험이 있어서 과제 로직 구현 자체는 어렵지 않았다. 객체 지향 적인 코드 흐름 문제 제외하고 가장 생..

이전 글에서 이어지는 내용 [Error] 키오스크 트러블 슈팅 1enum 상수과 switch문으로 관리하던 상태에서 상태 패턴 적용 해보는 것도 괜찮을 것 같다고 하셔서 검색 후 내 코드에 적용해 보았다. 기존에 키오스크 실질적인 기능을 담당하는 start() 메소드가devz0.tistory.com키오스크 프로그램을 작성하면서 상태패턴을 도입했다.Kiosk 클래스가 State를 관리하고, 각 상태(START, MAIN_MENU, SUB_MENU, CART, ORDER)는 사용자의 입력에 따라 다음 상태로 전이된다.초기 설계에서는 Kiosk 내부에서 상태 전이(currentState = State.MAIN_MENU)를 직접 수행했지만,점차 책임 분리의 중요성을 알게되며 로직을 수정하다 State와 Kios..

enum 상수과 switch문으로 관리하던 상태에서 상태 패턴 적용 해보는 것도 괜찮을 것 같다고 하셔서 검색 후 내 코드에 적용해 보았다. 기존에 키오스크 실질적인 기능을 담당하는 start() 메소드가 굉장히 길었는데 그 부분은 간략하게 생략되었지만 고려해봐야할 몇가지 문제가 생겼다. 그 과정을 정리해보려고 한다.목표기존 enum + switch 구조에서 상태 패턴(State Pattern)을 적용하여 Kiosk 클래스의 start 메소드 단순화 및 코드 재사용성 향상을 시도상태 패턴 적용 후 장점 start() 메소드가 간단해지고, 상태 전환 로직이 상태 객체로 분리됨.상태별 클래스(StartState, MainMenuState, ...)를 독립적으로 관리 가능 → 재사용성, 확장성 향상.새로운 ..

상태 패턴이란객체가 상태에 따라 다른 행동을 해야 할 때 사용하는 디자인 패턴상태를 객체로 캡슐화해서 상태 전환과 행동을 독립적으로 관리조건문 (if / switch)을 최소화할 수 있음객체가 여러 상태를 갖고있고 상태별로 행동이 다를때나, 상태가 자주바뀌고 상태별 로직이 길어서 조건문이 지저분할 때도 사용가능구성 요소구성 요소역할Context상태를 가진 객체State Interface상태 인터페이스/추상 클래스ConcreteState각 상태 구현장점조건문 최소화 → 코드가 깔끔상태별 행동 캡슐화 → 유지보수 용이새로운 상태 추가 용이단점상태 클래스가 많아질 수 있음 → 관리 필요상태 전환 로직이 복잡하면 Context가 상태를 지나치게 알게 됨적용간단한 기능이라 기본적인 상태패턴 규칙처럼 클래스로 나누..

List도 하나의 value로 취급 할 수 있다. List를 value로 사용하면 하나의 엔티티가 여러 데이터를 갖는 복합 구조를 쉽게 표현 할 수 있다.예시class Menu { private String name; private List menuItems; // List를 값으로 사용}List coffeeItems = new ArrayList();coffeeItems.add(new MenuItem("아메리카노", 4500));coffeeItems.add(new MenuItem("카페 라떼", 5500));Menu coffeeMenu = new Menu("Coffee", coffeeItems); Menu nonCoffeeMenu = new Menu("Non-Coffee", coffeeItems); ..

Mapkey, value의 쌍으로 데이터를 저장하는 자료구조Map map = new HashMap();map.put("name", "철수");map.put("city", "서울");System.out.println(map.get("name")); // 철수System.out.println(map.get("city")); // 서울특징key는 중복 불가value는 중복 가능빠른 검색/조회 가능(key로 value접근)구현체HashmapKey 해시값으로 저장 → 조회 빠름LinkedHashMap입력 순서 유지TreeMapKey 기준 정렬Map Value에 객체 사용Value에 클래스 객체를 담으면 단순 값뿐 아니라 상태와 동작(메서드)까지 관리 가능예제: 도서관 대출/반납 book 클래스public clas..

자바 입문하면서 가장 처음 맞이한 난관이다. 이번 과제를 수행해가며 과제 수행 여부에만 집중했다. 구현하라니까 구현하고 이런식으로 그 기준에만 맞추려고 했다. 팀원간에 setter의 적용에 대한 이슈가 나오며 setter를 사용하지 않으셨다는 의견을 들었다. 덧붙여 주신 의견으로 setter를 지양해야한다는 글들을 접하셨다고 하셨다. 나도 그이야기를 들은 후 찾아보니 진짜 지양해야한다는 글이 상당히 많았다. 하지만 찾아봐도 왜 지양해야할까에 대한 궁금증이 해소되지않았다. 왜 지양해야할까? 값에대한 private 필드를 그럼 어떻게 간접적으로 접근하고 저장할까??getter/setter객체의 필드(데이터)에 접근하기 위한 간접 통로private 필드에 직접 접근하지 않고, 메서드를 통해 접근하게 만드는 구..