“너무 객체 지향”

21

나는 강력한 OO 배경에서 왔으며 최근에 코드가 Java로 작성되었지만 익숙한 것보다 좋은 OO 디자인에 중점을 둔 조직에서 일하기 시작했습니다. 나는 "너무 많은 추상화"를 도입한다고 말했고, 대신 항상 수행되었던 방식을 코딩해야한다고하는데, 이는 Java의 절차 적 스타일이다.

TDD도 여기서 많이 연습하지는 않지만 테스트 가능한 코드를 원합니다. 대규모 "하나님 클래스"(이 팀의 표준 인 것으로 보임)에서 정적 개인 메소드에 비즈니스 로직을 묻는 것은 그리 테스트 할 수 없습니다.

나는 내 동기 부여를 동료들에게 명확하게 전달하는 데 어려움을 겪습니다. 누구든지 동료에게 OO 및 TDD를 사용하면 코드를보다 쉽게 유지 관리 할 수 있다고 확신시킬 수있는 방법에 대한 조언이 있습니까?

기술 부채에 관한 이 질문 은 내 질문과 관련이 있습니다. 그러나 나는 다른 질문이 다루고있는 사실을 빚을 갚는 것이 아니라 처음부터 부채가 발생 하지 않도록 노력하고 있습니다.

— ThuneGrill
소스

17

당신의 역할은 무엇입니까? 그런트 개발자? 당신은 망했다-더 나은 직업을 얻으십시오. 수석 개발자? 당신은 차이를 만들 수 있습니다 ...

— Matthew Flynn

2

열악한 디자인과 변하지 않는 사람들을 다루면서 기술 부채는 그리 많지 않습니다.

— ozz

1

나는 기술 및 비즈니스 논쟁을 알고 있으며, 이것을 모르는 것으로 보이는 동료들에게이 지식을 가장 잘 전달할 수있는 방법을 요구하고 있습니다. 그들은 많은 수업을 봅니다. 저는 테스트 가능하고 확장 가능한 시스템을

— 봅니다

5

죄송합니다. 떠나야합니다. 당신은 당신의 동료의 머리를 통해 이야기하고 있습니다. 프로젝트를 유지 보수 할 수 없을 때까지 변경되지 않습니다. 수동 테스트와 죽음 행진이 마음에 들지 않으면 다른 곳으로가는 것이 좋습니다.

— 케빈 클라인

4

문제의 코드를 보지 않으면 (예, 충분한 샘플을 제공하기가 어렵 기 때문에 여기서 판단을 믿어야 함) 실제로 OO가 부족하거나 과도하게 설계된화물 컬트를 추진하고 있는지 여부를 말하기는 어렵습니다 OO 이유는 아무 이유도 없습니다. 저는 모든 사람들이 과도하게 엔지니어링 된 OOP의 예를 보았는데 추상 공장 등을 생산하는 추상 공장의 층에 추상화가있는 곳입니다.

— Kromster는 Monica가

32

당신은 단지 당신이 좋아하는 것이 아니라 유지할 수 없다고 불평하지 않았습니다. 고의적 인 스타일 선택 인 경우, 결정적인 창의적 차이가있을 수 있으며, 스타일에 맞게 스타일을 조정하거나 선호하는 스타일에 맞는 곳을 찾아야합니다.

사람들은 항상 절차 적 스타일로 모듈 식이고 효율적이며 잘 요약되고 비교적 버그가없는 코드를 작성할 수 있습니다. Java는 그러한 상점에서 언어를 선택하는 이상한 선택이지만, 예를 들어 Android 용으로 개발해야하는 등 외부 요인이 언어를 결정한 경우 언어가 발생하는 것을 볼 수 있습니다.

모두 천재입니다. 그러나 나무를 오르는 능력으로 물고기를 판단하면 어리석은 짓을 믿으며 평생 살 것입니다. — 앨버트 아인슈타인

이 경우 였다 신중한 선택, 당신이 정말로 그들이 좋은 객체 지향 설계 원칙을 준수 얼마나 잘하여 그들을 판단 할 수 없습니다, 당신은 또한 리팩토링 따라 그들이 좋은 절차 적 설계 원칙을 준수 얼마나 잘에 의해 판단하고 있습니다. Java는 클래스 외부에서 코드를 작성할 수 없으므로 하나만 존재한다고해서 모듈이 객체 지향적임을 의도 한 것은 아닙니다.

다른 한편으로, 코드가 어느 패러다임 에서 혼란 스러우면 아마도 손실을 줄여야합니다.

— 칼 빌레펠트
소스

3

절차 적이고 지저분합니다. 그러나 나는 "너무 객체 지향"이라고 불리는 새로운 코드에 대해 이야기하고있다

— ThuneGrill

5

OO 코드로 확장되는 지저분한 절차 코드는 결국 개선이 아니며 혼란을 추가 할 수 있습니다.

— wirrbel

7

