나는 종종 코드 재사용 측면에서 객체가 전달되지 않았다고 들었습니다. 동의하십니까? 그들이하지 않았다고 생각한다면 왜 안됩니까?

반드시 그런 것은 아닙니다.

객체는 더 나은 의미 체계, 코드 / 기능 구성 및 사용 편의성을 제공합니다.

잘 설계된 라이브러리 는 객체 자체가 아니라 코드 재사용을 약속합니다.

솔직히 나는 "코드 재사용"이 실제로 누구의 뒤에 있는지 (또는 적어도 후에 있어야하는지) 확실하지 않습니다. 저의 철학은 "소프트웨어 구성 요소"입니다. 이는 우수한 인터페이스를 통해 유지 관리 효율성을 높이고 불필요한 커플 링을 피합니다. "코드 재사용"은 때때로 빠져 나오는 것 중 하나입니다. 불필요하게 중복 된 코드는 잘못된 방식으로 구성했으며 물론 유지하기가 어렵다는 신호입니다.

질문에 좀 더 직접적으로 대답하기 위해 상속, 특성, 위임, 고차 함수 등과 같이 자신을 반복하지 않는 훌륭한 도구 모음이 있습니다. 그중 사람들은 상속을 OO와 전체적으로 혼동하는 경향이 있습니다. 당신이 나에게 요청하면 그들은 또한 그것을 조금 남용하는 경향이 있습니다. 어쩌면 그것은 "OO sucks"바이브의 일부일 것입니다.

아니요, "객체"는 코드 재사용을 더 쉽고 일반적으로 만들지 않았습니다. 모듈 식 프로그램에서 코드가 재사용되지 않도록하는 것과 같은 우려 (범용 API를 설계, 테스트 및 문서화하는 것은 일회성 루틴을 작성하는 것보다 훨씬 선행 작업이 필요하며 모든 거래의 잭은 없음의 마스터-재사용하려는 논리는 실제로 사용되는 용도에 맞게 최적화되지 않을 수 있음) OO 프로그램에 적용하십시오. 잘 설계되지 않은 객체 모델은 재사용이 불가능한 재사용을 방해 할 수 있습니다 암호.

OO는 많은 문제에 대한 편리한 추상화이지만 '80 년대에서 90 년대 사이의 과대 광고에주의하십시오. 자고있는 동안 와플을 만드는 것 이상으로 무역의 근본적인 문제를 마술처럼 해결하지는 않습니다.

모든 객체가 재사용되는 것을 기대하지는 않지만 많은 프로젝트에서 재사용 할 객체가 많이 있습니다. 또한 하나의 프로젝트에서 재사용되는 객체도 있습니다. 우리는 종종 동일한 프로젝트에 대해 Click-Once 데스크톱 앱, 웹 앱 및 전화 앱의 비즈니스 로직 개체뿐만 아니라 동일한 비즈니스 개체 (또는 데이터 전송 개체)를 사용합니다.

OO가 재사용을 제공하지 않는다는 소식을 어디에서 들었습니까? 그리고 추론은 무엇입니까? 아마도 물체의 디자인으로 인해 그러한 상황이 발생했을 것입니다 ...

일부 프로그래머는 모든 언어와 스타일로 복사하여 붙여 넣습니다.

정말 좋은 프로그래머는 거의 모든 언어로 대부분의 복사 및 붙여 넣기를 피할 수 있습니다.

OO 패턴은 재사용을 권장하는 경향이 있습니다. 나는 OO가 아닌 스타일로 작성된 Java 코드 (데이터가 엉터리 ORM으로 인해 코드와 분리되어 있음)를 보았고 재사용이 정말 비참했습니다. 그러나 OO에서는 동일한 프로그래머가 디자인에서 더 나은 작업을 수행했습니다 ( 재사용).

또한 우리가 setters / getters, switch statement, anonymous inner class, 거대한 함수 등과 같은 비 oo 패턴 또는 oo anti-patters를 사용하는 경우 코드 재사용이 감소하고 상용구가 크게 증가하는 것을 보았습니다 ...

