Thrities

https://popcorntree.tistory.com/3

https://lazymankook.tistory.com/32

https://kjwsx23.tistory.com/167

Escpae text when pasting into a string literal 체크하면 됌.

보일러 플레이트 자체는 자주 반복, 중복되는 것을 뜻함(부정적 의미)

그리고 보일러 플레이트 코드란 이런 현상을 없애주고 자동화해주는 좋은 의미로 쓰임.

참고 : 

https://web-front-end.tistory.com/27

객체 = 구현할 대상 (추상적인 말)

클래스 = 구현할 대상의 설계도

인스턴스 = 클래스를 가지고 구현된 실체(new 로 만든 것)

정도로 구분하자

객체는 구현할 대상이므로 좀 추상적인거고, 클래스와 인스턴스를 포함하는 용어다.

예를들어 회의할때,

우리가 어떤 프로그램을 만들기 위해서, 어떤 상태를 가지고 어떤 기능을 하는 객체가 필요합니다. 그리고 이 객체를 위해 클래스 설계는 어떻게 되어야 합니다.

이 코드를 보면 이 인스턴스(실체화 된 것)가 파라미터로 넘어갑니다. (이때 인스턴스 대신에 객체라고 혼용하는 경우도 많은데 앞으로 구분하는게 좋을듯!)

https://cerulean85.tistory.com/149

1. SRP( Single Responsibility Principle ), 단일 책임 원칙

• 계산기라는 class가 있음. 더하기 빼기 곱하기 나누기의 기능을 가짐.
• 알람 울리는 기능이 필요해짐
• 계산기 클래스 자체에 알람 메쏘드를 넣지 말라

2. OCP ( Open-Closed Principle ), 개방-폐쇄 원칙 : 코드가 추가될때, 기존코드를 건들지 말라

• 걍 디자인패턴의 strategy pattern 임
• 사자, 호랑이, 오리 클래스가 있을 때, 울음소리라는 공통된 기능을 추상화하여 인터페이스로 두고, 얘를 상속받자

3. LSP ( Liskov Substitution Principle ), 리스코프 치환 원칙

• 상위 클래스에서 이미 구현된 메쏘드를 재 오버라이딩 하지 말라
• 왜냐면 상위클래스 형의 변수로 접근하게 되면, 오류가 발생하면 찾기가 빡새짐
•  - ex) class A ,  class B extends A     A b = new B();  b.methodcall();  이렇게 사용시 오류발생할 확률이 큼

4. ISP ( Interface Segregation Principle ), 인터페이스 분리 원칙

• 사용하지 않는 인터페이스는 구현하지 말라 = 인터페이스에 이것저것 때려박지 말라
• ex ) phone interface에 call sms game 등 메쏘드가 필요로하면, 이걸 하나로 때려 박지 말고 call interface, sms interface, game interface로 나눠서 해라(이래야지 기능이 추가될때 기존코드를 건드리지 않음)

5. DIP ( Dependency Inversion Principle ), 의존 역전 원칙

• 객체들이 정보를 주고 받을때는, 어쩔수 없이 의존관계가 형성된다. 이때 파라미터를 추상화된 인터페이스나 abstract 클래스를 쓰자는것
• ex) callMethod(클래스타입) -> callMethod(인터페이스나, 추상클래스 타입)  = 추상성이 낮은 클래스보다 추상성이 높은 클래스와 의존관계를 둬라

기가막힌 곳 출처 : https://victorydntmd.tistory.com/291

클라이언트가(클래스) 서버(멤버변수)에 의존관계를 갖고있고, 서버를 클라이언트에서 직접 생성하면 ocp원칙이 깨진다. 왜냐하면 다른 서버를 바꾸려고 할때, 클라이언트의 소스를 바꿔야 하므로. 그래서 OCP가 깨지는 것이고, 이를 해결하기 위해선 별도의 조립, 설정자가 필요한 것이다.

그리고 저 행위를 해 주는 것이 스프링이 해주는 것이다.(그냥 쉽게 밖에서 IOC컨테이너에 있는 빈으로 주입(DI) 시키는것 생각하면 됨.)

https://joooootopia.tistory.com/13