[edu] what is oop? (객체지향프로그래밍)

[abstract: 추상화]

현실 세계에 혹은 어떠한 개념이나 대상에서 원하는 특징, 속성(attribute) 을

뽑아 내는 과정.

예를 들어 자동차라는 프로그램을 만든다고 가정하자 

현실세계의 자동차에는 무한대에 가까운 특징이나 속성이 있다.

예를 들어서 자동차 표면의 미세한 기스나 먼지, 유리에 기스도 무한대에 가깝게 있을 것이다.

분자, 원자 단위의 정보들이 있지만 그것들은 필요가 없다.

추상화 과정을 원하는 모델링에 필요한 요소들만 추출하면 된다.

[variable]

모델명, 제조사, 배기량, 현재연료량, 현재속도, 최고속도

[behavior]

엑셀, 브레이크, 라이트 턴 온/오프, 핸들 돌리기

추상화로 클래스를 정의하면 그것으로 

클래스를 실체화 시키면 인스턴스라고 합니다.

인스턴스를 통해서 클래스의 변수나 함수 같은 

속성(attribute)에 접근 할 수 있습니다. 

[class vs object]

클래스는 설계도, 객체는 설계도로 구현한 모든 대상을 의미한다.

[object vs instance]

클래스 타입으로 선언되었을 때 객체라고 부르고, 그 객체가 메모리에 할당 되어 실제 사용될 때 인스턴스라고 부른다.

객체는 현실세계에 가깝고 인스턴스는 소프트웨어 세계에 가깝다.

객체는 '실체' 인스턴스는 '관계'에 초점을 맞춘다.

객체를 클래스의 인스턴스 라고도 부른다.

객체와 인스턴스를 엄격하게 나누긴 어렵다.

[inheritance: 상속]

예를 들어서 동물원이라는 프로그램을 만든다고 하자

사자, 호랑이, 토끼, 늑대, 여우, 코끼리, 염소, 고릴라 등등..

굉장히 많은 동물들을 추상화 작업을 해야 한다.

여러 동물을 추상화 하던중에 어떠한 특징을 발견하였다.

바로 공통된 특징들이 존재 하였다.

먹기, 잠자기, 체중, 성별, 나이 등등

이것들은 어떤 특정한 동물의 특징이 아니라 

동물자체의 특징으로 볼수 있다.

그렇다면 동물이라는 클래스를 추상화하고 

사자, 호랑이, 토끼, 늑대 등 동물들은 이것의 개념을 상속 받을 수 있다.

그러면 상속받는 하위 클래스는 동물의 특징이 아닌 자신만의 

특징만 클래스에 추상화 할수 있다.

[encapsulation: 캡슐화]

높은 응집력 낮은 결합력

연관이 높은 속성(attribute)을 클래스 안에 모아 둔다.

이것은 하나의 클래스에 대한 연관이 높은 속성들간의 응집력을 높인다.

[cohesion: 응집도]

- 프로그램의 한 요소가 해당 기능을 수행하기 위해 얼마만큼의 연관된 책임과 아이디어가 뭉쳐있는지를 나타내는 정도.

- 일반적으로 한 요소가 특정 목적을 위해 밀접하게 연관된 기능들이 모여서 구현되어 있고,

- 응집도가 높으면 프로그램을 쉽게 이해할 수 있고 유지보수 성이 높아진다.

[낮은 응집도의 문제]

- 이해하기 힘들다

- 따로 재사용하기 힘들다

- 유지보수하기 힘들다.

- 다른 클래스의 변화가 민감하다.(다른 클래스에 의존적일수 있다.)

[coupling: 결합도]

- 코드의 한 요소가 다른 것과 얼마나 강력하게 연결되어 있는지, 또한 얼마나 의존족인지 나타내는 정도

- 요소가 결함도가 낮다는 것은 다른 요소들과 관계를 그다지 맺지 않은 상태를 의미한다.

[높은 결합도의 문제]

