"안녕하세요, 아미고! 저는 오늘 강의를 캡슐화 에 바치고 싶습니다 . 당신은 이미 그것이 무엇인지에 대한 일반적인 생각을 가지고 있습니다."
캡슐화의 장점은 무엇입니까? 여러 가지가 있지만 내 생각에 가장 중요한 네 가지를 지적하겠습니다.
1) 유효한 내부 상태.
프로그램에는 동일한 개체와 상호 작용하는 여러 클래스가 있는 경우가 많습니다. 개체의 내부 데이터와 동시에 상호 작용함으로써 개체의 데이터 무결성을 위반하여 개체가 올바르게 작동하지 않도록 할 수 있습니다.
따라서 개체는 내부 데이터에 대한 모든 변경 사항을 추적해야 합니다. 더 나아가 이러한 변경 사항을 적용해야 합니다.
일부 클래스 변수가 다른 클래스에 의해 변경되는 것을 원하지 않으면 해당 변수를 private 로 선언합니다 . 즉, 해당 클래스의 메서드만 액세스할 수 있습니다. 변수가 다른 클래스에 대해 읽기 전용이 되도록 하려면 이러한 변수에 public getter를 추가합니다.
예를 들어 컬렉션에 얼마나 많은 요소가 있는지 모든 사람이 알기를 원할 수 있지만 아무도 우리의 허락 없이 변경할 수 없어야 합니다. 이 경우에는 private int count 변수 와 public getCount() 메서드를 선언합니다 .
적절한 캡슐화 는 다른 클래스가 우리 클래스의 내부 데이터에 직접 액세스할 수 없도록 보장하므로 우리가 그들의 작업을 제어할 수 없는 상태에서 데이터를 변경할 수 없습니다. 변경될 변수가 포함된 클래스의 메서드를 호출해야 합니다.
다른 프로그래머가 귀하(또는 귀하의 클래스)에게 가장 안전한 방식이 아니라 항상 자신에게 가장 편리한 방식으로 귀하의 클래스를 사용할 것이라고 가정하는 것이 가장 좋습니다. 이것은 버그의 원인이며 버그를 방지하는 방법입니다.
2) 파라미터 확인.
때로는 클래스의 메소드에 전달된 매개변수를 확인해야 합니다. 예를 들어 "사람"을 나타내는 클래스가 있고 해당 클래스의 생년월일을 지정할 수 있다고 가정합니다. 전달된 모든 데이터가 프로그램의 논리 및 클래스의 논리와 일치하는지 확인해야 합니다. 예를 들어, 13번째 달, 2월 30일 등이 없습니다.
"생년월일을 2월 30일로 표시하는 이유는 무엇입니까?"
"음, 우선 데이터 입력 오류의 결과일 수 있습니다."
둘째, 프로그램이 시계처럼 작동하기 전에 많은 버그가 있을 수 있습니다. 예를 들어 이런 일이 일어날 수 있습니다.
프로그래머는 모레 생일을 가진 사람을 결정하는 코드를 작성합니다. 오늘이 3월 3일이라고 가정해 보겠습니다. 이 프로그램은 현재 날짜에 2를 더하고 3월 5일에 태어난 모든 사람을 찾습니다.
그러나 3월 30일이 되면 프로그램은 3월 32일이 없기 때문에 아무도 찾지 않습니다. 메소드가 매개변수 검사를 수행할 때 프로그램의 버그가 훨씬 적습니다.
"ArrayList를 연구했을 때 그 코드를 살펴보았고 인덱스 매개변수가 0보다 크거나 같고 배열의 길이보다 작은지 확인하기 위해 get 및 set 메서드를 확인했습니다. 코드는 오류를 던질 것입니다. 배열에 인덱스에 해당하는 요소가 없으면 예외입니다.
"그래, 그게 고전적인 입력 확인이야. "
3) 클래스 내에서 코드를 변경할 때 버그가 적습니다.
거대한 프로젝트의 일부로 정말 유용한 클래스를 작성했다고 가정해 보겠습니다. 모두가 그것을 너무 좋아해서 다른 프로그래머들이 그들 자신의 코드에서 수백 곳에서 그것을 사용하기 시작했습니다.
수업이 너무 유용해서 개선하기로 결정했습니다. 그러나 클래스에서 메서드를 제거하면 수십 명의 다른 프로그래머의 코드가 더 이상 컴파일되지 않습니다. 그들은 신속하게 코드를 다시 작성해야 합니다. 재작성 횟수가 많을수록 버그가 발생할 가능성이 높아집니다. 빌드를 정기적으로 깨뜨리면 미움을 받게 됩니다.
그러나 비공개로 표시된 메서드를 변경하면 이러한 메서드가 어디에서도 다른 사람의 코드에 의해 호출되지 않는다는 것을 알 수 있습니다. 다시 작성할 수 있고 매개변수의 수와 유형을 변경할 수 있으며 종속 코드는 계속 작동합니다. 또는 적어도 여전히 컴파일됩니다.
4) 다른 개체가 우리 개체와 상호 작용하는 방식을 정의합니다.
개체에 대해 수행할 수 있는 작업을 제한할 수 있습니다. 예를 들어, 프로젝트의 여러 위치에서 동시에 생성되더라도 클래스의 인스턴스 하나만 생성되기를 원할 수 있습니다. 그리고 캡슐화를 사용하여 이를 달성할 수 있습니다.
캡슐화를 사용하면 추가적인 이점이 될 수 있는 추가 제한 사항을 적용할 수 있습니다 . 예를 들어 String 클래스는 변경할 수 없는 개체로 구현됩니다. String 클래스의 인스턴스는 생성과 소멸 사이에 변경할 수 없습니다. String 클래스의 모든 메서드(remove, substring, ...)는 새 문자열을 반환하며 호출된 객체를 변경하지 않습니다.
"이런 암소. 그래서 그런 거야."
"캡슐화가 흥미롭습니다."
"나는 동의한다."
GO TO FULL VERSION