개체가 개체를 나타내야합니까?

함으로써 기업 나는 같은 것을 의미 Product, Motor하는 ParkingLot등 물리적, 심지어 명확한 비 물리적 개념 개체 - 물론 일부 핵심 데이터가 명확하게 개체에 속하는으로, 정의 뭔가, 일부 기능 / 방법 핵심 데이터에서 명확하게 작동합니다.

예를 들어, 나는 Demon실체가 아닌 실체가 아닌 가상의 실체를 가질 수있다.

객체가 메소드의 모음 일 수 있습니까 ? 공통의 목표와 연계되는 일반적인 절차입니다.

예 : 클래스를 호출 할 수 있습니다 MotorOperations또는 MotorActions이 엔터티 없지만, 클래스 내의 메소드는 같은 일을 할 경우,

• getMotorDataFromHTMLForm ()
• getMotorManufacturers ()
• selectMotorFromUserRequirements ($ 요구 사항)
• canMotorCanHandleOperatingConditions ($ conditions)
• computePowerConsumptionForMotor ($ id)

클래스는 일반적으로 객체 중심의 데이터 + 데이터에 대한 작업으로 정의됩니다. 따라서 Motor모터 사양과 관련된 모터 변수가있을 수 있으며 이러한 데이터를 결합하여 무언가를 생성하는 작업이있을 수 있습니다.

내 경우에는 클래스를 통해 전달되는 데이터 + 데이터에 대한 작업이있는 클래스가 있고 클래스 통과 데이터 이외의 "모터 작업"에 대한 데이터 중심이 없습니다.

질문

클래스가 엔티티가없는 객체를 나타낼 수 있습니까? 그렇지 않은 경우 왜 불량 / 불완전 / OOP 중심이 아닌가? OOP와 일치하도록 개념적으로 변경 / 개선해야하는 방법이 있습니까?

아니요 , 개체는 개체를 나타내지 않아도됩니다.

사실, 나는 당신이 물체를 물리적 실체로 생각하는 것을 멈 추면 OOP가 약속 한 이익을 마침내 얻을 때라고 주장합니다.

이것이 가장 좋은 예는 아니지만 커피 메이커 디자인 은 아마도 조명이 켜지 기 시작했을 것입니다.

객체는 메시지에 관한 것입니다. 그들은 책임에 관한 것입니다. 자동차, 사용자 또는 주문에 관한 것이 아닙니다.

나는 우리가 OO를 이런 식으로 가르치는 것을 알고 있지만, MVC, MVVM 또는 MV를 수행하려고 할 때 일이 어디로 가야하는지 알아내는 것이 몇 번의 시도를 거친 후에 명백해집니다. 모델이 말도 안되게 부풀어 오르거나 컨트롤러가 부풀어 오릅니다. 탐색을 위해 Vehicles에 닿는 모든 것이 Vehicle.ext 파일에 있지만 응용 프로그램이 Vehicles에 관한 경우 필연적으로 해당 파일에 3000 줄의 스파게티가 생깁니다.

보낼 새 메시지가 있으면 새 개체가 적어도 하나 이상있을 수 있습니다. 따라서 일련의 메소드에 대한 귀하의 질문에서, 귀하는 메시지 묶음에 대해 잠재적으로 이야기하고 있다고 주장합니다. 그리고 각자 자신의 일이 될 수있는 고유 한 대상이 될 수 있습니다. 그리고 괜찮습니다. 당신이 정말로 정말로 함께해야 할 것들을 나누면 분명해질 것입니다. 그리고 당신은 그것들을 함께 넣습니다. 그러나 OO를 즐기고 싶다면 편의를 위해 모호한 서랍에 모든 방법을 즉시 버리지는 않습니다.

기능 가방에 대해 이야기합시다

객체는 단지 메소드의 모음 일 수 있으며 여전히 OO 일 수 있지만 내 "규칙"은 매우 엄격합니다.