@ThuneGrill, 당신은 그들이 객체 지향 디자인의 무지에서 코딩 스타일을 선택했다고 가정하고 있습니다. 교육을받을 수 있다면 빛을 볼 수 있습니다. 강력한 객체 지향 언어로 수익성 높은 소프트웨어 비즈니스를 가진 사람이 지금까지 OOD의 이점을 조사하지 않았다면 "새로운 사람"이 그를 설득 할 방법이 없습니다. 그것에 대한 내 말과 다른 주석가의 말을 들어보십시오. 팀이 읽기 쉽도록 스타일을 조정할 수 없거나 조정하지 않으면 손실을 줄여야합니다.

— Karl Bielefeldt

3

@ThuneGrill : Karl이 맞습니다. 종교적인 이유가 아니라 실용적인 이유를 고수하십시오. OOP는 확실히 좋은 생각이지만, 나는 그것이 엄청나게 극단적 인 것을 보았습니다. 결과적으로 두더지에서 산을 만들었습니다. 1000 줄의 코드로 수행 할 수있는 일은 결국 클래스가 많은 10,000 줄입니다. 그렇다면, 유지하기가 어렵고 성능이 저하됩니다. (컬렉션 클래스가 어떻게 사용 되든 상관 없음)

— Mike Dunlavey

1

나는 당신이 이것에 대해 사람들을 설득 할 수 있다는 생각을 반드시 포기하지는 않을 것입니다. 힘든 일이지만 할 수 있습니다. 이 질문에 폐쇄 보이기 때문에, 참조 workplace.stackexchange.com/questions/9703/...을

— 에이미 Blankenship의

7

귀하의 질문을 읽으면서 Pragmatic Programmer라는 한 가지 팁을 기억했습니다.

그 팁 중 하나는 Be a Catalyst for Change다음과 같습니다.

해야 할 일과 수행 방법을 정확히 알고있는 상황 일 수 있습니다. 전체 시스템은 눈앞에 나타납니다. 그러나 모든 것을 다루기 위해 허가를 요청하면 지연과 공허한 응시를 만날 수 있습니다. 사람들은위원회를 구성하고 예산은 승인이 필요하며 상황은 복잡해질 것입니다. 누구나 자신의 자원을 보호 할 것입니다. 때때로 이것을 "스타트 업 피로"라고합니다.

이제 Stone Soup을 요리 할 차례입니다. 합리적으로 요구할 수있는 것을 해결하십시오. 잘 개발하십시오. 일단 그것을 얻으면 사람들을 보여주고 놀라게하십시오. 그런 다음 "물론 추가하면 좋을 것입니다."라고 말합니다. 중요하지 않은 척. 앉아서 원래 원하는 기능을 추가 할 것을 요구하기 시작할 때까지 기다립니다. 사람들은 지속적인 성공에 더 쉽게 참여할 수 있습니다. 그들에게 미래에 대한 엿보기를 보여 주면 당신은 그들을 둘러 볼 수 있습니다.

OO와 TDD에 대한 지식으로 좋은 일을 시작하면 곧 그들이 당신의 직업을 찾고 물어볼 것입니다.

— 로드리고
소스

노력하고 있지만 코딩하지 않은 동네 짱 건축가에게는 아무것도 없습니다.

— ThuneGrill

그가 TDD의 이점과 더 나은 OO (신뢰성, 생산성 등)를 알게 되 자마자주의를 기울일 것입니다!

— Rodrigo

3

새로운 업무 방식을 판매하려면 분명한 이점이 있어야합니다. 분명한 이점없이 모호한 더 많은 추상화 계층을 작성하는 것은 "미래에 도움이 될 수 있습니다"는 효과가 없습니다.

팩토리가 하나 이상의 유형의 객체를 만드는 팩토리를 만듭니다. 종속성 주입을 사용하면 즉시 이점이 표시됩니다. 실제로 하나 이상의 클래스에 의해 구현 될 인터페이스를 만듭니다.

"true OO"에서 너무 자주 볼 수있는 것은 매우 간단한 방법으로 매우 복잡한 문제를 해결하기 위해 고급 기술을 사용한다는 것입니다.

동일한 객체를 만들려는 경우 어떻게 공장의 이점을 보여줄 수 있습니까? 코드에서 고급 기술의 이점을 얻고 문제를 지적하고 해결하는 문제를 찾으십시오.

한 번에 한 번의 전투에서 승리합니다.

— 피터 B
소스

1

작은 코드 덩어리를 취하고 이점을 실현하기 위해 TDD 및 더 나은 OO 관행을 구현함으로써 만 설득 할 수 있습니다. 당신은 단지 좋은 엽서를 보여주지 않고 약속의 땅으로 그들을 인도했습니다.

확실히, 저는 오늘날 많은 코드 기반에서 과도하게 추상화 된 사례가 있다고 생각합니다. 필요한 것만 넣으십시오. 여기에는 추상화도 포함됩니다.

— 존 레이너
소스

1

방금 말한 것이 바로 전체 토론의 원인입니다. I는 기존 기능 위에 3-4 개의 추상화 만 도입했습니다

— ThuneGrill