- 연관된 다른 클래스가 변경되면 같이 변경해야한다.

- 수정하려는 클래스를 이해하기 위해 연관된 다른 클래스를 함께 분석해야한다.

- 해당 코드를 다른 프로그램에서 클래스를 재사용하기 힘들다.

[예시]

개라는 클래스를 추상화 하고 바둑이라는 인스턴스를 생성하였다.

바둑이의 체중을 불리기 위해서 주인은 바둑이라는 인스턴스의 체중이라는 변수에 접근했다.

주인 클래스의 홍길동 인스턴스에서 바둑이의 체중에 직접 접근을 해서 변경하였다.

만약 바둑이의 체중을 변경해야 하는 코드라면 

개 클래스 안에 있어야 맞다. 

그래야 응집력이 높은 코드이고 결합도가 낮다.

개 클래스 안에 먹기 라는 메소드를 만들어서 실행해야 할것이다.

[polymorphism: 다형성]

육식동물이라는 클래스를 만들고

사자, 호랑이, 늑대, 곰 이 이것을 상속 받았다.

육식동물에는 사냥 이라는 특징이 있지만

하위 클래스들은 이것들이 모두 형태가 다릅니다.

이것이 다형성에 오버라이딩 이라고 합니다.

[overriding: 오버라이딩]

부모클래스에서 정의된 메소드를 자식클래스에서 새롭게 정의하는 것을 말한다.

[overloading: 오버로딩]

같은 클래스안에 동일 이름 메소드들이 여러가지 있게 한다.

단 인자의 개수나 타입들은 달라야 하고 반환값은 달라도 되고 같아도 된다.

(파이썬은 메소드 오버로딩이 없다.)

[객체지향의 오해]

oop 가 아닌것들은 무엇인가?

non-oop 에도 존재하는데 oop 의 특징처럼 말해지는 것들이다.

oop 는 실세계 real world 를 모델링 하는 것이다?

oop 는 실세계를 모델링하기 위해 추상화 abstraction 을 사용하는 프로그래밍 패러다임이다.

더 나은 도메인 분석과 시스템 디자인의 통합을 제공함으로써 실세계 모델링을 더 잘 지원한다.

oop 가 다른 방법론들 보다 실세계 모델링을 더 잘 지원한다는 것은 쓰레기같은 말입니다.

 모든 컴퓨터 프로그램은 프로세스를 모델링하는 방법을 찾는 것입니다. 

모델이 잘 못되었다면 소프트웨어도 잘못 됩니다.

개념적 모델은 실세계의 분석으로 만들어 집니다. 

그리고 컴퓨터 소프트웨어는 전적으로 개념적 모델에 기반합니다. 

oop 는 더 잘 모델링하는 것을 보장하지 않습니다.

모델의 구현방법이 약간 다를 뿐입니다.

abstraction 또한 해석해야하는 용어이고 잘못해석되는 용어입니다. 

고객에게 필요한 x,y,z 의 기능이 없는 소프트웨어가 만들어지는 경우에서

oop 라고 이러한 경우를 줄일 수 있는 요소는 없습니다.

oop에 의해 실세계가 모델로 바로 매핑된다는 것에 모든 사람들이 동의하지 않습니다.

oop 는 코드 재사용을 위한 것이다?

객체지향시스템은 코드를 재사용 함으로써 생산성을 증대시키고, 품질을 향상시키며,

 비용을 축소시키는 것을 약속한다.

쓰레기 같은 말입니다. 이것은 코드 재사용이 non-oop 에서는 불가능하고 oop 에서만 가능하다는 의미를 내포하고 있습니다.

코드 재사용은 코드를 어떻게 작성하느냐에 달려 있는 것이지, oop가 코드 재사용을 보장하는 것은 아닙니다.

non-oop 언어로도 재사용 가능한 라이브러리를 작성하는 것이 가능하고 oop 언어로도 재사용 불가 코드가 만들어 질수 있습니다.