1. 컬렉션에는 단일 책임이 있어야하며 그 책임은 "모터에 물건을 싣는 것"만큼 일반적 일 수 없습니다. 서비스 계층 파사드와 같은 일을 할 수도 있지만 OO 코드를 작성하려고하지 않기 때문에 탐색 / 발견 이유로 게으르다는 것을 심각하게 알고 있습니다.

2. 모든 방법은 일관된 추상화 계층에 있어야합니다. 한 메소드가 Motor 오브젝트를 검색하고 다른 메소드가 Horsepower를 리턴하는 경우, 아마도 너무 멀리 떨어져있을 것입니다.

3. 객체는 동일한 "종류"의 데이터에서 작동해야합니다. 이 객체는 모터에 작동 (시작 / 중지), 크랭크 길이의 작업, 점화 시퀀싱 처리, HTML 형식을 취합니다. 이 데이터는 아마도 객체의 필드 일 수 있으며 응집력이있는 것처럼 보입니다.

나는 일반적으로 변형, 구성을 수행하거나 변경 가능성에 대해 걱정하고 싶지 않을 때 이런 종류의 객체를 만듭니다.

나는 객체 책임에 초점을 맞추면 응집력을 얻게된다. 객체가되기 위해서는 약간의 응집력이 있어야하지만, 객체가되기 위해 어떤 필드 나 많은 행동이 필요하지는 않습니다. 5 가지 모터 방법을 필요로하는 시스템을 구축하고 있다면, 그 일을하는 5 가지 다른 물체로 시작할 것입니다. 공통점을 발견하면 함께 병합하거나 일반적인 "도우미"개체를 사용하기 시작합니다. 그것은 열린 / 닫힌 관심사로 나를 움직입니다.이 비트의 기능을 어떻게 추출하여 특정 파일을 다시 수정할 필요가 없지만 필요한 곳에서 계속 사용할 수 있습니까?

객체는 메시지에 관한 것입니다

필드는 거의 객체에 중요하지 않습니다. 레지스터를 가져오고 설정해도 프로그램 외부의 세계는 바뀌지 않습니다. 다른 개체와 공동 작업하면 작업이 완료됩니다. 그러나 OO의 강점은 추상화를 생성하여 모든 개별 세부 사항을 한 번에 생각할 필요가 없다는 것입니다. 누출되거나 이해가되지 않는 추상화는 문제가 있으므로, 우리는 우리의 정신 모델과 일치하는 객체를 만드는 것에 대해 깊이 생각합니다.

주요 질문 :이 두 물체가 서로 대화해야하는 이유는 무엇입니까?

개체를 사람의 장기로 생각하십시오-기본 목적을 가지고 있으며 관심있는 특정 메시지를받을 때만 동작이 변경됩니다.

횡단 보도에 있고 자동차가 빨리오고있는 시나리오를 상상해보십시오. 뇌의 대상으로 스트레스 요인을 감지합니다. 시상 하부에 코르티코 트로 핀 방출 호르몬을 보내라고 지시합니다. 뇌하수체는 그 메시지를 받고 부 신피질 호르몬을 분비합니다. 부신은 그 메시지를 받고 아드레날린을 만듭니다. 근육이 그 아드레날린 메시지를 받으면 수축합니다. 심장이 같은 메시지를 받으면 더 빨리칩니다. 길 건너편의 단거리 달리기의 복잡한 행동을 시작하는 데 관련된 모든 플레이어 체인이 있으며 중요한 메시지입니다. 뇌 개체는 시상 하부가 경고를 보내도록하는 방법을 알고 있지만 결국에는 동작이 일어날 개체 체인을 모릅니다. 마찬가지로, 심장은 아드레날린이 어디에서 오는지 모릅니다.

따라서이 단순화 된 예에서 부신 개체는 ACTH를 복용하고 아드레날린을 만드는 방법 만 알면됩니다. 이를 수행하기 위해 필드가 필요하지는 않지만 여전히 나에게 객체처럼 보입니다.

