오늘의 몸상태는 어제보다 좋다 하하
날이가면 갈수록 회복되는게 느껴진다. 물론 내일부터 다시 몸상태가 안좋아질 예정이지만, 오늘과 내일 열심히 할 것이다.
오늘은 컬렉션 배열강의 1.5배속으로 들으면서 강의 내용을 정리할 것이고, 배열 다음인 LinkedList 강의 2배속으로 들으면 키워드를 작성할 예정이다.
오후에는 새로운 과제 야구게임이 나온다. 가 아니고 키오스크 등장! 해당 과제의 흐름을 오후에 정리한 뒤, 이전에 고쳐할 것들 (네이밍, 클래스 나누기, 무분별한 세터,... 등등) 에 유의하며, 작성할 수 있을 만큼 코드를 작성할 것이다.
또, 과제를 하는 것에 부족함을 느끼는 파트를 추가로 공부하거나, 강의를 이어서 더 들을것 같다!
배열과 같이 여러 데이터(자료)를 구조화해서 다루는 것을 자료 구조라 한다.
알고리즘의 성능을 분석하는 수학적 표현 방식이다.
데이터 크기에 증가에 따른 연산 수를 계산한 것으로 대략적으로(어느정도의 추세) 이렇것이다 를 알려주는 차트이다.
- 매우 큰 데이터가 있다고 가정
O(1) - 상수 시간
데이터의 크기와 상관없이 알고리즘의 실행 시간이 일정하다
O(n) - 선형 시간
데이터의 크기에 따라 알고리즘 시간이 비례해서 커진다.
O(n^2) - 제곱 시간
데이터의 크기에 제곱하여 알고리즘 시간이 증가한다.
O(log n) - 로그 시간
데이터의 크기에 로그에 비례해서 알고리즘 시간이 증가한다.
O(n log n) - 선형 로그 시간
배열은 인덱스를 가지고 하는 연산(실행)은 빅오 표기법으로 O(1) - 상수 시간 로 매우 빠르게 처리한다.
그럼 인덱스를 가지고 어떻게 빠르게 연산하는지? 어떤것이 인덱스를 이용한 연산인지 알아보자!
배열은 참조형 데이터로, 참조값과 데이터 타입에 크기를 이용해서 인덱스를 쉽게 찾을 수 있도록 했다. ( 데이터 꽉이 다 붙어 있고, 꽉의 타입이 하나로 정해져있다. )

다음으로 어떤것이 인덱스를 이용한 연산인지 알아보자.
1. 입력 2. 변경 3. 조회 가 있다.
모든 데이터를 거쳐야하는 - > 순회해야하는 것이 있다. - 검색
'어떤 값을 찾을때' 가 그것이다.

