📝 객체지향 설계 강의 노트

랜덤넘버는 구현체이니까 Number로 받자

이러면 모두가 움직이는데 ?

의존성 주입 DI

스프링 프레임 워크는 DI를 구현하도록 강제되어 있다.
의존성 주입을 위해서는 스프링을 써야한다는 말이 있는데 그렇지 않다.

스프링 프레임 워크를 쓰지 않은 채로 DI를 해본 적이 있습니까 ?

생성자 의존성 주입

❓ randomNumbers를 객체의 변수로 두고있는데, move()의 인수로 넘겨받는 것은 어떨까요?
-> 상관 없음

move 메서드를 사용할 때마다 객체를 생성해야하니

인자가 많아졌을 떄는 생성자를 전달하는 것이 좋을 수도..

❓ 의존성 주입을 위한 setter는 괜찮나요 ?
-> 어떤 객체냐에 따라 다른데, 지금은 Cars의 상태 데이터를 가지고 있는 현제 예시에서는 final로 선언해주는 것이 좋다. setter 써도 상관은 없다.

Dependency Injection인데 객체가 다른 객체에 의존하는 것을 외부에서 주입하는 경우를 DI라고 하지 않을까여..?

setter를 사용하는 부분은 전략패턴이 좋은 예시가 되지않을까요?

저는 내부 로직을 객체로 추출할 수 있을때 추출한 후 주입받아 사용하는 식으로 변경할 때 ‘DI한다’ 하는거 같아요

객체지향적 설계는 기본적으로 객체간의 협력을 만들어내는 일이고, 이를 가능하게 하기 위해서는 객체간의 의존성이 필요해요.
-> 그럼 setter를 활용할 수 있지않을까용

의존성을 DI가 아닌 내부에서 만들어 줄 수도 있지만, 이렬 결우 강한 결합성을 가지기 때문에 변경에 자유롭지 않아 DI가 필요하다고 생각해요

유지보수하기 좋은 코드

작은 코드가 유지보수하기 쉽다.
클래스가 작으면 메서드와 프러퍼티가 더 가까이 있을 수 있기 때문에 응집도가 높아진다.
간단히 말해 각각 메서드가 모든 필드를 사용한다.

불변 객체로 만드세요

함수형 프로그래밍은 side eggect를 만들지 않는다.
가변 객체는 말고 불변 객체를 만들어야 side effect가 생기지 않는다.
불변 객체로 만들다보면 인스턴스가 많아져서 성능이 떨어진다 .

-> 이는 캐싱 전략을 통해 해소하자

불변 객체로 만들다 성능 이슈가 생기면 가변 객체나 캐싱을 사용해라

모든 클래스를 불변으로 만들면 유지보수가 쉽다.

현재 불변 객체가 아니다.
Position이 final이 아니다.
c메소드들이 car를 리턴하도록 변경한다 ?

요거는 가변 객체

사이드 이펙트가 밝생할 수 있다.

값을 바꾸면 계속 새로운 객체를 만들죠 ?

무슨 개소리야 할 수 있지만 분명히 다르다. 근데 계속 객체를 할당 받아야 하네

상태가 바뀌면 계속 새로운 것을 반환해주어야 하니…

불변 객체는 list 내부의 상태 데이터를 추가하고 뺴는 것도 불변 객체 이다.

이렇게 clear하는 것도 허용이다.

❓그렇다면, 메모리의 주솟값이 불변이면, 메모리의 주솟값이 참조하고 있는 값이 변경되도 불변이다 라고 보는 건가요?
-> 그렇다.

불변 객체와 상수 객체의 차이에 대해 공부해 보세요.

불변 객체로 구현하면 좋은 점

• 식별자 가변성 문제가 없다.
• 실패 원자성이 있다 - 완전하고 견고한 상태의 객체를 가지거나, 실패하거나 둘 중 하나만 가능하다.
• 시간적 결합을 제거할 수 있다. - 가변 객체가 많은 경우 연산들의 순서를 일일이 기억해야한다.
• 사이드 이펙트를 제거할 수 있다.
• null 참조를 없앨 수 있다.
• 스레드 세이프하다.
• 더 작고 더 단순한 객체를 구현할 수 있다.

public 상수를 사용하지 마세요.. ?

상수라고 불리는 public static final 프로퍼티는 객체 사이의 데이터를 공유하기 위해 사용한다.
사용하지 말라는 이유는 객체들은 어떤 것도 공유해서는 안되기 때문이다.
독립적이어야 하며, 닫혀 있어야 한다.

하지만 일반적으로는 public 상수를 쓰는게 관례이다.

상수를 쓸거면 객체로 만들어라??
OOP에서 퍼블릭 상수를 절대로 사용하지 말라고 한다.
사소한 상수라도 항상 작은 클래스를 이용해 대체할 것을 추천한다.
enum도 public static final을 쓰는 건데 쓰지 마라!

그냥 설계가 완벽하다 싶을 때 도전해라 ^^

인스턴스 변수는 4개 이하로… 근데. 번외로 데코레이터 필드는 허용된다고 생각합니다.

position, name의 클래스 접근자를 없애는 것은 ??
그러면 패키지 내부의 결합도를 낮출 수 있고, 인터페이스로 다 만들려면 너무 많아지는 문제점 해결

스프링 프레임 뭐크는 객체들의 의존성을 없앤다.

스프링 프레임워크를 위한 강의였따.