이제 우리의 응용 프로그램이 길 건너 스프린트 전용으로 설계된 경우, 뇌하수체와 부신이 필요하지 않을 수 있습니다. 또는 개념적으로 "뇌하수체 모델"로 볼 수있는 것의 작은 부분만을 수행하는 뇌하수체 개체 만 필요합니다. 이러한 개념은 모두 개념적 개체로 존재하지만 소프트웨어이므로 AdrenalineSender 또는 MuscleContractor 등을 만들 수 있으며 모델의 "불완전 성"에 대해 크게 걱정하지 않아도됩니다.

클래스가 엔티티가없는 객체를 나타낼 수 있습니까? 그렇지 않은 경우 왜 불량 / 불완전 / OOP 중심이 아닌가? 변경 / 개선해야 할 방법이 있습니까?

요컨대, 당신은 무엇이든 할 수 있지만,이 특정 시나리오는 OOP 원칙에 위배됩니다 :)

당신이 묘사하는 것을 때때로 "유틸리티"클래스라고 부릅니다. 보통 코드 냄새의 징조입니다. 일부 메소드를 함께 유지하기 위해 클래스를 작성하지 않으려 고합니다.

응용 프로그램의 모든 개체가 모터 나 자동차와 같은 실제 개체에 연결되어 있어야하는 것은 아닙니다. 그것들은 비즈니스 객체입니다. 애플리케이션에서 많은 비즈니스 오브젝트를 사용할 가능성이 있지만 나열된 비즈니스 엔티티와 같이 비즈니스 엔티티의 일부가 아닌 다른 오퍼레이션에 대한 분리가 더 필요합니다.

일반적인 아키텍처 패턴을 살펴 봐야합니다. 그 중 하나는 MVC (Model-View-Controller) 입니다.

MVC를 사용하여 나열된 방법을 배포하려면 다음과 같이하십시오.

수업보기 :

• GetMotorDataFromHTMLForm ()

모델 클래스 (모터 기본) :

• GetMotorManufacturer ()
• CanMotorHandleOperationConditions ()
• 전력 소비량 계산 ()

컨트롤러 클래스 (MotorsController) :

• GetAllMotors ()
• GetMotorById ()
• GetMotorByUserRequirements ()

PHP를 사용하는 것 같습니다. 살펴볼 좋은 MVC 프레임 워크는 Laravel 입니다. 그들의 예에서 그들은 어떤 방법이 속하는지를 잘 보여줍니다.

방법이 속하는 곳을 결정하는 방법에 대한보다 일반적인 또 다른 정보원은 GRASP 및 SOLID 원칙입니다.

클래스가 엔티티가없는 객체를 나타낼 수 있습니까?

할 수있다? 예. 할까요? 아마도 당신이 어떻게 말을하는지가 아닙니다.

실제 객체는 실제 객체를 직접 표현 하지 않을 때 실제로 가장 좋습니다. 현실적이기 때문에 가끔 코드에 잘 매핑됩니다. 그러나 응집력있는 개념 또는 코드 객체를 나타내야합니다. 그들은 하나의 응집력있는 책임을 나타내야합니다.

접선 적으로 관련된 여러 함수를 함께 묶는 것은 OOP 용어의 객체가 아닌 네임 스페이스 또는 모듈입니다. 그것들은 유용 할 수 있지만, 동일하지 않으며, 효과적으로 사용하기 위해서는 다른 종류의 사용법 / 생각이 필요합니다.