물론 위 행동을 빠르게 해줄 메서드는 준비되있으니 걱정 ㄴ
ps
크기를 처음부터 크게하면 메모리 낭비!
ps
이동한다는 건 해당 값을 인덱스+1 자리에 복사 한다는 말 - > 마지막 인덱스부터 오른쪽으로 밀어야한다!
말그대로 배열과 리스트를 합친 느낌
위에 쓴 내용 처럼 배열은 생성시점에 크기가 정적으로 고정되있어, 크기가 변해야하는 곳에선 적합하지 않다. 그래서 크기가 유동적으로 변하는 List를 배열에 접목시킨 것이다.
새로운 과제 키오스크가 재밌어서 오늘의 강의는 생략한다!!!
새로운 과제 키오스크가 재밌어서 오늘의 강의는 생략한다!!!
Scanner 로 입력받은 값 출력 + 반복문
절차 지향에서 만든 menuItem 을 클래스로 만들었다.
해당 클래스에서 만든 객체를 다시 Main 에서 반복문으로 출력하였다.
나는 확실히 아직 개발자스럽지 못한것 같다. 물론 java를 배운지 3주차이지만, 기존에 python 은 이전에 해두었기에, 마인드 정도는 잡혀있는 줄 알았는데... 아니였다.
느낀것
내 코드를 누가봐도 이해하기 쉬워야한다.
- > 같이 협업하는 동료가 있다면, 파트를 나누어서 진행할 경우가 있을텐데, 동료분이 내가 짠 코드에 의문을 가지거나 하는 일은 분명 없어야한다.
객체를 생성해서 오는 이점이 많은데, 이제까지 이상하게 클래스 라는 맛있는 틀을 만들어 두어, 클래스의 메서드에서 필드의 값을 채우려했다... 무슨말인지 모를 수 있다...
한마디로 그냥 붕어빵 틀 사서, 혼자 붕어 그리고 팥 넣는 멍청한 행위를 했다는 소리이다.
째든 3주차 마무리 시점에라도, 해당 문제를 알아서 다행이다. 고치려고 노력해야겠다.
나는 클래스 필드 맴버에 static을 넣어 MenuItem 의 객체를 관리하려 했다.
이렇게 한 이유는 출력한 같을 한번에 보여주기 위함이였고, 이것 또한, static을 오용했다는 것을 알게되었다.
동료 영빈gpt에게 만든 코드를 보여주는 중, static을 쓰면 나의 코드가 다른 어떤 누가봐도 이해할 수 없는 역할(기능)을 가진 클래스 혹은 객체라는 것을 알게 되었다...
얼마전에 static 강의와 참고자료를 공부하면서, static이 중요하다는 생각에... 오용을 범했다... 고치려고 노력해야겠다.
MenuItem 을 관리해주는 Kiosk 클래스를 생성
Kiosk 클래스에 start 메서드를 정의( MenuItem 생성 및 인터페이스 ) 하여 Main에서 실행
start문에 try-catch문 사용
try-catch문
try-catch문은 scope 영향을 받는다!
- > 만약 try 문에 실행 코드에 지역변수가 있다면,
catch문의 실행문이나,finally문의 실행문에선 해당 지역변수를 사용할 수 없다.
-> 그래서 만약 이런 경우에 봉착한다면, try와 finally로 나누지말고, 모두 try문에 넣어 예외를 걸르는게 맞다.
디버깅의 중요성
위에 문제를 인지하고 코드를 짜는 중, catch를 했을 때, 반복문이 일정 코드만 돌아가는 버그? 를 발견했다... 해당 문제를 해결하기 위해 break 와 문제를 인지해줄 변수 또, 회귀를 위한 장치도 마련했다...
결과 - > 잘 돌아간다. 하지만 코드가 너무 더러워지는 것을 느껴 튜터님께 질문을 했고, 답을 찾았다.(물론 여기서 문제 해결을 다루진 않을 것이다.)
튜터님은 디버깅을 이용하여 해당 문제를 파악했고, 문제는 생각보다 쉽게 해결되었다.
디버깅이 중요성을 느꼈다. 만약 내가 누군가에게 질의? 질문을 할 수 없는 상황에선 나 혼자 해결해 가야하는데, 이 부분에서 해결하지 못하면 위 처럼 힘든? 혹은 코드가 조잡해지는 길을 걸어야한다. 혼자서 버그를 잘 찾고, 수정을 잘 하는 자가 되보자!
오버라이딩과 오버로딩 차이
오버로딩 - 같은 메소드라도 매개변수만 다르면 메서드를 정의 할 수 있다.
- > 매개변수의 타입, 갯수 , 순서
오버라이딩 - 부모클래스로 부터 상속받은 메서드를 더 이쁘게 꾸미는 것
가변인자
매개변수로 들어오는 값의 개수와 상관 없이 동적으로 인수를 받아 기능하도록 해주는 문법을 지칭한다.
메서드 파라미터 부분에 '타입... 매개변수명' 으로 처리하면 사용이 가능하다.
- > 해당 방법은 메서드뿐 아니라, 생성자의 매개변수에도 사용가능하다!
🚩 주위할 점! ---
1. 만일 매개변수가 가변 인자 외에 다른 매개 변수들도 받는다면, 반드시 가변 인자를 메서드 파라미터 가장 마지막에 위치하도록 정의해야 한다.
2. 가변 인수 메서드는 호출될 때 마다 배열을 새로 하나 할당하고 초기화 하므로,
성능에 민감한 상황에서는 마이너스적인 요소가 될 수 있다.
3.하나의 클래스 내에 가변인자를 사용한 메서드를 오버로딩하는 것은 권하지 않는다.
컴파일러가 어떤 메소드를 사용해야 하는지 구분하지 못하기 때문에 컴파일 에러가 발생하기 때문이다.
조금 더 있지만, 밑에 링크를 통해 더 알아보길 바랜다.
🚩---
🚩 동일성 - 동일성은 동일하다는 뜻으로, 두 개의 객체가 완전히 같은 경우를 의미한다.
여기서 완전히 같다는 뜻은 ** 두 객체가 사실상 하나의 객체로 봐도 무방 **하며, ** 주소 값이 같기 때문 ** 에 두 ** 변수가 같은 객체를 가리 ** 키게 된다.
🚩 동등성 - 동등성은 동등하다는 뜻으로, 두 개의 객체가 ** 같은 정보 ** 를 갖고 있는 경우를 의미한다.
동등성은 ** 변수가 참조하고 있는 객체의 주소가 서로 다르더 ** 라도 ** 내용만 같으면 두 변수는 동등 ** 하다고 이야기할 수 있다.
_** 동일하면 동등하지만, 동등하다고 동일한 것은 아니다. **_
그리고 해당 변수가 동등한지 equals 연산자를 통해 판별할 수 있다.
🚩 주위할 점!---
** == 연산자는 객체의 동일성을 판별 ** 하기 위해 사용하며, ** equals 연산자는 두 객체의 동등성을 판별 ** 하기 위해 사용한다.
** equals 연산자는 재정의하지 않으면 내부적으로 == 연산자와 같은 로직을 수행하므로 차이가 없다. **
따라서 ** equals 연산자는 각 객체의 특성에 맞게 재정의를 해야 동등성의 기능을 수행** 한다.
🚩---