어떤 언어에서 같은 코드 클록이 100군데 이상 중복되는 것은 언어능력의 문제가 아닙니다.

또한 어떤 언어로도 코드 블록을 재사용 가능한 라이브러리로 만들고 100군데에서 호출하게 할 수 있습니다.

oop 는 모듈화에 대한 것이다?

어떤 오브젝트에 대한 소스코드는 다른 오브젝트 코드와 별개로 작성되고 관리되어질 수 있다. 한번 만들어지면 시스템 안에서 쉽게 전달 할 수 있다.

모듈화 프로그래밍은 non-oop 언어에도 수년동안 존재해 왔습니다. 

그래서 이 논재는 객체지향이 비 객체지향보다 낮다는 설명으로 쓰일수 없습니다.

모든 언어는 하나의 어플리케이션 소스코드를 한개의 파일에 집어넣을 수 있습니다.

또한 여러개의 작은 모듈로 나누어서 모듈 별로 파일에 넣고, 유지보수하고, 컴파일 할 수 있습니다.

게다가 여러개의 클래스로 구성된 어떤 소프트웨어는 자동적으로 모듈화 됩니다. 중요한 요소는 모듈 또는 클래스를 잘 디자인 하는겁니다. 

oop 는 플러그를 가능하게 하는 것이다.

특정 오브젝트가 문제가 있다고 밝혀지면, 여러분은 어플리케이션에서 그 오브젝트를 간단하게 제거하고 다른 오브젝트를 플러그 하듯이 대체할 수 있다. 이는 실세계와 유사하다, 타이어가 펑크나면 자동차 전체가 아니라 타이터만 교체하면 된다.

이것은 다른 모듈을 손볼 필요없이 개개의 모듈이 독립적으로 수정되고 컴파일 되고 삽입될 수 있다고 말하는 

모듈화의 경우와 같다.

oop 는 정보 은닉에 대한 것이다.

객체의 인터페이스와만 상호작용함으로써 내부 구현은 바깥 세상으로 부터 감추어 질수 있다.

첫 부분, 여기서 설명하는 것은 '구현'의 은닉이지 '정보'의 은닉이 아니다.

어떤 사람들은 무의식적으로 객체의 데이터가 포함된다고 가정합니다. 

다시말해 API 뒤로 코드를 감춘다는 것은 뷰로 부터 감춘다는 것이지 

객체로부터 데이터를 감춘다는 말이 아닙니다.

두번째 부분, 구현 은닉은 oop 의 목적이 아닙니다. 이것은 캡슐화의 부산물 입니다.

바깥세상은 오브젝트의 메소드 이름만을 볼 수 있습니다. 메소드 뒤의 코드를 볼 수 있는 것이 아닙니다.

세번째 부분, 구현 은닉은 oop 만의 특별한 것이 아닙니다. 

인터페이스를 가진 80년대에 작성된 상업용 COBOL 패키지를 기업합니다. 

OOP 는 메세지 전달에 대한 것이다.

메시지 전달이란 한 객체에서 다른 객체로 데이터를 전달하거나, 다른 객체의 메소드를 실행시키는 것이다.

객체지향 언어에서 객체(인스턴스)가 메소드를 실행시키는 것은 비객체지향 언어에서의 함수나 메소드를 실행시키는 것은 "메세지 전달 message passing" 이 아니라 "호출 calling" 이라고 부릅니다.

사실 몇몇 언어에서는 서브루틴을 실행시키기 위하여 "호출" 이라고 부르는 단어가 필요합니다.

[non-oop] 

result = function(arg1, age2 ...)

[oop]

result = object->function(arg1, age2 ...)

각각의 실행의 결과는 정확하게 동일합니다. 통제권은 피 호출자로 넘어가고 호출자는 기다립니다.

통제권은 피호출자가 종료될때까지 반환되지 않습니다.

메시징 소프트웨어와 완벽하게 다르다고 할 수 있습니다.