클래스는 무언가 를 모델링해야합니다 . 그렇지 않으면 의미가 없습니다. 그러나 모델링되고있는 것은 물리적 인 "것"이 아닐 수도 있습니다. 대신 '실제'가 아니지만 모델링되는 시스템을 제어하는 ​​데 필요한 것을 나타낼 수 있습니다. 예를 들어, 신호등 제어 시스템에는 시스템의 한 부분에서 다른 부분으로 전송되는 신호를 나타내는 일종의 ControlSignal 클래스가있을 수 있습니다. "실제 세계"에서 이러한 신호는 한 상자에서 다른 상자로 와이어를 통해 전송되는 전기 충격으로 구성 될 수 있습니다. "실제"가 아닌 것을 구체적인 대상으로 모델링하는 프로세스를 "통합"이라고합니다.

행운을 빕니다.

아니요. (반대 질문을하기 위해 제목을 편집했습니다!)

예 :

Public class MyRepository
{
    public MyObject GetObject(string id)
    {
        //get data from the DB and build an object
    }
}

또는

Public class MyService
{
    public MyObject3 ProcessData(MyObject1 obj1, MyObject2 obj2)
    {
         //perform a process which is not a sole responsiblity of obj1 or obj2
    }
}

그러나 일반적으로 OOP의 이상적인 이상은

public struct Car
{
    public Wheel[] Wheels;
}

public int CountWheelsOnCar(MyCarStruct car)
{
   return car.Wheels.Length;
}

에

public class Car
{
    private Wheel[] wheels;
    Public int CountWheels()
    {
        return this.wheels.Length;
    }
}

클래스를 코딩 할 때 실제 세계에서 무언가를 시각화하는 것이 도움이되지만 필요하지는 않다고 생각합니다.

실제로 문자 그대로의 방식에 따라 작업하는 많은 객체에는 물리적 인 표현이 전혀 없습니다. 예를 들어 MVC 아키텍처를 고려하십시오. 실제 세계에서는 일반적으로 클래스로 표시되지만 모델 또는 컨트롤러는 없습니다. 세 사람이 함께 무언가를 대표하지만 항상 그런 것은 아니지만 항상 말했듯이 실제로 원한다면 무언가에 적응할 수 있습니다 (그리고 뭔가 도움이 될 것이라고 상상할 수 있습니다! 나는 어떤 방식 으로든 대부분의 물체를 시각화합니다. 당신은 현실 세계에서 본 적이 있습니다).

OO에 대해 배우게 될 이러한 "규칙"은 OO로 생각하는 데 초점을 맞추기위한 지침 일뿐입니다. OO를 매일 코딩하기 위해 일단 사용하면 걱정할 필요는 없습니다.

그런데 OO 자체는 만병 통치약이 아니며 솔루션을 코딩하는 첫 번째 단계에서 전혀 도움이되지 않지만 올바르게 수행하면 코드를 구성하는 것이 정말 환상적인 방법이라고 생각합니다. 나중에 쉽게 이해할 수 있습니다. 유지 관리 가능한 코드 작성은 아마도 소프트웨어 개발에서 가장 어려운 작업 중 하나이며 많은 경우 (진행중인 디버깅 / 유지 관리가 필요한 것) 가장 중요합니다.

개체가 개체를 나타내야합니까?

질문 : 어느 기관이 Logger대표합니까?

은유 적으로-말 그대로.

학생들에게 OOP를 설명 할 때 실제 세계와 유사한 대상을 설명하는 것이 도움이됩니다.

OOP 의 아버지 중 한 명인 Alan Kay 는 다음과 같이 썼습니다.

[...]

그것의 원래 개념은 다음과 같은 부분을 가졌습니다.

• 나는 객체가 생물학적 세포 및 / 또는 네트워크상의 개별 컴퓨터와 같으며 메시지와 만 통신 할 수 있다고 생각했습니다.
• 나는 데이터를 제거하고 싶었다.

[...]

나에게 OOP는 메시징, 로컬 보존 및 보호만을 의미하며

상태 프로세스 숨기기 및 모든 것들의 극단적 인 바인딩.

거의 믿을 수없는 HW 아키텍처. 나는

셀 / 전체 컴퓨터 메타포가 데이터를 제거합니다.

출처

