제 차고에 정말 차가 있나요?
저는 자바 프로그래밍에 초보자라서 OOP의 요령을 알고 싶습니다.
그래서 저는 추상 수업을 만들었습니다.
public abstract class Vehicle{....}
및 2개의 서브클래스:
public class Car extends Vehicle{....}
public class Boat extends Vehicle{....}
Car ★★★★★★★★★★★★★★★★★」Boat또한 일반적이지 않은 몇 가지 고유한 필드 및 메서드를 보유하고 있습니다(같은 이름을 가지고 있지 않기 때문에 차량에서 추상적인 메서드를 정의할 수 없습니다).
이제 mainClass에서 새 Garage를 설정했습니다.
Vehicle[] myGarage= new Vehicle[10];
myGarage[0]=new Car(2,true);
myGarage[1]=new Boat(4,600);
저는 다형성에 매우 만족하고 있었습니다만, 다음과 같은 자동차 고유의 분야 중 하나에 액세스하려고 했습니다.
boolean carIsAutomatic = myGarage[0].auto;
컴파일러는 그것을 받아들이지 않습니다.저는 캐스팅을 사용하여 이 문제를 해결했습니다.
boolean carIsAutomatic = ((Car)myGarage[0]).auto;
그거는...방법에는 도움이 되지 않고 필드에만 도움이 됩니다.할 수 없다는 뜻
(Car)myGarage[0].doSomeCarStuff();
그래서 제 질문은 제 차고에 정말 뭐가 있을까요?나는 직감을 얻고 "뒤에서" 무슨 일이 일어나고 있는지 이해하려고 노력하고 있다.
장래의 독자를 위해서, 이하의 회답의 간단한 요약을 참조해 주세요.
- 아, 아, 아, 아, 이런 게
CarmyGarage[] - 컴파일러는 슈퍼 : "Vehicle")에예: "Vehicle 수 .
Vehicle myGarage[]) - 해결 방법에 대해서는, 다음의 2개의 주요한 어프로치가 있습니다.
- 타입 캐스팅을 사용하면 컴파일러의 우려가 경감되고 설계에 오류가 남아 실행 시간을 단축할 수 있습니다.
- 캐스팅이 필요한 건 디자인에 결함이 있다는 거예요.비차량 기능에 액세스해야 하는 경우 차량 기반 데이터 구조에 자동차 및 보트를 저장하지 않아야 합니다.이러한 모든 기능을 차량에 포함시키거나 좀 더 구체적인(유래된) 유형 기반 구조를 사용합니다.
- 대부분의 경우, 구성 및/또는 인터페이스가 상속의 더 나은 대안이 될 수 있습니다.아마 다음 질문의 주제는...
- 그 밖에도 많은 훌륭한 통찰력들이 있습니다. 만약 답을 훑어볼 시간이 있다면 말이죠.
「 」의 를 만들 .Car ★★★★★★★★★★★★★★★★★」Boat차고에 보관해야 합니다.
예:
public class Garage {
private List<Car> cars;
private List<Boat> boats;
}
그런 다음 보트 또는 자동차에 고유한 방법을 정의할 수 있습니다.
그럼 왜 다형증이 있는 거죠?
'우리'라고 합시다.Vehicle음음음같 뭇매하다
public abstract class Vehicle {
protected int price;
public getPrice() { return price; }
public abstract int getPriceAfterYears(int years);
}
모든 모든Vehicle따라서 가격이 있기 안에넣을 수 있습니다 안에 때문에될 수 있는 가격.Vehicle추상 클래스입니다.추상 수업
그러나, n년 후의 가격을 결정하는 공식은 차량에 따라 다르므로, 이를 정의하는 것은 구현 계층에 맡겨졌다.예:
public Car extends Vehicle {
// car specific
private boolean automatic;
@Override
public getPriceAfterYears(int years) {
// losing 1000$ every year
return Math.max(0, this.price - (years * 1000));
}
}
그 그Boat등급수 있습니다 있을클래스에는다른 정의가에 대한 다른 정의할 수도 있다.getPriceAfterYears그리고 특정한 속성 및 메서드.및 특정 속성 및 메서드를 지정합니다.
이제 자,이제 다시에.Garage교실에서, 당신:class는 다음과수 있습니다 정의할 같이 할 수 있다.
// car specific
public int numberOfAutomaticCars() {
int s = 0;
for(Car car : cars) {
if(car.isAutomatic()) {
s++;
}
}
return s;
}
public List<Vehicle> getVehicles() {
List<Vehicle> v = new ArrayList<>(); // init with sum
v.addAll(cars);
v.addAll(boats);
return v;
}
// all vehicles method
public getAveragePriceAfterYears(int years) {
List<Vehicle> vehicules = getVehicles();
int s = 0;
for(Vehicle v : vehicules) {
// call the implementation of the actual type!
s += v.getPriceAfterYears(years);
}
return s / vehicules.size();
}
다형성의 흥미는수 있다는 것이다 부를 같이 다형성의관심사는 다음과를 부를 수 있을 것이다.getPriceAfterYears한에서에Vehicle 구현에 신경 쓰지 않습니다.
일반적으로 다운캐스팅은 결함이 있는 설계의 표시입니다. 실제 유형을 구분해야 할 경우 차량을 모두 함께 보관하지 마십시오.
주의: 물론 여기서의 디자인은 쉽게 개선될 수 있습니다.그것은 단지 요점을 설명하기 위한 예시일 뿐이다.
차고에 정확히 무엇이 있는지 확인하려면 다음 절차를 수행합니다.
Vehicle v = myGarage[0];
if (v instanceof Car) {
// This vehicle is a car
((Car)v).doSomeCarStuff();
} else if(v instanceof Boat){
// This vehicle is a boat
((Boat)v).doSomeBoatStuff();
}
업데이트: 아래 코멘트에서 알 수 있듯이, 이 방법은 간단한 해결책으로는 충분하지만, 특히 차고에 차량이 많이 있는 경우에는 권장되지 않습니다.그러니 차고가 작아질 것을 알고 있을 때만 사용하세요.그렇지 않은 경우 스택 오버플로에서 "인스턴스 회피"를 검색합니다.이 검색에는 여러 가지 방법이 있습니다.
기본 유형에 대해 작업하는 경우 해당 유형의 공용 메서드 및 필드에만 액세스할 수 있습니다.
확장 유형에 액세스하고 싶은데 저장된 기본 유형의 필드가 있는 경우(예:) 먼저 캐스팅한 다음 액세스할 수 있습니다.
Car car = (Car)myGarage[0];
car.doSomeCarStuff();
또는 온도 필드가 없는 더 짧은 값:
((Car)myGarage[0]).doSomeCarStuff();
네가 사용하고 계시기 때문에를 사용하고 있Vehicle개체는, 당신은 단지 그들이에 대한 기본 클래스에서 주조 없이 메서드를 호출할 수 있다.오브젝트에서는 캐스팅 없이 베이스 클래스의 메서드만 호출할 수 있습니다.그래서 당신의 차고에 다른 배열의 개체는 구별하기 위해 더 바람직한 일이다 명단-배열은 종종 좋은 생각이 아니기 때문에 훨씬 덜에 관련된따라서 차고에서는보다 융통성이 있어요 다양한 어레이(또는 더 나은 목록)의 객체를 구별하는 것이 권장될 수 있습니다. 어레이는 처리의 유연성이 매우 낮기 때문에 권장되지 않습니다.Collection- 이 - - - -
차고에서 차량을 보관한다고 정의했으므로 어떤 종류의 차량을 가지고 있는지 상관하지 않습니다.그 차량들은 엔진, 바퀴, 움직이는 것과 같은 행동과 같은 공통적인 특징을 가지고 있다.이러한 기능의 실제 표현은 다를 수 있지만 추상 계층에서는 동일합니다.추상 클래스를 사용했는데, 이는 일부 속성 및 동작이 두 차량에서 완전히 동일함을 의미합니다.차량에 공통적인 추상적 기능이 있다는 것을 표현하고 싶다면 이동과 같은 인터페이스를 사용하는 것은 자동차와 보트에 따라 다를 수 있습니다.둘 다 지점 A에서 지점 B로 이동할 수 있지만 다른 방법(바퀴 위 또는 물 위)으로 이동할 수 있습니다. 따라서 차고에 동일한 방식으로 작동하는 차량이 있고 차량의 특정 기능에 대해 신경 쓰지 않습니다.
코멘트에 응답하려면:
인터페이스란 외부와 통신하는 방법을 기술하는 계약을 의미합니다.계약서에는 차량이 이동할 수 있고 조향할 수 있다고 정의되어 있지만, 실제 작동 방식에 대해서는 설명하지 않고 구현에 설명되어 있습니다.추상 클래스에서는 구현을 공유하는 함수가 있을 수 있지만, 구현 방법을 모르는 함수도 있습니다.
추상 클래스를 사용하는 한 가지 예는 다음과 같습니다.
abstract class Vehicle {
protected abstract void identifyWhereIAm();
protected abstract void startEngine();
protected abstract void driveUntilIArriveHome();
protected abstract void stopEngine();
public void navigateToHome() {
identifyWhereIAm();
startEngine();
driveUntilIArriveHome();
stopEngine();
}
}
차량마다 동일한 단계를 사용하지만, 차량 유형에 따라 이 단계의 구현 방식이 다릅니다.차는 GPS를 사용하고 보트는 음파탐지기를 사용하여 위치를 확인할 수 있습니다.
저는 자바 프로그래밍에 초보자라서 OOP의 요령을 알고 싶습니다.
단 2센트 - 이미 많은 흥미로운 이야기들이 나왔기 때문에 간단히 설명하도록 하겠습니다.하지만 사실 여기에는 두 가지 질문이 있습니다.하나는 "OOP"에 대한 것이고 다른 하나는 Java에서 구현되는 방법에 대한 것입니다.
우선, 네, 차고에 차가 있습니다.그럼 네 추측이 맞아.그러나 Java는 정적으로 입력된 언어입니다.컴파일러의 타입 시스템은 대응하는 선언에 의해서만 다양한 오브젝트의 타입을 알 수 있습니다.그들의 용법에 의해서가 아니다.의 배열이 있는 경우Vehicle컴파일러는 그것밖에 모릅니다.따라서 이 체크박스는 모든 동작에 대해 허용된 동작만 수행하는지 확인합니다. Vehicle(즉, 에서 볼 수 있는 방법 및 속성)Vehicle선언)을 클릭합니다.
컴파일러에게 명시적 캐스트를 사용하여 "사실 이것이 "라는 것을 알고 있습니다"라고 설명할 수 있습니다.(Car)컴파일러는 당신을 믿을 것입니다. Java에서는 런타임에 체크가 있어도, 그것이 원인이 될 수 있습니다.ClassCastException 당신이 거짓말을(other language like C++ won't check at run-time - you have to know what you do) 하면 더 이상의 피해를 막을 수 있습니다.
마지막으로 꼭 필요한 경우 런타임 유형 식별을 사용할 수 있습니다. instanceof오브젝트를 캐스팅하기 전에 오브젝트의 "실제" 유형을 확인합니다.그러나 이는 Java에서 대부분 나쁜 관행으로 간주됩니다.
앞서 말했듯이, 이것이 OOP를 구현하는 자바 방식입니다."동적 언어"로 널리 알려진 전혀 다른 클래스의 언어 패밀리가 있으며, 이는 실행 시 개체에서 작업이 허용되는지 여부만 확인합니다.이러한 언어에서는 일반적인 메서드를 모두 일부(추상적인) 기본 클래스로 "업업"할 필요가 없습니다.이것은 오리 타이핑이라고 불립니다.
집사한테 물어봤지
지브스, 자바섬에 있는 내 차고 기억나?저기 주차된 첫 번째 차량이 자동 차량인지 확인해 보세요.
게으른 지베스는 말했다.
하지만 자동이나 비자동이 불가능한 차량이라면요?
그게 다예요.
현실은 정적인 타입이라기보다 오리 타입이기 때문에 그게 다가 아닙니다.그래서 내가 지브스가 게으르다고 말한 거야.
는 보다 수준에 . 즉, 과 같이 구축한 것입니다.Vehicle Garage needs needs the the the the the the the the the the the the the the the보다 사물에 대해 더 잘 .Vehicle인터페이스가 알립니다.도 한번 .Vehicle의 Garage하는 모든 에서)Vehicle: 차 : : : : : : : : : :?어떻게 하면 제 방법으로 그것들을 가능하게 할 수 있을까요?
예를 들어 다음과 같습니다.
bool carIsAutomatic = myGarage[0].auto;
당신네 차고에서 차량의 엔진에 대해 알고 싶어...이유?어쨌든, 이 사실이 그냥 드러날 필요는 없어Car 실장되어 있지 않은 것을 할 수 isAutomatic() in the method in the method in 。Vehicle, 이렇게 해 보세요.return TrueBoat ★★★★★★★★★★★★★★★★★」return this.autoCar.
값이면 더 것 요.EngineType（ 거형 ）HAS_NO_GEARS,HAS_GEARS_AUTO_SHIFT,HAS_GEARS_MANUAL_SHIFT인 )의 할 수 합니다.Vehicle깔끔하고 정확하게. (어쨌든 오토바이를 다루려면 이 구별이 필요하겠죠.)
차고에는 차량이 포함되어 있으므로 컴파일러의 정적 컨트롤 뷰에서 차량이 있고 .auto가 자동차 필드이므로 액세스할 수 없습니다. 동적으로 자동차이므로 캐스트에게 문제가 발생하지 않습니다. 보트가 될 경우 Car에 캐스팅하려고 하면 런타임에 예외가 발생합니다.
은 '하다'를 적용하기에 입니다.Visitor디자인 패턴
이 패턴의 장점은 슈퍼클래스의 다른 서브클래스에서 관련 없는 코드를 호출할 수 있다는 것입니다.어디서든 이상한 캐스팅을 하거나 관련 없는 메서드를 슈퍼클래스에 넣을 필요가 없습니다.
'이렇게 하다', '이렇게 하다'를 만들 수 있습니다.Visitor 및 을 설정합니다.Vehicle로 to to to로 accept()방문자
그리고 의 '를 만들 수 .Visitor관련 하고, 합니다.Visitor구현: 클린 클래스를 만들 때 이 설계 패턴을 매우 강력하게 만듭니다.
데모 예:
public class VisitorDemo {
// We'll use this to mark a class visitable.
public static interface Visitable {
void accept(Visitor visitor);
}
// This is the visitor
public static interface Visitor {
void visit(Boat boat);
void visit(Car car);
}
// Abstract
public static abstract class Vehicle implements Visitable {
// NO OTHER RANDOM ABSTRACT METHODS!
}
// Concrete
public static class Car extends Vehicle {
public void doCarStuff() {
System.out.println("Doing car stuff");
}
@Override
public void accept(Visitor visitor) {
visitor.visit(this);
}
}
// Concrete
public static class Boat extends Vehicle {
public void doBoatStuff() {
System.out.println("Doing boat stuff");
}
@Override
public void accept(Visitor visitor) {
visitor.visit(this);
}
}
// Concrete visitor
public static class StuffVisitor implements Visitor {
@Override
public void visit(Boat boat) {
boat.doBoatStuff();
}
@Override
public void visit(Car car) {
car.doCarStuff();
}
}
public static void main(String[] args) {
// Create our garage
Vehicle[] garage = {
new Boat(),
new Car(),
new Car(),
new Boat(),
new Car()
};
// Create our visitor
Visitor visitor = new StuffVisitor();
// Visit each item in our garage in turn
for (Vehicle v : garage) {
v.accept(visitor);
}
}
}
바와 같이, '우리'는 '우리'입니다.StuffVisitor할 수 .Boat ★★★★★★★★★★★★★★★★★」Car「」의 ,visit또한 동일한 코드를 호출할 수도 ..visit()★★★★★★ 。
, 이하면, 「」는 되지 않는 해 주세요.instanceof어떤 해킹적인 클래스 체크도 가능합니다.입니다.void accept(Visitor).
이을 "3"에 추가하면 .Visitor인터페이스도 있습니다.
여기에서는 다른 사람들의 아이디어를 정리하고 있을 뿐입니다(그리고 저는 Java가 아니기 때문에 실제가 아니라 유사입니다). 하지만 이 계획된 예에서는 자동차 점검 방식을 전용 클래스로 요약합니다. 이 클래스는 자동차만 알고 정비소를 볼 때는 자동차만 신경 씁니다.
abstract class Vehicle {
public abstract string getDescription() ;
}
class Transmission {
public Transmission(bool isAutomatic) {
this.isAutomatic = isAutomatic;
}
private bool isAutomatic;
public bool getIsAutomatic() { return isAutomatic; }
}
class Car extends Vehicle {
@Override
public string getDescription() {
return "a car";
}
private Transmission transmission;
public Transmission getTransmission() {
return transmission;
}
}
class Boat extends Vehicle {
@Override
public string getDescription() {
return "a boat";
}
}
public enum InspectionBoolean {
FALSE, TRUE, UNSUPPORTED
}
public class CarInspector {
public bool isCar(Vehicle v) {
return (v instanceof Car);
}
public bool isAutomatic(Car car) {
Transmission t = car.getTransmission();
return t.getIsAutomatic();
}
public bool isAutomatic(Vehicle vehicle) {
if (!isCar(vehicle)) throw new UnsupportedVehicleException();
return isAutomatic((Car)vehicle);
}
public InspectionBoolean isAutomatic(Vehicle[] garage, int bay) {
if (!isCar(garage[bay])) return InspectionBoolean.UNSUPPORTED;
return isAutomatic(garage[bay])
? InspectionBoolean.TRUE
: InspectionBoolean.FALSE;
}
}
요점은, 당신은 이미 자동차의 변속기에 대해 질문할 때 자동차에만 관심을 두기로 결정했다는 것입니다.그러니 그냥 자동차 검사관에게 물어보세요.트라이스테이트 Enum 덕분에 자동인지 자동차가 아니더라도 알 수 있습니다.
물론 관심 차량마다 다른 VehicleInspector가 필요합니다.그리고 방금 어떤 VehicleInspector가 체인을 인스턴스화하느냐에 대한 문제를 다뤘습니다.
그 대신에, 인터페이스를 참조해 주세요.
★★★★★getTransmission 「」 「」 「」 「」 「CHANGE: "CHANGE: "CHANGE: "CHANGE: ")HasTransmission를 쓸 수★★★★★★★★★★★★★★★★★★:
abstract class Vehicle { }
class Transmission {
public Transmission(bool isAutomatic) {
this.isAutomatic = isAutomatic;
}
private bool isAutomatic;
public bool getIsAutomatic() { return isAutomatic; }
}
interface HasTransmission {
Transmission getTransmission();
}
class Car extends Vehicle, HasTransmission {
private Transmission transmission;
@Override
public Transmission getTransmission() {
return transmission;
}
}
class Bus extends Vehicle, HasTransmission {
private Transmission transmission;
@Override
public Transmission getTransmission() {
return transmission;
}
}
class Boat extends Vehicle { }
enum InspectionBoolean {
FALSE, TRUE, UNSUPPORTED
}
class TransmissionInspector {
public bool hasTransmission(Vehicle v) {
return (v instanceof HasTransmission);
}
public bool isAutomatic(HasTransmission h) {
Transmission t = h.getTransmission();
return t.getIsAutomatic();
}
public bool isAutomatic(Vehicle v) {
if (!hasTranmission(v)) throw new UnsupportedVehicleException();
return isAutomatic((HasTransmission)v);
}
public InspectionBoolean isAutomatic(Vehicle[] garage, int bay) {
if (!hasTranmission(garage[bay])) return InspectionBoolean.UNSUPPORTED;
return isAutomatic(garage[bay])
? InspectionBoolean.TRUE
: InspectionBoolean.FALSE;
}
}
이제 차량에 관계없이 변속기에 대해서만 이야기하므로 변속기에 문의할 수 있습니다.인스펙터버스와 차량 모두 변속기를 통해 검사할 수 있습니다.경감님, 하지만 전송에 대한 질문만 할 수 있습니다.
이제 부울 값만 신경 쓰는 것이 아니라고 판단할 수 있습니다.이 때 지원되는 상태와 값을 모두 표시하는 일반 지원 유형을 사용하는 것이 좋습니다.
class Supported<T> {
private bool supported = false;
private T value;
public Supported() { }
public Supported(T value) {
this.isSupported = true;
this.value = value;
}
public bool isSupported() { return supported; }
public T getValue() {
if (!supported) throw new NotSupportedException();
return value;
}
}
인스펙터는 다음과 같이 정의됩니다.
class TransmissionInspector {
public Supported<bool> isAutomatic(Vehicle[] garage, int bay) {
if (!hasTranmission(garage[bay])) return new Supported<bool>();
return new Supported<bool>(isAutomatic(garage[bay]));
}
public Supported<int> getGearCount(Vehicle[] garage, int bay) {
if (!hasTranmission(garage[bay])) return new Supported<int>();
return new Supported<int>(getGearCount(garage[bay]));
}
}
이미 말했듯이, 저는 Java가 아니기 때문에 위의 구문 중 일부는 틀릴 수 있지만, 그 개념은 유효합니다.단, 위의 내용을 테스트하지 않고 중요한 장소에서 실행하지 마십시오.
Java에 있는 경우 리플렉션을 사용하여 함수를 사용할 수 있는지 확인하고 실행할 수도 있습니다.
각 개별 차량을 보다 명확하게 구분하는 데 도움이 되는 차량 수준 필드를 만듭니다.
public abstract class Vehicle {
public final boolean isCar;
public final boolean isBoat;
public Vehicle (boolean isCar, boolean isBoat) {
this.isCar = isCar;
this.isBoat = isBoat;
}
}
상속 클래스의 차량 수준 필드를 적절한 값으로 설정합니다.
public class Car extends Vehicle {
public Car (...) {
super(true, false);
...
}
}
public class Boat extends Vehicle {
public Boat (...) {
super(false, true);
...
}
}
Vehicle level 필드를 사용하여 차량 유형을 올바르게 판독합니다.
boolean carIsAutomatic = false;
if (myGarage[0].isCar) {
Car car = (Car) myGarage[0];
car.carMethod();
carIsAutomatic = car.auto;
}
else if (myGarage[0].isBoat) {
Boat boat = (Boat) myGarage[0];
boat.boatMethod();
}
컴파일러에게 차고에 있는 모든 것이 차량이라고 알려주기 때문에 차량 클래스 수준의 메서드와 필드를 고집하게 됩니다.타입을 하려면 , 「」등)를 .isCar ★★★★★★★★★★★★★★★★★」isBoat이를 통해 프로그래머가 사용 중인 차량 유형을 더 잘 이해할 수 있습니다.
이므로 Java와 이 가장 .Boat §Cars.
프로그램에서 제시하고 싶은 오브젝트를 모델링하는 것(일부 문제를 해결하기 위해)과 코딩하는 것은 별개의 문제입니다.당신 코드에 따르면 기본적으로 어레이를 사용하여 차고를 모델링하는 것은 부적절하다고 생각합니다.어레이를 오브젝트로 간주하는 것은 보통 언어의 완전성이나 친밀함을 위해 보이는 경우가 많지만, 어레이는 실제로는 컴퓨터 고유의 것입니다.IMHO, 특히 Java에서는 어레이를 확장할 수 없습니다.
저는 차고를 나타내기 위해 수업을 올바르게 모델링하는 것이 "차고지 안의 차"라는 질문에 대답하는 데 도움이 되지 않는다는 것을 이해합니다. 단지 조언 하나일 뿐입니다.
암호로 돌아가.OOP에 대한 이해를 얻는 것 외에 몇 가지 질문을 하면 해결하고 싶은 문제를 더 잘 이해할 수 있습니다(단순히 "어느 정도"가 아니라 다음과 같은 문제가 있다고 가정합니다).
- 하고 싶은 사람
carIsAutomatic - 의 「」
carIsAutomatic을 할 수 있을까요?doSomeCarStuff
어떤 검사관이나 오토 트랜스미션 카 등을 운전할 줄 아는 사람일 수도 있지만, 정비소의 관점에서는 어떤 차량을 가지고 있을 뿐이므로 (이 모델에서는) 자동차인지 보트인지 판단하는 것은 검사관이나 운전자의 책임입니다.현시점에서는 다른 차량군을 만드는 것이 좋을지도 모릅니다.ss는 장면에서 유사한 유형의 *배우*를 나타냅니다.해결해야 할 문제에 따라 다르지만, 꼭 해야 한다면, 정비소를 슈퍼 인텔리전트 시스템으로 모델링할 수 있습니다. 그러면 일반 정비소가 아니라 자판기처럼 작동할 수 있습니다. 버튼은 "자동차"라고 표시되고 다른 버튼은 "보트"라고 표시되므로 사람들은 원하는 대로 버튼을 눌러 자동차나 보트를 얻을 수 있습니다. 결과적으로 이 슈퍼 인텔리전트 시스템이 됩니다.사용자에게 어떤 것(자동차 또는 보트)을 제시해야 하는지 지시할 책임이 있는 연결 차고. 이 즉흥적인 조치를 따르기 위해 차고에서 차량을 인수할 때 부기가 필요할 수 있으며, 누군가가 정보를 제공해야 할 수도 있습니다. 이러한 모든 책임은 단순한 메인 클래스를 넘어선다.
이 정도 이야기했지만, OO 프로그램을 코드화하는 것은 물론 보일러 플레이트와 함께 모든 문제를 이해하고 있습니다.특히, OO가 해결하려고 하는 문제는 매우 간단하지만, 그 외의 많은 문제를 해결할 수 있는 실현 가능한 방법입니다.지금까지의 경험으로 볼 때, 사람들은 오브젝트가 서로 어떻게 상호작용하는지를 설계하고 클래스(Java 인터페이스도 포함)로 분류한 다음 Main 클래스 같은 것을 사용하여 세계를 부트스트랩합니다.
언급URL : https://stackoverflow.com/questions/24883075/do-i-really-have-a-car-in-my-garage
'programing' 카테고리의 다른 글
| Vue.js 단일 파일 구성 요소에서 외부 js 라이브러리 가져오기 (0) | 2022.08.16 |
|---|---|
| Linux pthreads에서 스레드 이름을 설정하는 방법 (0) | 2022.08.16 |
| Java EE란 정확히 무엇입니까? (0) | 2022.08.16 |
| VueJS 컴포넌트 슬롯에 클래스를 추가하는 방법 (0) | 2022.08.16 |
| '아토이'라는 이름은 어디서 유래한 것일까? (0) | 2022.08.10 |