추상화 :불필요한 부분을 생략하고 가장 핵심이 되는 즉 가장 중요한 것만 중점을 두고 개략화 하는 것.
캡슐화 : 데이터와 데이터 처리하는 함수를 하나로 묶으므로 인해 변경이나 오류 발생 시 파급 효과과 적고 캡슐화된 객체들의 재사용이 용이함.
상속 : 이미 부모에게 정의된 속성과 함수를 하위클래스인 자식이 물려받아 함수를 재정의 하지 않고 자신의 속성 즉 자식의 입맛대로 정의하도록 하는 코드의 반복을 줄이고 재사용이 가능하다는 점이 있다.(Abstract)
다형성 : 상속과 비슷하지만 실제 구현부분이 작성이 안된 인터페이스를 갖고 있다. 이 Interface들을 갖는 각 클래스들은 이 구현부분을 실제로 작성하여 서로다른 기능을 할 수있게 된다. 서로다른 전혀 연관된 일 보다는 같은 목표를 두고 다르게 도달하는 방식이라고 이해하면 좋을 것 같다. 이렇게 하여 실행 시점에 유연하게 변경할 수 있다는 큰 장점으로 실질적인 구현 기능을 유연하게 변경 가능하다.
객체지향 프로그래밍이란
명령어들의 모임이 아닌 독립된 단위(객체)들의 모임이다. 객체는 메시지를 주고받으며 데이터를 처리한다 -> 서로 다른 객체들 끼리 협력하여 데이터를 처리한다.
객체지향 프로그래밍은 프로그램을 유연하고 변경이 용이하여 대규모 프로젝트 소프트웨어에 많은 토대가 되고있다.
지금까지 일반 프로그래밍 언어에서 배워온 관점은 클라이언트가 없는 상황에서의 일반적인 객체의 쓰임을 주먹구구식으로 익혀온것 같다. 그 속안에있는 뜻은 전혀 모른체 서로 다른 관계의 처리부분에만 집중했었던 것이다.
실질적으로 보면 클라이언트 (사용자) 와 서버관계에서 이 두 부분(클라이언트:사용자) 는 서로 협력 관계를 가진다.
클라이언트의 요청에 대한 서버는 응답을 한다.
클린코드의 5원칙 ( 파급효과 즉 변경의 범위가 넓어 질 수록 좋지 못한 코드이다)
Single responsibility principle : 파급효과 즉 변경의 범위가 넓어 질 수록 좋지 못한 코드이다
Open / Closed principle : 확장은 열려있고 ,변경은 닫혀있어야 한다.(확장은 용이하게 변경은 빈번하게 아닌 적게 만든다) --> 구현 객체를 변경하려면 코드를 변경하는 부분이 꼭 있다. OCP이 원칙을 위배할 수밖에 없다.
Liskov substitution principle : 단순히 컴파일 부분을 넘어서는 것만이 아닌 해당 규약에 맞게 해야한다.
Interface segregation principle : 구분 가능한 인터페이스를 설계해야 독립적으로 나누어 보는 것이 나중에 더 간단하다.(확장을 고려하여)
Dependency inversion principle : 추상화에 의존하고 구체화는 과감히 버린다. 특정 한사람을 위한 것이 아닌 공용을 위해서 만들어야 변경이 빈번하지 않게 되고 확장이 용이해진다. -> 실제 구현 부분에 의존하는 코드의 변경을 자동으로 할 수 있는 그러한 방법은 어떤 다른 내장된 기술이 있을 것 같다.
OCP|DIP 원칙에 위배되는 부분에서 framework가 이 둘을 위배하지 않도록 도와주는 기술들을 지원을 해준다.
즉 코드의 변경없이 기능 확장이 가능하다는 것이다.
깨달은
구체적인것이 나오기 까지는 얼마나 시간을 걸리는지 정확히 알 수 없다. 하지만 무엇을 해야 하는 시기이면서 무엇을 할지 틀이 정해졌다면 핵심에 중점을 두고, 멈추지 말고 (틀을 형성하여)추상적으로 접근하는 것을 시작으로 점점 구체화 시키고 확장해 가는 것이 객체지향 프로그래밍 방식이다.
댓글