이것으로부터 객체는 다음과 같이 가장 잘 이해됩니다.

• 데이터를 캡슐화 / 숨기기

• 메시지를 통해 다른 객체와 통신

클래스가 엔티티가없는 객체를 나타낼 수 있습니까?

확실히 : 생각 Math

귀하의 예와 관련하여 :

예 : 엔티티가없는 클래스를 MotorOperations 또는 MotorActions라고 할 수 있지만 클래스 내부의 메소드는 다음과 같은 작업을 수행합니다.

• getMotorDataFromHTMLForm ()

• getMotorManufacturers ()

• selectMotorFromUserRequirements ($ 요구 사항)

• canMotorCanHandleOperatingConditions ($ conditions)

• computePowerConsumptionForMotor ($ id)

이러한 방법을 어디에 둘 것인지 결정하려면 다음을 살펴 봐야합니다 responsibilities. 누가 무엇에 대해 책임이 있는지 .

getMotorDataFromHTMLForm ()

이러한 방법의 맥락은 모터 객체를 구성하는 것 입니다. 양식을 통해 검색된 데이터에서 자체를 생성하는 것은 모터 의 책임 이 아닙니다 . 최소한 두 개의 객체가 관련되어 있습니다. 하나는 모터이고 다른 하나는 모터의 제작자입니다 .

getMotorManufacturers ()

그러한 메소드를 작성하는 일반적인 컨텍스트는입니다 service.

selectMotorFromUserRequirements ($ 요구 사항)

이것은 service-context 에서도 사용됩니다.

canMotorCanHandleOperatingConditions ($ conditions)

이것은 motor-object에 대한 질문입니다

computePowerConsumptionForMotor ($ id)

이것 역시 모터 자체에 가장 좋은 질문입니다.

tl; dr

의 은유 objects와 같은 물리적 객체는 도움보다 더 자극적이다.

예, 당신은 이것을 할 수 있습니다. 그러나 기본적으로 절차 라이브러리와 동일한 기능을 제공하는 클래스를 만들고 있습니다. 그렇게하는 유일한 이유는 언어에 절차 모듈 (예 : Java 또는 Ruby)이없는 경우입니다.

절차 모듈이있는 언어 (PHP는 절차 모듈이 있다고 생각합니다)에서 절차 모듈을 사용하는 것을 고려할 수 있습니다.

클래스를 다시 디자인하여 클래스의 인스턴스가 일관된 객체를 나타낼 수도 있습니다.

그러나 OO를 위해서만이 아니라 추가적인 힘을 줄 때만 OO 표기법을 사용하십시오!

평신도의 말로

• 설명하는 것을 유틸리티 클래스라고합니다.
• 상태가 없으므로 실제로 여러 인스턴스를 가질 필요가 없습니다.
• 모든 메소드는 정적이므로 모든 것을 매개 변수로 전달해야합니다.

이러한 클래스는 존재합니다. 예를 들어 Java SDK에는 Collections 클래스가 있으며 이는 컬렉션에서 작동하거나 컬렉션을 반환하는 정적 메서드로만 구성됩니다.

따라서 모든 클래스를 도메인 엔터티에서 모델링 할 필요는 없습니다.

반면에, OOP의 진정한 힘은 다형성과 캡슐화에 있기 때문에 OOP 언어로 만들어진 프로그램에서 그러한 클래스는 단지 몇 개이거나 몇 개만 있어야합니다.

비행기를 이용해 한 장소에서 다른 장소로 이동하는 것은 비행기가 아니라 고속도로를 주행하는 것과 같습니다. 비행기는 자동차와 같은 바퀴를 가지고 있지만 비행기를 타려고합니다.

아니요, 클래스는 단순히 인스턴스화 가능하고 멤버가 있으며 상속받을 수있는 것을 나타냅니다.

실제로 언어에는 정적 클래스가있을 수 있으며이 클래스는 두 번 이상 인스턴스화되지도 않습니다.

