"객체는 클래스의 인스턴스입니다"라고 말합니다. 클래스는 여러 인스턴스를 가질 수 있습니다. 그러나 이러한 인스턴스는 클래스 참조일 뿐입니다. 클래스에는 필드가 있습니다. 필드는 개체의 속성입니다 . 메서드는 개체의 특정 속성 값을 처리하는 엔진의 요소입니다.
내 이해에서 개체는 명명된(또는 번호가 매겨진) 속성 집합입니다. 속성 값은 다양한 대형 블록 메커니즘에 의해 처리됩니다. 기본적으로 같은 것입니다. 다르게 쓰여졌을 뿐입니다. OOP에서 기능은 캡슐화를 위해 분할됩니다. 나에게 - 반대로 - 기능의 통합.
질문을 그래픽 영역으로 번역하면 "CButton" 클래스가 내 Button 요소와 동일합니다. 내 구현에서 이들은 각각 속성 집합인 코어의 세 개체입니다. 클래스에서 이것은 또한 속성(필드), 버튼 메서드의 목록입니다(버튼에 별도로 속하는 메서드는 없습니다. 버튼의 기능은 전역 기능 블록 안에 있습니다). 이 블록에서 버튼은 모든 요소처럼 취급되지만 특정 위치에는 자체 조건과 핸들러가 있습니다. OOP에서 동일한 버튼 기능은 인스턴스를 통해 액세스할 수 있는 클래스에만 캡슐화됩니다.
George, 모든 라이브러리, 모든 솔루션에는 일종의 개념이 있습니다. 다른 사람의 개념을 가지고 그것을 기반으로 내 자신의 개념을 개발하려고 하면 두 개 이상의 개념으로 구축된 시스템이 안정적이지 않기 때문에 개념 충돌이 발생할 수 있습니다. 따라서 혁신적인 것은 처음부터 스스로 개발해야 합니다. 다른 저자의 "일반적인" 오류 및 모순을 처리하지 않기 위해.
피터, 당신은 헛된 논쟁. 아무것도 증명할 수 없습니다. 나는 또한 _Symbol을 사용하는 대신 CSymbolInfo 라이브러리를 연결하고 object.Name() 작성을 제안할 때 프로그래밍에 대한 이 접근 방식을 이해하지 못합니다.
나는 그러한 SB 방법의 사용을 이해하지 못합니다. 예를 들어
//+------------------------------------------------------------------+//| Set the property value "SYMBOL_SELECT" |//+------------------------------------------------------------------+bool CSymbolInfo::Select( constboolselect )
{
return (SymbolSelect(m_name, select ));
}
쓰기가 얼마나 어려운지
SymbolSelect ( "Нужный символ" , включить или выключить );
두 경우 모두 한 줄의 코드만 있습니다.
반면 Artyom은 길을 잃고 아무것도 이해하지 못하고 사용하지 않는 OOP의 가능성을 보여주었습니다.
객체는 클래스 유형으로 변수를 선언하거나 new 연산자를 사용하여 이 클래스의 새 객체를 생성한 경우입니다.
예를 들어 다음과 같은 클래스입니다.
//+------------------------------------------------------------------+class CClass
{
//--- Приватные члены класса. Доступны только в объекте этого классаprivate :
int m_type; // Тип объекта//--- Защищённые члены класса. Доступны в объекте этого класса и его наследникахprotected :
string m_name; // Имя объекта//--- Публичные члены класса. Доступны вездеpublic :
void SetType( constint type) { this .m_type=type; }
int GetType( void ) const { returnthis .m_type; }
void SetName( conststring name) { this .m_name=name; }
string GetName( void ) const { returnthis .m_name; }
};
//+------------------------------------------------------------------+
클래스의 두 멤버(유형 및 이름)만 있습니다. 이것이 그 속성입니다. 그리고 그것은 물건이 아닙니다. 이것은 미래의 대상에 대한 계획, 도면, 프로젝트입니다.
우리는 객체를 생성합니다:
CClass class_obj; // Объявили переменную class_obj с типом класса CClass. Теперь class_obj - это объект
객체와 이에 대한 포인터를 생성합니다.
CClass *class_ptr = new CClass(); // Оператором new создали новый объект класса CClass, и в переменную class_ptr получили на него указатель. // Теперь в памяти сидит объект CClass, и получить к нему доступ можно по этому указателю, // и по этому же указателю обязательно удалить объект по завершении работы оператором delete
내가 말했듯이, OOP에서 객체의 관점은 내 개념보다 더 넓습니다. 균일한 속성 집합을 가진 그래픽 개체만 다루었습니다. OOP는 개체의 개념을 통해 모든 엔터티에 대한 보기를 제공합니다. 모든 엔터티가 개체이기 때문에 이것은 물론 훌륭합니다. 물론 나는 객체 기능의 과도한 캡슐화와 단편화에 반대한다. 왜요? 예, 메커니즘의 효율성이 떨어지기 때문입니다. 그러나 더 넓은 맥락에서 대상을 바라볼 수 있다는 바로 그 가능성이 저를 매료시킵니다.
George, 모든 라이브러리, 모든 솔루션에는 일종의 개념이 있습니다. 다른 사람의 개념을 가지고 그것을 기반으로 내 자신의 개념을 개발하려고 하면 두 개 이상의 개념으로 구축된 시스템이 안정적이지 않기 때문에 개념 충돌이 발생할 수 있습니다. 따라서 혁신적인 것은 처음부터 스스로 개발해야 합니다. 다른 저자의 "일반적인" 오류 및 모순을 처리하지 않기 위해.
7(!) 음표만 있습니다. 얼마나 많은 음악이 그들에 있습니까? 그리고 단 한 명의 작곡가도 붕괴에 대해 생각하지 않습니다. 그는 영혼에서 재생되는 음악을 씁니다. 그는 다른 것을 발명하지 않고 이 7개의 음표를 사용합니다.
객체는 클래스 유형으로 변수를 선언하거나 new 연산자를 사용하여 이 클래스의 새 객체를 생성한 경우입니다.
예를 들어 다음과 같은 클래스입니다.
클래스에는 유형과 이름의 두 멤버만 있습니다. 이것이 그 속성입니다. 그리고 그것은 물건이 아닙니다. 이것은 미래의 대상에 대한 계획, 도면, 프로젝트입니다.
우리는 객체를 생성합니다:
객체와 이에 대한 포인터를 생성합니다.
클래스는 객체에 대한 설명입니다. 좋은. 개체 및 해당 기능의 속성을 포함합니다. 확인. 이 모든 것이 명령되거나 열리거나 보호됩니다.
그런 다음 OBJECT ITSELF가 무대 뒤에 있습니다. 그것은 클래스의 컨텍스트에 있습니다. 이름과 설명의 맥락에서. 즉, OOP에서 Object는 속성의 명명된 복합체(속성뿐만 아니라 기능적 요소 - 메서드)이지만 내 것보다 더 정렬되고 캡슐화됩니다. (그렇게 하면 더 명확해집니다.)
클래스는 객체에 대한 설명입니다. 좋은. 개체 및 해당 기능의 속성을 포함합니다. 확인. 이 모든 것이 명령되거나 열리거나 보호됩니다.
그런 다음 OBJECT ITSELF가 무대 뒤에 있습니다. 그것은 클래스의 컨텍스트에 있습니다. 이름과 설명의 맥락에서. 즉, OOP에서 Object는 속성의 명명된 복합체(속성뿐만 아니라 기능적 요소 - 메서드)이지만 내 것보다 더 정렬되고 캡슐화됩니다. (그렇게 하면 더 명확해집니다.)
모든 것을 이해하려면 책을 읽어야 합니다. 21일 이내에 최소 VC++
MFC를 처음 사용하고 CDialog 기반으로 Windows 응용 프로그램을 만들고 모든 종류의 개체를 만들고 얼마나 쉽게 관리되는지 확인하는 것이 좋습니다.
어쨌든, OOP "Object"에 있는 것은 나에게 도달하지 않습니다.
"객체는 클래스의 인스턴스입니다"라고 말합니다. 클래스는 여러 인스턴스를 가질 수 있습니다. 그러나 이러한 인스턴스는 클래스 참조일 뿐입니다. 클래스에는 필드가 있습니다. 필드는 개체의 속성입니다 . 메서드는 개체의 특정 속성 값을 처리하는 엔진의 요소입니다.
내 이해에서 개체는 명명된(또는 번호가 매겨진) 속성 집합입니다. 속성 값은 다양한 대형 블록 메커니즘에 의해 처리됩니다. 기본적으로 같은 것입니다. 다르게 쓰여졌을 뿐입니다. OOP에서 기능은 캡슐화를 위해 분할됩니다. 나에게 - 반대로 - 기능의 통합.
질문을 그래픽 영역으로 번역하면 "CButton" 클래스가 내 Button 요소와 동일합니다. 내 구현에서 이들은 각각 속성 집합인 코어의 세 개체입니다. 클래스에서 이것은 또한 속성(필드), 버튼 메서드의 목록입니다(버튼에 별도로 속하는 메서드는 없습니다. 버튼의 기능은 전역 기능 블록 안에 있습니다). 이 블록에서 버튼은 모든 요소처럼 취급되지만 특정 위치에는 자체 조건과 핸들러가 있습니다. OOP에서 동일한 버튼 기능은 인스턴스를 통해 액세스할 수 있는 클래스에만 캡슐화됩니다.
George, 모든 라이브러리, 모든 솔루션에는 일종의 개념이 있습니다. 다른 사람의 개념을 가지고 그것을 기반으로 내 자신의 개념을 개발하려고 하면 두 개 이상의 개념으로 구축된 시스템이 안정적이지 않기 때문에 개념 충돌이 발생할 수 있습니다. 따라서 혁신적인 것은 처음부터 스스로 개발해야 합니다. 다른 저자의 "일반적인" 오류 및 모순을 처리하지 않기 위해.
피터, 당신은 헛된 논쟁. 아무것도 증명할 수 없습니다. 나는 또한 _Symbol을 사용하는 대신 CSymbolInfo 라이브러리를 연결하고 object.Name() 작성을 제안할 때 프로그래밍에 대한 이 접근 방식을 이해하지 못합니다.
나는 그러한 SB 방법의 사용을 이해하지 못합니다. 예를 들어
쓰기가 얼마나 어려운지
두 경우 모두 한 줄의 코드만 있습니다.
반면 Artyom은 길을 잃고 아무것도 이해하지 못하고 사용하지 않는 OOP의 가능성을 보여주었습니다.
별로.
여기서는 다르게 설명하겠습니다. 보통 아무도 그렇게 설명하지 않습니다.
모든 프로그래머는 예를 들어 int x 가 무엇인지 알고 있습니다.
이제 int 라는 단어가 클래스의 이름과 같다고 상상해 보십시오. 그는 무엇을 설명합니까? 이게 뭔가요:
1. 정수
2. 메모리에서 4바이트를 차지합니다.
3. 일부 제한 내에서 + - 값을 취합니다. (많으면 충분하다);
그리고 int x 를 쓸 때 ; 그런 다음 int 유형의 객체 x 를 선언합니다. x 는 이미 물리적으로 RAM의 4바이트 필드를 차지합니다.
피터, 당신은 헛된 논쟁. 아무것도 증명할 수 없습니다. 나는 또한 _Symbol을 사용하는 대신 CSymbolInfo 라이브러리를 연결하고 object.Name() 작성을 제안할 때 프로그래밍에 대한 이 접근 방식을 이해하지 못합니다.
나는 그러한 SB 방법의 사용을 이해하지 못합니다. 예를 들어
쓰기가 얼마나 어려운지
두 경우 모두 한 줄의 코드만 있습니다.
반면 Artyom은 길을 잃고 아무것도 이해하지 못하고 사용하지 않는 OOP의 가능성을 보여주었습니다.
의미의 이 버전에서 클래스는 도구, 재료, 원자재 및 공작 기계의 창고입니다. "공장"의 상점과 같은 상속된 클래스의 계층 구조.
피터, 왜 그런 미묘함에 빠지는거야?
클래스는 개체, 해당 속성 및 이러한 속성을 설정하고 액세스하기 위한 메서드에 대한 설명입니다 .
객체는 클래스 유형으로 변수를 선언하거나 new 연산자를 사용하여 이 클래스의 새 객체를 생성한 경우입니다.
예를 들어 다음과 같은 클래스입니다.
클래스의 두 멤버(유형 및 이름)만 있습니다. 이것이 그 속성입니다. 그리고 그것은 물건이 아닙니다. 이것은 미래의 대상에 대한 계획, 도면, 프로젝트입니다.
우리는 객체를 생성합니다:
CClass class_obj; // Объявили переменную class_obj с типом класса CClass. Теперь class_obj - это объект객체와 이에 대한 포인터를 생성합니다.
George, 모든 라이브러리, 모든 솔루션에는 일종의 개념이 있습니다. 다른 사람의 개념을 가지고 그것을 기반으로 내 자신의 개념을 개발하려고 하면 두 개 이상의 개념으로 구축된 시스템이 안정적이지 않기 때문에 개념 충돌이 발생할 수 있습니다. 따라서 혁신적인 것은 처음부터 스스로 개발해야 합니다. 다른 저자의 "일반적인" 오류 및 모순을 처리하지 않기 위해.
7(!) 음표만 있습니다. 얼마나 많은 음악이 그들에 있습니까? 그리고 단 한 명의 작곡가도 붕괴에 대해 생각하지 않습니다. 그는 영혼에서 재생되는 음악을 씁니다. 그는 다른 것을 발명하지 않고 이 7개의 음표를 사용합니다.
피터, 왜 그런 미묘함에 빠지니?
클래스는 개체, 해당 속성 및 이러한 속성을 설정하고 액세스하기 위한 메서드에 대한 설명입니다 .
객체는 클래스 유형으로 변수를 선언하거나 new 연산자를 사용하여 이 클래스의 새 객체를 생성한 경우입니다.
예를 들어 다음과 같은 클래스입니다.
클래스에는 유형과 이름의 두 멤버만 있습니다. 이것이 그 속성입니다. 그리고 그것은 물건이 아닙니다. 이것은 미래의 대상에 대한 계획, 도면, 프로젝트입니다.
우리는 객체를 생성합니다:
객체와 이에 대한 포인터를 생성합니다.
클래스는 객체에 대한 설명입니다. 좋은. 개체 및 해당 기능의 속성을 포함합니다. 확인. 이 모든 것이 명령되거나 열리거나 보호됩니다.
그런 다음 OBJECT ITSELF가 무대 뒤에 있습니다. 그것은 클래스의 컨텍스트에 있습니다. 이름과 설명의 맥락에서. 즉, OOP에서 Object는 속성의 명명된 복합체(속성뿐만 아니라 기능적 요소 - 메서드)이지만 내 것보다 더 정렬되고 캡슐화됩니다. (그렇게 하면 더 명확해집니다.)
나는 그러한 SB 방법의 사용을 이해하지 못합니다. 예를 들어
쓰기가 얼마나 어려운지
OOP의 바로 그 개념은 쓰지 않는 것을 의미합니다 - 메소드의 구현을 알 필요가 없습니다(귀하의 예에서 return(SymbolSelect(m_name,select)))
이 줄 대신 다음을 상상해보십시오.
많은 요청, 다양한 확인 등을 수행해야 합니다. - 자신의 라이브러리를 작성하고 자료 자체를 연구하는 데 시간이 걸립니다.
귀하의 작업은 클래스 형태의 기성 솔루션의 한 가지 방법을 사용하는 것으로 끝납니다. 클래스(객체)의 인스턴스를 만들고 기성품 Select(const bool select) 방법을 사용합니다.
이러한 작업이 더 이상 수행되지 않아야 하는 경우 여유 메모리 = 개체를 파괴합니다.
시장 시계에서 기호를 활성화/비활성화하는 버튼을 표시하는 것으로 작업을 줄이십시오 ---> 자신의 클래스를 만들고 기성품 버튼 클래스와 기성품 CSymbolInfo 클래스를 캡슐화합니다. 과제가 해결되다
OOP 패러다임은 클래스로 무엇을 할 수 있는지에 대한 일반적인 정보만 제공합니다. - CSymbolInfo를 캡슐화하고 싶지 않다면 - 글쎄요, 클래스를 가져오세요.
추신 : "손가락에"라면 OOP의 본질은 구현을 알지 못한 채 작업에 대한 빠른 솔루션입니다.
클래스는 객체에 대한 설명입니다. 좋은. 개체 및 해당 기능의 속성을 포함합니다. 확인. 이 모든 것이 명령되거나 열리거나 보호됩니다.
그런 다음 OBJECT ITSELF가 무대 뒤에 있습니다. 그것은 클래스의 컨텍스트에 있습니다. 이름과 설명의 맥락에서. 즉, OOP에서 Object는 속성의 명명된 복합체(속성뿐만 아니라 기능적 요소 - 메서드)이지만 내 것보다 더 정렬되고 캡슐화됩니다. (그렇게 하면 더 명확해집니다.)
모든 것을 이해하려면 책을 읽어야 합니다. 21일 이내에 최소 VC++
MFC를 처음 사용하고 CDialog 기반으로 Windows 응용 프로그램을 만들고 모든 종류의 개체를 만들고 얼마나 쉽게 관리되는지 확인하는 것이 좋습니다.
그 후, 당신은 당신의 아이디어를 버릴 것입니다. 안타깝게도.