첫번째로 메시징 소프트웨어는 한 프로세스에서 다른 프로세스로 메시지를 전달하는 것을 허용합니다.

같은 프로세스에서 다른 모듈로의 메시지 전달이 아닙니다.

같은 어플리케이션의 한 non-modal 폼에서 다른 non-modal 폼으로 메시지를 전달하는 것이었습니다.

이것은 오로지 분리된 sendMessage() 함수와 수신 모듈에서의 수신되는 메시지를 처리하기 위한 receiveMessage 트리거로써 가능합니다.

수신자가 송신자에게 응답하는 방법은 메시지를 전송하는 방법 이외에는 없습니다.

두번째로 행위(Behavior) 가 전혀 다릅니다.

그것들은 비동기 입니다. 이것은 호출자는 메시지를 큐에 전송하고 다른 프로세스를 처리합니다.

피 호출자가 통제권을 반환하는 것을 기다릴 필요가 없습니다.

E-mail 이 전통적인 메시징시스템의 예 입니다.

메시지큐는 프로세스의 개수와 메시지의 갯수에 제약받지 않습니다. 수신 프로세스는 메시지 큐의 첫번째 메시지를 꺼내고 또 다음 것을 꺼냅니다.

수신자는 메시지를 받자마자 송신자에게 acknowledgement 를 전송합니다. 또는 처리된 메시지를 반환합니다.

메시지 시스템은 acknowledgement 또는 결과를 전송하는 코드를 포함하고 있어야 합니다.

보다시피 객체가 메소드를 활성화 시키는 메커니즘은 비객체지향 함수가 활성화 시키는 것과 정확하게 동일합니다.

메시징 시스템의 메시지 전송과 무관합니다.

OOP 는 책임의 분리에 대한 것이다.

각각의 객체는 구별되는 역할과 책임을 가지고 있는 작은 머신으로 보여질 수 있다.

언어의 문제가 아니라 전적으로 모듈이 어떻게 작성되느냐에 달려 있습니다.

COBOL 과 같은 절차적 언어로도 독립적인 모듈을 작성할 수 있습니다.

반대로 객체지향 언어로도 지극히 종속적인 모듈이 작성될 수 있습니다.

책임분리의 문제는 그 뜻이 정확히 무엇이든지 상관없이 해석하는 사람마다 다릅니다.

어떤 사람은 SELECT, INSERT, UPDATE, DELETE 와 같은 데이터베이스 오퍼레이션이 그를 필요로 하는 객체에 존재해야 한다고 생각하고, 어떤 사람은 그것들을 한데 모은 별도의 객체에(Data Access Object, DAO) 넣어야 한다고 생각합니다.

어떤 프로그래머는 테이블 마다 DAO를 작성해야 한다고 생각하고 어떤 프로그래머는 모든 데이터베이스 테이블을 취급하는 한개의 DAO를 작성해야 한다고 생각합니다.

여러분은 책임들을 분리하기 전에 언어와의 별도의 디자인 결정에 의해 책임을 구별해야만 합니다.

내 모든 경험을 통틀어 "기술의 난이도"에 의해 실패한 단 하나의 프로젝트는 "책임의 분리"에 대한 모든 것을 알고 있다고 생각하는 객체지향 설계 전문가와 함께한 것이었습니다.

그들은 각각의 책임을 가지는 모듈로 나누고, 디자인 패턴을 이용하여 설계하였습니다.

이 결과로 UI 에서 데이터베이스 까지 적어도 10개의 레이어를 가지도록 설계 되었습니다.

이로써 컴포넌트는 필요이상으로 복잡해 졌고 테스트와 디버깅은 완전히 악몽이었습니다.

그 결과 고객의 시간과 비용은 엄청 증가하였습니다.

그 고객은 플러그를 뽑고 전체 프로젝트를 중단하여 손실을 제한하였습니다.