.NETMath 은 엔터티를 나타내지 않는 "프로페셔널"클래스의 훌륭한 예입니다 (수학이 무엇인지에 대해 철학적으로 설명하고 싶지 않다면 ...). 그리고 그러한 클래스의 합법적 인 사용 사례를 보여줍니다. 메소드와 2 개의 필드 만 있습니다 (둘 다 개별 상수를 나타냄).

유사한 라이브러리의 클래스 계층은 Math.Net수학 / 숫자 메서드를 유형별로 클래스로 그룹화합니다. 여기서 클래스는 엔티티가 아니라 논리적 범주를 나타냅니다.

나 자신은 종종 관련 (정적) 함수의 백에 불과하거나 하나의 중앙 위치에 편리하게 그룹화 된 상수 그룹에 불과한 (정적) 클래스를 종종 만듭니다. 나는 이것이 좋은 디자인이라고 주장하지는 않지만 때로는 가장 간단한 솔루션입니다.

귀하의 질문에 대한 답변은 궁극적으로 "클래스"및 "엔티티"와 같은 용어를 얼마나 정확하게 정의하는지에 달려 있습니다. 당신은 후자를 정의하는 좋은 일을했으며, 물리적, 개념적 실체 모두를 허용했다. 그러나 순수 주의자에 대한 "클래스"라는 용어는 항상 "특정 내부 표현으로 객체를 인스턴스화하기위한 팩토리"가 될 것이며 실용 주의자에게는 용어가 순수 주의자에 의해 멸시되는 Java 또는 C ++ 항목을 포함합니다. 실용 주의자들이 Java와 C ++가 할 줄 알지만 "순간 주의자"라는 용어는 Alan Kay가 말했을 때 의미했던 것을 의미하기 위해 "OOP"라는 용어를 사용합니다. C ++을 염두에두고 ""] ( 그래서 Alan Kay는 "객체 지향"이라는 용어가 실제로 무엇을 의미 했는가? )

실용 주의자 관점을 취하면 인스턴스없는 유틸리티 클래스를 사용할 수 있습니다. 그러나 순수 주의적 견해가 더 흥미 롭습니다. Kay에 따르면 OOP는 항상 클래스보다 메시지 에 대한 것이 었습니다 . 그래서 당신의 질문에 :

클래스가 엔티티가없는 객체를 나타낼 수 있습니까?

아니요. 클래스는 객체를 분류 합니다. 클래스는 정의상 new객체 생성 과 같은 메시지를 보내는 엔터티 입니다. 객체는 클래스로 만든 엔터티입니다. 객체를 제조하고 실제로 분류하기위한 클래스가 존재합니다. 그것이 수업이하는 일입니다. 클래스는 객체를 만듭니다. 클래스를 사용하여 객체를 분류합니다. 따라서 C가 인스턴스화 또는 서브 클래 싱을 허용하지 않는 메소드 번들 인 경우 C로 분류 된 오브젝트가 없으므로 C는 클래스가 아닙니다.

그렇지 않은 경우 왜 불량 / 불완전 / OOP 중심이 아닌가?

그들은 나쁘지 않습니다. 그냥 클래스라고 부르지 마십시오. 메소드 번들 은 OOPable입니다. 메소드 를 호출하기 위해 메시지를 보낼 수 있지만 객체를 인스턴스화 할 수 없다면 클래스가 아닙니다. 루비를 아십니까? 루비에서 모듈 은 메소드 묶음입니다. 클래스는 객체를 생성 할 수있는 모듈입니다. 모듈은 나쁘지 않습니다 . 그러나 클래스를 모듈과 다르게 만드는 것은 순수한 OOP 용어로 클래스가 인스턴스를 가질 수 있다는 것입니다. 모듈은 몇 가지 방법 일뿐입니다. 혼동은 C ++와 Java 및 기타 언어가 class와 module 모두에 "class"라는 용어를 사용한다는 것 입니다.

