모든 주요 OOP 기능을 잃지 않고 OOP에서 불변성을 실제로 사용할 수 있습니까?
왜 그런지 모르겠다. 어쨌든 Java 8이 모든 기능을 갖추기 전에 몇 년 동안 해왔습니다. 현에 대해 들어 본 적이 있습니까? 시작 이후로 좋고 불변합니다.
- 목록, 맵 등과 같은 지속적인 (기능적 의미에서) 데이터 구조가 필요합니다.
모두 함께 필요했습니다. 내가 읽는 동안 컬렉션을 변경했기 때문에 반복자를 무효화하는 것은 무례합니다.
- 상호 참조 (예 : 자식이 부모를 참조하는 동안 자식을 참조하는 트리 노드)를 사용하는 것은 매우 불편하므로 상호 참조를 전혀 사용하지 않으므로 데이터 구조와 코드의 기능이 향상됩니다.
순환 참조는 특별한 종류의 지옥입니다. 불변성은 당신을 구하지 못합니다.
- 상속은 의미가 없어지고 대신 작곡을 사용하기 시작합니다.
글쎄, 나는 너와 함께 있지만 불변성과 어떤 관계가 있는지 보지 못합니다. 내가 작곡을 좋아하는 이유는 동적 전략 패턴을 좋아하기 때문이 아니라 추상화 수준을 변경할 수 있기 때문입니다.
- 캡슐화와 같은 OOP의 전체 기본 아이디어가 무너지기 시작하고 객체가 함수처럼 보이기 시작합니다.
"캡슐화와 같은 OOP"에 대한 당신의 생각이 무엇인지 생각하기 위해 떨었습니다. 게터와 세터와 관련이 있다면 캡슐화가 아닌 캡슐화를 중지하십시오. 그것은 결코 없었다. 수동 Aspect 지향 프로그래밍입니다. 유효성을 검사하고 중단 점을 놓을 수있는 기회는 좋지만 캡슐화는 아닙니다. 캡슐화는 내부에서 무슨 일이 일어나고 있는지 알거나 돌보지 않을 권리를 보존합니다.
객체는 함수처럼 보일 것입니다. 그들은 기능의 가방입니다. 그것들은 함께 움직여서 서로를 재정의하는 기능의 가방입니다.
현재 함수형 프로그래밍이 유행하고 있으며 사람들은 OOP에 대해 약간의 오해를 쏟고있다. 이것이 OOP의 끝이라고 믿도록 혼동하지 마십시오. 기능과 OOP는 아주 잘 어울릴 수 있습니다.
정말 그렇습니다. Dykstra는 우리 goto에게 유해하다고 말했기 때문에 공식적으로 구조화 된 프로그래밍을 만들었습니다. 마찬가지로,이 두 패러다임은 이러한 귀찮은 일을 자연스럽게하는 데 따른 함정을 피하면서 일을 수행 할 수있는 방법을 찾는 것입니다.
당신에게 뭔가를 보여 드리겠습니다 :
F N (X)
그것은 기능입니다. 실제로는 연속 함수입니다.
f 1 (x)
f 2 (x)
...
f n (x)
우리가 OOP 언어로 어떻게 그것을 표현하는지 맞춰보세요?
n.f(x)
그 n구현은 어떤 구현 f이 사용 되는지를 선택 하지 않으며 그 함수에 사용 된 상수 중 일부가 무엇인지 결정합니다 (솔직히 같은 것을 의미합니다). 예를 들면 다음과 같습니다.
f 1 (x) = x + 1
f 2 (x) = x + 2
클로저가 제공하는 것과 같은 것입니다. 클로저가 둘러싸는 범위를 참조하는 경우 객체 메서드는 인스턴스 상태를 나타냅니다. 객체는 클로저를 더 잘 수행 할 수 있습니다. 클로저는 다른 함수에서 반환 된 단일 함수입니다. 생성자는 전체 함수 백에 대한 참조를 리턴합니다.
g 1 (x) = x 2 + 1
g 2 (x) = x 2 + 2
그렇습니다.
n.g(x)
f와 g는 함께 바뀌고 함께 움직이는 함수입니다. 그래서 우리는 그것들을 같은 가방에 넣습니다. 이것이 바로 물체입니다. n상수 (불변)를 유지 하면 호출 할 때 수행 할 작업을보다 쉽게 예측할 수 있습니다.
이제는 구조 일뿐입니다. 내가 OOP에 대해 생각하는 방식은 다른 작은 것들과 대화하는 작은 것들입니다. 희망적으로 작은 것들의 작은 선택된 그룹에. 코딩 할 때 나는 그 자체를 객체라고 생각합니다. 나는 물건의 관점에서 사물을 본다. 그리고 나는 게 으르려고 노력하여 물건을 과도하게 사용하지 않습니다. 나는 간단한 메시지를 받고 약간의 작업을하며 나의 가장 친한 친구에게 간단한 메시지를 보냅니다. 내가 그 물체를 다 마치면 다른 물체로 뛰어 들어 그것의 관점에서 사물을 본다.
수업 책임 카드는 저에게 그런 식으로 생각하도록 가르치는 최초의 사람이었습니다. 남자 나는 그때 그들에 대해 혼란 스러웠지만 오늘날에도 여전히 관련이 없다면 망할 것입니다.
ChessBoard를 불변의 체스 조각 (확장 추상 클래스 Piece)의 불변 컬렉션으로합시다. OOP 관점에서, 피스는 보드의 위치에서 유효한 움직임을 생성합니다. 그러나 움직임을 생성하려면 보드에 대한 참조가 필요하지만 보드는 해당 참조에 대한 참조가 필요합니다.
아가! 불필요한 순환 참조로 다시.
어떻습니까 : A ChessBoardDataStructure는 xy 코드를 조각 참조로 바꿉니다. 그 조각들은 x, y 및 특정 방법을 사용 ChessBoardDataStructure하여 새로운 sking spanking 브랜드 모음으로 ChessBoardDataStructure만듭니다. 그런 다음 최선의 움직임을 선택할 수있는 것으로 밀어 넣습니다. 이제는 ChessBoardDataStructure불변이 될 수 있으며 조각도 마찬가지입니다. 이런 식으로 메모리에 하나의 흰색 폰이 있습니다. 올바른 xy 위치에는 여러 참조가 있습니다. 객체 지향, 기능 및 불변.
잠깐, 이미 체스 얘기 안 했어?