구식의 비객체 방법론으로 한시간도 채 안걸리는 컴포넌트를 최신 유행하는 객체지향 기술로는 10일이 걸렸습니다.

덧붙여서, " 관심이 분리된 Seperation of Concern" 여러개의 클래스/모듈로 자동으로 구성된 소프트웨어는

특정 엔티티에서는 "걱정거리 concern" 로 고려 되어 질 수 있습니다.

중요한 요소는 클래스/모듈 엔티티의 요구사항을 어떻게 잘 취급하는가 입니다.

OOP 는 배우기가 쉽다.

OOP 는 이전의 접근방법보다 배우기가 매우 쉽다. 이 접근방법은 개발과 유지보수를 단순하며 다른 절차적 방법론보다 분석, 코딩, 복잡한 상황의 이해도를 직관적으로 만들어 준다.

마케팅 전략일 뿐입니다. 모든언어/도구/패러다임은 그 가치보다 모든 것이 좋다고 제안됩니다.

무엇을 사용하느냐가 아니라 어떻게 사용하느냐가 중요합니다.

유능한 프로그래머에 의해 사용되는 '구식' 언어는 '신식'언어의 광고되는 생산성보다 몇배는 더 큽니다.

한 사람의 학습 능력은 종종 가르치는 사람과 가르치는 도구에 의해 제한됩니다.

나는 프로젝트를 성공 시키는 것 보다 너무 비효율적이고, 복잡하게 하는 것을 배우는 것을 두려워 합니다.

OOP 를 가능하게 하는 방법은 "단 한가지" 뿐이라고 주장하는 선생님이 너무 많습니다.

나는 이것에 가장 동의하지 않습니다. 나는 소위 전문가라고 하는 사람들의 방법을 무시하고도 비객체 지향 언어로 작성된 것을 성공적으로 객체지향 언어로 마이레이트한 경험이 많습니다.

어떤 사람은 프로시저 함수를 클래스로 감싸는 것만이 OOP가 아니라고 나에게 말 했습니다.

나는 동의하지 않습니다.

그것은 간단합니다. 유일한 트릭은 연결된 함수를 한곳에 모르고(캡슐화라고 말하는), 객체를 관리될 수 있도록 조정합니다.

여러분이 클래스로 할 수 있는 정말 똑똑한 것은 부모 또는 추상 클래스를 상속(Inheritance)를 통하여 수개의 서브클래스로 확장하는 것 입니다.

다형성(Polymorphism)을 이용하여 서로 다른 클래스의 메소드/함수를 사용가능하게 할 수도 있습니다.

나는 함수들이 잘못 혼합된 매우 많은 예제들을 접해 봤습니다.

관계 없는 함수가 한 클래스에 있으면 안됩니다. 상속의 과잉 사용으로 매우 복잡한 계층구조를 가저서 유지보수와 진보가 거의 힘든 경우를 보았습니다.

나는 다른 프로그래머에게 인상적으로 보일 목적 이외로는 볼 수 없는 객체지향의 모든 기능을 사용하여 코드를 더욱 불분명하게 만드는 프로그래머를 본적이 있습니다.

그들은 너무 단순하면 틀렸다고 생각하는 듯 합니다.

아마도 KISS(keep-it-simple, stupid. 단순하게 하란말야. 멍청아!) 원칙을 들어 본적이 없어 보입니다.

oop 는 행위자(actors) 와 행위(actions) 에 대한 것이다.

객체지향 프로그래밍이란 소프트웨어 개발을 행위자와 행위를 코드를 이용하여 분배하고 모듈화 하는 것이다.

이것은 매우 모호하고, 전혀 쓸모 없는 말입니다.

oop 는 늦은 바인딩(late binding) 에 대한 모든 것이다.

'늦은' dlfksms rjtdms (어떤 바이너리를 로드할 지, 어떤 함수를 호출할지) 바인딩을 가능한한 늦추는 결정이다.