이제 특정 예제 중 하나를 보려면 argument와 함께 MotorOperations메시지 computePowerConsumptionForMotor를 보낼 수 있는 클래스에 대해 문의 하십시오 id. 그게 나쁜가요? 적어도 그것은 원칙을 묻지 말라고 위반 하지 않습니다 . 우리는 말라 가 모터 클래스를 만들고 그것에게 보내는 powerConsumption메시지? 아마도 시간의 100 %는 아니지만 그러한 일을 시도하면 코드에 대한 멋진 통찰력이 생길 수 있습니다. 또는, 그것은 작은 클래스의 폭발로 이어질 수 있습니다.

OOP와 일치하도록 개념적으로 변경 / 개선해야하는 방법이 있습니까?

"OOP 수행"이 중요한 경우, 서로 메시지를 보내서 통신하는 구성 요소로 시스템을 설계하는 방법을 찾고 싶을 것입니다. 그것은 단지 OOP 가 무엇인지 , 또는 적어도 용어의 창시자가 생각한 것입니다. 이보기에서 유틸리티 클래스는 OOP가 아닙니다. 그러나 어떤 사람들에게는 그럴 수도 있습니다.

수업에서 인스턴스화 된 수백만의 생활, 호흡, 사물 중에서 전체 시스템을 만들려고하면 일부 프로젝트에서 효과가있을 수 있습니다. 그러나 인공적이고 잘못된 소리를내는 수업을 만들면 모듈을 소개해야합니다. 클래스를 강조하고 인스턴스화 가능한 클래스가 터무니없는 경우 모듈을 사용하십시오.

TL; DR-메소드 번들이 항상 나쁜 것은 아닙니다. 먼저 인스턴스화 가능한 클래스를 사용하십시오. 필요한 경우에만 "모듈"로 폴백하십시오.

주어진 예를 들면 :

getMotorDataFromHTMLForm()
selectMotorFromUserRequirements($requirements)

이것들은 Motor객체를 리턴하는 "factory"메소드처럼 보입니다 . 두 번째는 요구 사항을 충족하기 위해 새 개체를 만들거나 검사중인 데이터베이스 또는 메모리 내 모터 모음을 의미합니다. 어떤 경우에는 그 방법이되어야합니다. 또는 요구 사항 오브젝트에 대한 메소드 일 수 있습니다.

getMotorManufacturers()

어디서 구할 수 있습니까? 이것이이 방법이되어야합니다.

canMotorCanHandleOperatingConditions($conditions)
computePowerConsumptionForMotor($id)

이것들은 그들에 대한 방법이어야합니다 Motor.

객체는 응집력이 높은 메소드와 데이터의 모음입니다. 그들은 상호 연관성이 높고 상태가 유지되기 때문에 클래스에 속합니다.

이것은 큰 전면 디자인을 사용하고 모든 것을 모델링하려고 시도하거나 당시의 시스템 요구에 맞는 것으로 객체를 반복하고 발전시키는 새로운 디자인에 해당됩니다.

상태를 유지할 이유가 없다면 객체를 인스턴스화해야 할 이유가 없기 때문에 클래스를 가질 이유가 없을 것입니다. 그렇지 않으면 사용하는 언어에 클래스를 사용하는 것 이외의 네임 스페이스를 정의 할 수있는 기능이 없습니다. 관용적이기 때문에 클래스를 사용하는 것이 좋습니다.

나는 일반적인 방식 이외의 방식으로 클래스를 사용하는 것에 대한 부정적인 측면을 생각할 수 없습니다. "네임 스페이스"를 인스턴스화하여 불필요한 비용과 복잡성을 초대합니다. 이 코드를 지원하는 사람은 데이터가 추가인지 부하 (대부분 1 인당 1 회 비용)를 소비하는 위치를 궁금해 할 것입니다. 추가 가치가없는 특이한 사용법입니다.