기능적인 JavaScript 코드를 객체 지향 디자인으로 변환 할 가치가 있습니까?

Question

저는 현재 상당한 양의 JavaScript가 포함 된 소규모 웹 응용 프로그램을 만들고 있습니다. 초기 아이디어를 프로토 타이핑 할 때, 나는 몇 가지 기능을 해킹하여 애플리케이션이 결국 객체 지향적 인 성격의 자바 스크립트를 다시 작성하려고하는 방식을 보여주었습니다.

구현 단계로 넘어 갔으므로 객체 지향적 인 목적으로 객체 지향 JavaScript를 만드는 것이 잔인한 것처럼 보입니다. 프로젝트는 앞으로 큰 수정을 요구하지 않을 것입니다. 이는 객체 지향 설계와 보증이 될 것입니다. 대신, 나는 일련의 간결하고 응집력있는 함수가 잘 작동하고 있음을 발견했다.

KISS 원칙을 고수하려고하면서 함수 집합이 문제에 대한 적절한 해결책을 제공 할 때 코드를 객체 지향 설계로 변환 할 필요가있는 다른 이유가 있습니까? ?

Answer 1

아니요, 개인적으로 OOP를 더 맛있게 보더라도, 그것은 끝까지의 수단이지 결코 끝이 아닙니다. 절차 적 프로그래밍이 OOP보다 더 의미가있는 경우가 많이 있습니다. 변환을 위해 변환하는 것은 지나치게 과장 될 수 있습니다.

Answer 2

아니요, 앞으로 나아가고 앞으로 나아가십시오. 내 생각에 더 생산적입니다.

Answer 3

코드가 잘 구성되어 있고, 잘 배치되어 있고, 주석이 잘 붙어 있고, 필요한 작업을 수행하고 있다면, 그 밖의 다른 이유로 기능을 추가하는 것이 바람직하지 않습니다.

프로그램이 멋지게 OOP 등이라고 말하는 것이 좋을 수도 있지만 작동하도록 변경할 필요가 없다면 나는 그것을 그대로두고 간다.

가 파산 아닌가요 경우

는, 그것으로 fidgit 해달라고 : 레거시 코드로

Answer 4

취급을 지금부터. 뭔가를 바꾸고 싶을 때 코드를 리팩토링하면 코드가 마음에 편해집니다. 약간의 OOP가 필요한 경우 사용하십시오. 그렇지 않으면하지 마십시오.

OOP는 해머입니다. 나사와 같은 문제는 손톱으로 취급하지 마십시오.

Answer 5

작동하고 유지 관리가 쉽다면 변환을 위해 변환하지 않아도됩니다. 더 흥미로운 일이 있어야합니다.

Answer 6

이 코드가 이미 구현되어 있고 유지 보수가 필요하지 않거나 더 나은 업그레이드가 필요하다면 계속 사용하십시오. 지금 구현하려고하고 복잡해질 수 있다면 OO 접근법을 고려하십시오.

경험상 복잡성은 낮지 만 절차 적 코드를 작성하고 유지하는 것이 쉽지만 일정한 임계 값 이후 절차 적 프로그래밍을 사용하는 동안 복잡성을 증가시키는 것이 점점 더 어려워지고있는 반면, OOP는 시작하기가 더 어렵지만, 복잡성을 훨씬 관리하기 쉽게 유지합니다.

최종선 : 작업이 간단하거나 이미 구현 된 경우에는 간단하게 유지하십시오. 좀 더 복잡 해지면 OOP를 고려하십시오.

Answer 7

마음에두고 그냥 개체 자바 스크립트에서 만드는 데 오히려 비용이 많이 듭니다.

개체를 최소한으로 유지하십시오.

Answer 8

나는 결정하기 전에 코드를 검토 할 가치가 있다고 말할 것입니다. "코드 다시 작성"의 단점은 코드가 이전과 동일하게 작동하는지 테스트하기위한 비용이 든다는 것입니다. 유닛 테스트가 있습니까? 그렇지 않으면 테스트 비용이 훨씬 더 높습니다. 그래서 일반적으로, 다른 목적을 위해 사용하지 않는 한 작업 코드를 다시 작성하는 것에 반대합니다. 이제는 필요한 새로운 기능을 더 쉽게 작성할 수 있습니다 (즉, 일반적인 함수 등을 리펙토링하는 것).

한 사람이 "나는 함께 해킹했다"고 말하면서 코드를 다시 볼 가치가 있다고 제안합니다. 왜 처음부터 함께 해킹 당했습니까? 나는 많은 사람들이 객체 지향 코드가 그 자체로 끝나지 않는다고 말하고 있지만, 그 후에 생각할 필요가없는 방법론이다. 당신은 자연스럽게 일을 시작합니다.

아마도 js가 비교적 간단 할 수 있으며, 따라서 OO 스카 폴딩은 진정으로 여분의 오버 헤드입니다. 벌금. 하지만 여전히 해킹 된 코드를 리뷰 작성 (특히 다른 사람에게 검토)시켜야한다고 제안합니다. 아마도 그것은 프로이트의 미끄럼틀 이었지만 ... 미끄러졌습니다.