컴파일 타임에 바인딩(early) 하기 보다는 호출 될때 바인딩 하는 것이다.

빠르거나 늦게 바인딩 되는 것은 객체지향과 비객체지향 차이와 무관합니다. 

비객체지향 언어도 늦은 바인딩을 지원합니다.

비객체지향 언어가 늦은 바인딩을 지원한다고 해서 마술같이 객체지향으로 바뀌지 않는 것 처럼, 객체지향 언어가 빠른 바인딩을 한다고 해서 비객체지향 언어가 되는 것은 아닙니다.

[객체지향은 무엇인가?]

객체지향 언어의 5가지 특성

1. Object

2. Class

3. Encapsulation

4. Inheritance

5. Polymorphism

클래스는 엔티티의 프라퍼티(데이터)와 그 프로퍼티들에 작동하는 메소드(함수)들을 정의(캡슐화)합니다.

엔티티의 프로퍼티나 메소드는 클래스 바깥에 정의 되어서는 안됩니다.

객체지향이란 무언인가?

여러분이 믿고 싶어하는 것보다 훨씬 단순 합니다. 사람들은 실제의 그들 자신보다 더 영리해 보이기 위해 더욱 복잡한 정의를 사용합니다. 여기에 진짜 정의가 있습니다.

객체지향 프로그래밍이란 캡슐화, 다형성, 상속을 이용하여 코드 재사용을 증가시키고, 유지보수를 감소시키는 장점을 얻기 위해서 객체들을 연결시켜 프로그래밍 하는것

객체지향 프로그래밍을 하기 위해서는 객체지향 언어가 필요합니다.

캡슐화, 상속, 다형성을 지원한다면 객체지향 언어라고 말 할 수 있습니다.

다른 기능들도 지원할 수 있지만 그것들은 그닥 중요하지 않습니다.

이는 개인적인 의견이 아니라 객체지향 용어를 발명한 사람의 의견입니다.

Bjanne Strousrup 은 그의 문서 Why C++ is not just an Object Oriented Programming Language: 섹션 3에서 지금의 널리 사용되는 "객체지향" 이라는 용어를 제시하였습니다.

언어 또는 기술은 다음을 직접 지원 한다면 객체지향이다.

1. 추상화 - 클래스나 객체를 제공한다.

2. 상속 - 이미 존재하는 것으로 부터 새로운 추상화를 만들어 낼 능력을 제공한다.

3. 런타임 다형성 - 수행시간에 바인딩 할수 있는 어떠한 폼을 제공한다.

많은 객체지향 언어들은 나중에 더 많은 기능들을 추가하였고, 몇몇 사람들은 이 부가 기능들을 객체지향을 결정하는 요소라고 생각하지만 전혀 동의하지 않는 부분입니다.

이는 온도조절기나 네비게이션이 없다고 자동차를 자동차가 아니라고 말하는 것과 같습니다.

바퀴가 있다고 해서 자동차라고 말하는 것 또한 틀린것입니다.

바퀴를 가졌다고 모든 것이 차가 되는 것은 아닙니다. 손수레에 바퀴가 있다고 해서 자동차가 되는 것은 아닙니다.

비객체지향 언어에 이미 존재하는 것이기 때문에 "모듈성", "재사용성", "메시징"을 비객체와 객체를 구별하는 기능이 아니라고 말하는 이유는 간단한 이유입니다.

[oop, non-oop 차이]

비객체와 객체의 차이점을 설명하는 가장 좋은 방법은 실제 예제를 보는 것입니다.

다르게 정의됩니다.

함수는 필요한 것을 가진 코드의 블록으로 정의 됩니다. 각각의 함수 이름은 어플리케이션에서 유일해야 합니다.

function fName ($arg1, $arg2) 
// function description
{
    ....
    
    return $result;
    
} // fName

클래스 메소드는 클래스 정의의 경계로써 규정됩니다. 각각의 클래스 이름은 어플리케이션에서 유일해야 합니다.