추신. 사람들이 이전 단락에 문제가 있다는 것을 알고 있으므로 조금 설명하겠습니다.

Setter와 Getter는 객체의 멤버를 조작 할 수 있기 때문에 OO 문제를 일으킨다 (오브젝트는 OWN 멤버를 조작해야 함). 이것은 클래스에서 작동하는 코드를 다른 클래스에 분산 시켜서 setter / getter 주위의 기능을 복사해야합니다. . 이것은 속성에도 적용됩니다. 속성이 더 쉬워서 모든 상황에서 "좋아"하지는 않습니다.

익명 내부 클래스의 코드는 전혀 재사용 할 수 없으며 사람들은 청취자와 같은 많은 것들이 본격적인 클래스 일 수 있고 있어야한다는 것을 잊어 버립니다. 이것은 클로저에도 적용됩니다! 익명의 내부 클래스를 사용하여 리스너와 같은 것을 구현했다면 코드를 메소드 또는 자체 클래스로 추출하여 대신 호출하는 것보다 구현을 복사하여 붙여 넣는 것보다 훨씬 낫습니다. 클로저는 재사용 성도 향상시킬 수 있습니다. 사용 방법에 따라 다릅니다.

많은 경우에 사용 가능한 기능은 코드 구성 방식을 결정합니다. OO는 모든 코드와 상호 작용 방식을 시각화하는 데 도움이 될 때 훨씬 강력하지만 다른 질문입니다.

계단이나 다른 피트니스 장비가 체중 감량을 제공 할 수있는 것보다 객체가 더 이상 코드 재사용을 제공 할 수 없습니다. 개발자는 도구를 올바르게 사용하도록 동기를 부여해야합니다.

소프트웨어 팀이 모든 세부 사항을 머리 속에 담는 것보다 테스트 된 코드를 재사용하는 데 더 높은 가치를 부여하면 훨씬 더 세분화 된 객체와 메소드를 볼 수 있으므로 더 많은 코드를 재사용 할 수 있습니다.

예

OOP는 더 많은 코드 재사용 방법을 제공합니다

아니

은 총알이 없다

때에 따라 다르지

당신이 그것에 넣은 것과 당신이 기대했던 것에 대한 것!

예. 우수한 객체 지향 프로그래밍은 관심사 분리, 낮은 커플 링, 높은 응집력 및 정보 숨기기를 촉진합니다. 이 모든 것은 재사용 가능한 코드에 중요합니다.

OOP의 주요 이점은 재사용이 아닌 모듈화 및 수정 가능성이라고 주장하지만 이는 또 다른 질문입니다.

객체는 코드 재발행을 가능하게하지만 가장 적합한 기술은 아닙니다. 상속, 다형성, 오버로드 및 템플릿과 같은 객체 관련 기술을 통해 코드 재사용이 촉진된다고 생각합니다.

그렇습니다. 수퍼 클래스 클리어에서 확장 (상속)하는 기능은 코드 재사용에 기여합니다. 누군가가 달리 주장 할 수 있는지 잘 모르겠습니다. 코드 재사용에 도움이되지 않으면 수퍼 클래스의 나머지를 사용하면서 클래스를 확장하고 하나의 메소드를 재정의 할 수 있습니다.

그것이 지금까지 코드 재사용 약속을 이행 했습니까? 예, OOP로 작성된 프로그램이 현명하게 디자인 패턴을 적용한다면 그렇지 않으면, 대부분 아닙니다. 그러나 Adobe 시스템, Google 등이 C ++ 또는 Java 또는 기타 OOP 언어로 작성하는 대규모의 사소한 프로그램의 인기를 살펴보면 OOP가 단계적으로 진행되기 전에 먼 길을 가고 있다고 말할 수 있습니다. 그 시간은이 질문을하기에 훨씬 더 적합 할 것이며 새로운 패러다임의 기초 작업을 제공하는 데 도움이 될 것입니다.