인스턴스 메소드/클래스 메소드/스태틱 메소드, 알고리즘: 징검다리, ORM(lazy loading, eager loading, select_related, prefetch_related, n + 1, caching)

1. 클래스 메소드와 스태틱 메소드

'''
1. 인스턴스 메소드 : 첫 번째 매개변수로 객체를 받는다 -> self
2. 클래스 메소드 : 첫 번째 매개변수로 자기 클래스를 받는다 -> cls
3. 스태틱 메소드 : 일반 함수와 거의 비슷해 클래스와 연관성이 있음을 나타내는 정도로 쓰인다/
4. 클래스 메소드 vs. 스태틱 메소드
    - 공통점 : 클래스 변수에 접근 가능하지만 생성자를 포함한 인스턴스 메소드 변수에는 접근 불가능하다.
    - 스태틱 메소드 : 부모 클래스에서 정의된 스태틱 메소드는 자식 클래스에서 호출할 수 있다.
    - 클래스 메소드 : 부모 클래스에서 정의된 클래스 변수와 클래스 메소드는 자식 클래스에서도 선언이 가능하다.
    - 상속할 때 차이점 : 자식 클래스가 존재할 때, 스태틱 메소드는 부모 자식 어디서 선언하든 클래스 변수를 모두 바꾸지만, 클래스 메소드에서는 부모 클래스 객체에서 선언해야만 자식 클래스의 클래스 변수까지 모두 바꿀 수 있다. 자식 클래스에서 선언하면 자식 클래스의 클래스 변수만 바뀐다.
'''

class Parent:
    name = 'Geumbin Lee'
    
    @staticmethod
    def change_name_with_static(new_name) :
        Parent.name = new_name
        
    @classmethod
    def change_name_with_class(cls, new_name) :
        cls.name = new_name
    
class Child(Parent) :
    pass

parent = Parent()
child = Child()

print('<<<<< 스태틱 메소드에 대해 배워봅시당 >>>>>')
parent.change_name_with_static('Robin Lee')
print(f'부모 클래스에서 선언 : {parent.name}, {child.name}') # Robin Lee, Robin Lee
child.change_name_with_static('Katy Lee')
print(f'자식 클래스에서 선언할 때 : {parent.name}, {child.name}') # Katy Lee, Katy Lee

print('-'*50)
print('<<<<< 클래스 메소드에 대해 배워봅시당 >>>>>')
parent.change_name_with_class('Robin Lee')
print(f'부모 클래스에서 선언 : {parent.name}, {child.name}') # Robin Lee, Robin Lee
child.change_name_with_class('Katy Lee')
print(f'자식 클래스에서 선언할 때 : {parent.name}, {child.name}') # Robin Lee, Katy Lee

1. 프로그래머스 - 이분 탐색: 징검다리

def solution(distance, rocks, n):
    answer = 0
    rocks.sort()
    start, end = 0, distance
    
    while start <= end: 
        mid = (start + end) // 2
        del_rock = 0 # 제거 횟수 카운트
        stone = 0 # 기준점
        for rock in rocks:
            if rock - stone <  mid: # 거리가 mid보다 작으면 제거한다.
                del_rock += 1 
            else: # 돌 사이 거리가 mid보다 크면 기준을 바꾼다.
                stone = rock
             
            if del_rock > n: #제거된 돌이 문제 조건 보다 크면 for문을 나온다
                break
        
        if del_rock > n: # 제거할 바위 수(n)보다 많은 바위를 제거했을 시 범위를 줄인다.
            end = mid - 1
        else: # 그게 아니면 큰 쪽으로 줄인다.
            answer = mid
            start = mid + 1
        print(f"start : {start}, end : {end}, mid : {mid}, del_rock : {del_rock}, answer :{answer}")
            
    return answer

solution(25, [2, 14, 11, 21, 17], 2)

1. ORM
   • 정의 : 객체와 관계형 데이터베이스의 데이터를 자동으로 매핑(연결)해준다.
   • SQL로 변환해서 들어가기 때문에 sql문을 잘 몰라도 작성할 수 있다. where를 filter로 가져오는 식
   • 특징
     1. Lazy Loading
        • 말 그대로 게을러서 실제로 데이터를 조작하는 순간에 DB를 hit한다.
        • 필요할 때마다, 필요한 횟수만큼만 db를 건드린다.
        • n + 1 문제를 발생시킬 수 있다.
     2. n + 1 문제
        • N건의 데이터를 가져오고(쿼리 +1), 특정 데이터를 위해 N건의 데이터를 순회(쿼리 +N)하는 문제
        • ORM은 필요할 때마다 쿼리문을 수행하기 때문에 조회할 데이터가 개수가 증가할수록 쿼리문 수행 개수도 증가한다 → 서버 부하 UP → 속도 DOWN
        • 해결책 : Eager Loading
     3. Eager Loading
        • 말 그대로 굉장히 열심(eager)이다. 지금 당장 안 필요한 데이터도 가져온다. → select_realted와 prefetch_related
        • select_realted
          • SQL의 JOIN을 사용하는 방법 → 외래키로 종속된 테이블의 데이터를 함께 들고 온다 (부지런하다)
          • One 객체를 참조하는 경우(one-to-one, many-to-one), 정참조 관계일 때(many-to-one(many에서 one 참조)) 사용 가능
          • 정참조와 역참조 모두 사용 가능한 prefetch_realted에 비해 범용성은 떨어지지만, 대개 성능이 더 좋기 때문에 가능한 상황에서는 select_related를 사용하는 것이 좋다.
        • prefetch_related
          • 공식 문서에서 ‘joining’이라고는 하나, 그 JOIN이 아니고, 테이블을 각각 불러들인 후 ORM 처리 단계에서 결합하는 방식
          • 따라서 항상 추가 쿼리가 발생한다. 그래서 대개 select_realted에 비해 성능이 떨어진다. (항상은 X)
          • 정참조 역참조 모두 사용 가능
     4. Caching
        • 캐싱을 활용해 이미 가져온 데이터를 쿼리문을 또 날리지 않고 그대로 재사용할 수 있다.
        • 핵심은 그대로!!! 가져온 데이터에 무언가 가공을 가하지 않은 상태여야 캐싱을 활용할 수 있다. ex) 슬라이싱이나 인덱싱하면 안됨
        • 당연히 많이 활용할수록 속도가 개선된다.