각각의 클래스는 클래스 내부에서 유일한 이름을 가지는 다수 함수(메소드라고 알려진)들을 가질 수 있습니다.

어플리케이션에서 유일할 필요는 없습니다. 사실 공통의 함수/메소드 이름을 가지는 것은 다형성에서 필요로 하는 공유의 능력을 위해서 입니다.

class cName
{
    function fName ($arg1, $arg2) 
    // function description
    {
        ....
        
        return $result;
        
    } // fName
    
} // cName

접근 방법이 다릅니다.

함수/클래스는 그 정의가 로드되기 전에 접근될 수 있음을 주목해야 합니다.

함수를 호출하는 것은 직접적입니다.

$result = fName($arg1, $arg2);


다수의 다른 복제본을 가지고 있습니다.

함수는 접근되기 전에 인스턴스화 될 필요가 없습니다. 단 한개의 카피본 만이 존재하기 때문입니다.

클래스 메소드는 오브젝트로 인스턴스화 된 후에만 접근될 수 있습니다.

(정적 메소드로 정의된 경우는 제외)

같은 클래스로 서로 이름이 다른 다중의 오브젝트로 인스턴스화 시킬수 있습니다.

$object1 = new cName;
$object2 = new cName;
$object3 = new cName; 

인스턴스화 시키지 않고 정적메소드에 접근할 수 있다 하더라도, non class 함수의 접근보다 나을것이 없습니다.

오브젝트에 의해 실제로 사용되지 않으며 객체지향 프로그래밍의 한 부분으로 고려되는 사항이 아닙니다.

다수의 엔트리 포인트를 가집니다.

함수는 단일의 진입점을 가집니다. 그것은 함수 이름 그 자체입니다.

오브젝트는 여러개의 진입점을 가집니다. 각각의 메소드 이름입니다.

상태관리를 위한 다수의 메소드를 가집니다.

함수는 기본적으로 상태를 가지지 않습니다. 이것은 호출 될 때마다 새로운 실행으로 취급됩니다.

이전 실행과는 아무 연결이 없습니다.

오브젝트는 상태를 가집니다. 각각의 오브젝트 메소드가 호출될 때 마다 오브젝트의 상태가 변경됩니다.

이것은 함수와 클래스 메소드 모두 로컬 변수를 사용한다는 점에서 같은 방시으로 동작합니다.

로컬 변수란 함수나 클래스 메소드의 범위를 넘지 않는다는 것을 뜻합니다.

그리고 실행들 사이에서 저장되지 않는다는 것입니다.

함수가 서로 다른 수행에서 값을 기억할 수 있는 방법은 정적변수를 사용하는 것입니다.

function count () {
    static $count = 0;
    $count++;
    return $count;
}


결론

많은 사람들이 oop의 의미를 서로 다른 단어로 묘사합니다. 문제는 그 단어들이 오역되기 쉽다는 것입니다.

oop 의 창작자가 사용한 단어를 사용할 때 그 단어에 다른 뜻을 적용한다면, 다른 사람은 여러분의 단어를 또 다른 뜻으로 적용합니다.

그것은 원래와 전혀 관계 없는 것으로 끝이 납니다.

객체지향과 비객체지향을 구별하는 데이는 단지 세가지 기능이 있습니다.

이것들은 캡슐화, 상속, 다형성 입니다. 이거 이외에는 다 헛소리 입니다.

객체지향 프로그래밍은 프로그래밍 언어에서 이 기능들을 이용하는 것입니다.

높은 재상용성과 낮은 유지보수 비용은 보장될 수 없습니다.

전적으로 이 기능들을 어떻게 구현하느냐에 달려 있습니다.

몇몇 사람들은 내가 oop 에 대해 너무 단순한 관점을 가젔다고 비난합니다.

KISS 원칙의 오래된 추종자로써 나는 다른 사람들을 가르치기 쉬운 더욱 적절한 관점을 알고 있습니다.