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

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); ..

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

확장에는 열려있고 수정에는 닫혀 있어야 한다객체지향 설계 5대 원칙(SOLID)중 하나로 기존 코드를 수정하지 않고도 새 기능이나 요구사항을 추가할 수 있어야 한다는 개념이다.계산기 예제로 살펴보면좋지못한 설계class Calculator { public double calculate(double x, double y, String operator) { if (operator.equals("+")) return x + y; else if (operator.equals("-")) return x - y; else if (operator.equals("*")) return x * y; else if (operator.equals("/")) return ..

StackLIFO(Lasn In, First Out) 자료구조즉 마지막에 넣은 데이터가 가장 먼저 나오는 자료구조이다. 웹 브라우저 뒤로가기 히스토리 동작을 생각해보면 알 수 있다.Java의 Stackimport java.util.Stack;Stack stack = new Stack();메서드메서드설명push(E item)스택의 맨 뒤에 데이터 추가pop()스택의 맨 뒤 데이터 제거 후 반환peek()스택의 맨 뒤 데이터 확인 (제거X)Stack 클래스의 문제불필요하게 느림 (Thread-safe)모든 연산이 안전하게 스레드용으로 처리한 번에 한 스레드만 접근 가능하도록 락(lock)을 걸어서 동작하지만 대부분의 코드에서는 하나의 스레드만 사용하기 때문에 불필요예전 방식의 오래된 클래스다른 컬렉션들(Li..

캡슐화객체의 상태(필드)를 숨기고(보호) 공개된 메서드로만 접근하게 해서 내부 구현을 바꾸더라도 외부에 영향이 없게 만드는 설계 원칙캡슐화의 목적 데이터 보호: 필드를 private으로 숨겨 잘못된 접근(무결성 훼손)을 막음인터페이스와 구현 분리: 외부는 무엇을 할 수 있는지(메서드)만 알고, 내부 구현은 바꿀 수 있음유지보수성 향상: 내부를 바꿔도 외부 코드는 그대로 작동응집도 증가 / 결합도 감소: 책임이 분명해지고 모듈화가 쉬워짐검증/비즈니스 로직 중앙화: 값 유효성 검사, 상태 변화 규칙을 한곳(setter/메서드)에 모을 수 있음적용 예제1. 필드를 private으로 선언내부 속성은 private으로 숨기고, 외부는 public 메서드를 통해 접근하게 함private int result;priv..

인터페이스인터페이스란 "이 클래스는 이러한 기능들을 반드시 가지고 있어야 해" 라는 규칙을 정해놓은 설명서 같은 개념이다. 클래스가 반드시 구현해야하는 메서드의 목록만 담겨있다.public interface RemoteControl { void turnOn(); void turnOff();}public class TV implements RemoteControl { public void turnOn() { System.out.println("TV를 켭니다"); } public void turnOff() { System.out.println("TV를 끕니다"); }}리모콘의 경우로 예시를 살펴보면 켜기/끄기 기능은 꼭 있어야 한다는 약속을 정한 것이..

문제 설명정수 배열 arr가 주어집니다. arr를 이용해 새로운 배열 stk를 만드려고 합니다.변수 i를 만들어 초기값을 0으로 설정한 후 i가 arr의 길이보다 작으면 다음 작업을 반복합니다.만약 stk가 빈 배열이라면 arr[i]를 stk에 추가하고 i에 1을 더합니다.stk에 원소가 있고, stk의 마지막 원소가 arr[i]보다 작으면 arr[i]를 stk의 뒤에 추가하고 i에 1을 더합니다.stk에 원소가 있는데 stk의 마지막 원소가 arr[i]보다 크거나 같으면 stk의 마지막 원소를 stk에서 제거합니다.위 작업을 마친 후 만들어진 stk를 return 하는 solution 함수를 완성해 주세요.Pseudo Code 초기화stk → 결과 배열idx → arr 순회 인덱스반복 조건idx 조건 ..

int[ ] Integer [ ]int[ ] -> Integer [ ]int[] arr = {1, 2, 3};Integer[] objArr = Arrays.stream(arr) .boxed() .toArray(Integer[]::new);Arrays.stream(intArr) → IntStream 생성.boxed() → int → Integer 변환 (int 값을 Integer 객체로 감싸서 객체 배열 생성).toArray(Integer[]::new) → 최종 Integer[] 배열 생성Integer [ ]-> int[ ] Integer[] wrapperArr = {1, 2, 3};// Stream ..

메서드(Method)기능 단위로 묶인 코드 블록입력(매개변수) -> 처리(작성된 로직) -> 출력(리턴값) 객체지향에서 객체의 행동을 정의한가지 기능만 수행반복되는 코드는 메서드로 분리기본 구조[접근제어자] [리턴타입] 메서드이름([매개변수]) { // 수행할 코드 return 값; // 리턴 필요 시}public int add(int a, int b) { return a + b;} 접근제어자: public, private, protected, 생략(default)리턴타입: 반환값 자료형, 없으면 voidpublic void printHello() { System.out.println("Hello!");}매개변수: 타입과 변수명 필수접근 제어자 범위public → 어디서나 ..