결정의 효율성이란 결정의 품질을 의미하며, 여기서 메커니즘(및 프로그램은 의심할 여지 없이 메커니즘)이 가장 안정적으로 작동합니다. 메커니즘은 명확하고 일관성 있고 생산적이어야 합니다. 메커니즘의 기능은 할당된 모든 작업을 구현해야 합니다. 메커니즘은 불필요한 것을 허용하지 않으며이 메커니즘의 개발에서 불필요한 것은 차단해야합니다.
나는 여기서 holivar를 만들고 싶지 않지만 OOP 지지자가 OOP가 없는 솔루션보다 이 솔루션이 더 효율적이라는 것을 분명히 알 수 있는 일부 문제를 해결하는 코드를 여기에 제공할 수 있는지 궁금합니다.
저는 OOP가 없는 문제 해결사이고 OOP가 있는 문제 해결사와 경쟁하고 싶습니다.
나는 당신에게 설명하려고 노력할 것입니다. 당신이 계약자이고 끊임없이 일을 던지는 고객이 있다고 가정 해 봅시다 .. 그리고 5-6 개의 주문 후에 당신은 그의 모든 작업이 어떤 의미에서 같은 유형이라는 것을 알게됩니다 .. 그리고 템플릿으로 결합할 수 있다는 것 .. 또한 고객은 이러한 템플릿을 서로 많은 수로 결합하는 것을 좋아합니다. OOP의 관점에서 보면 결과가 위치할 템플릿을 생성해야 합니다. 클래스 내에서 계산됨) 그런 다음 고객이 다시 어려운 작업을 수행하면 이 템플릿(클래스)의 원하는 수 인스턴스(예: 10개)를 만들고 속성(생성자에서)을 설정하기만 하면 됩니다. 고객이 제안한 각각의 주문... 결과적으로 주문을 열기로 한 결정은 10개의 각 인스턴스와 모든 항목에서 결과를 살펴보는 루프를 기반으로 합니다. 이러한 주문을 리벳팅할 수 있습니다. 5 분..
그리고 OOP가 없으면 복사본을 만들 수 없으며 거의 모든 것을 다시 실행해야 하며 변경 사항으로 인해 손상되지 않기를 바랍니다. 결과적으로 훨씬 더 많은 시간이 소요됩니다. ..
결론: OOP를 아는 프로그래머는 문제(OOP에 적합한)를 훨씬 더 빠르고 훨씬 적은 오류로 해결할 수 있습니다.
나는 당신에게 설명하려고 노력할 것입니다. 당신이 연기자이고 끊임없이 일을 던지는 고객이 있다고 가정 해 봅시다 .. 그리고 5-6 개의 주문 후에 당신은 그의 모든 작업이 어떤 의미에서 같은 유형임을 알 수 있습니다 .. 그리고 템플릿으로 결합할 수 있다는 것 .. 또한 고객은 이러한 템플릿을 서로 많은 수로 결합하는 것을 좋아합니다. OOP의 관점에서 결과가 위치할 템플릿을 생성해야 합니다. 클래스 내에서 계산됨) 그런 다음 고객이 다시 어려운 작업을 수행하면 이 템플릿(클래스)에 필요한 수의 인스턴스(예: 10개)를 만들고 속성(생성자에서)을 설정하기만 하면 됩니다. 고객이 제안한 각각의 주문... 결과적으로 주문을 열기로 한 결정은 10개의 인스턴스 각각에서 결과를 살펴보는 주기를 기반으로 합니다. 5분 안에 그러한 명령을 거부합니다.
그리고 OOP가 없으면 복사본을 만들 수 없으며 거의 모든 것을 다시 실행해야 하며 변경 사항으로 인해 손상되지 않기를 바랍니다. 결과적으로 훨씬 더 많은 시간이 소요됩니다. ..
결론: OOP를 아는 프로그래머는 문제(OOP에 적합한)를 훨씬 더 빠르고 훨씬 적은 오류로 해결할 수 있습니다.
어쩌면 당신이 옳습니다. 나는 주문을 완료 한 적이 없고 고객이 무엇을 원하는지 모릅니다. 당신이 설명하는 것은 일상적인 작업과 비슷하며 여기서 개발에 대해 이야기하고 있습니다. 아마도 일상적인 작업(팀에서 수행하는 작업)의 경우 OOP는 대체할 수 없습니다. 저는 그런 경험이 없어서 잘 모르겠습니다.
OOP 없이 하지 않는 것이 더 나은 동일한 유형의 이러한 작업에 대한 구체적인 예를 제공할 수 있습니까?
그러나 유지 관리, 확장성 및 타사의 사용 용이성 측면에서 TS(Karputov가 아니라 Peter)를 밀어붙이는 것은 석기 시대에 불과합니다.
나는 모든 프로그래머가 코드의 효율성과 다양성이 이 코드가 좋은 것을 의미하지 않는다는 것을 이해하기 위해 이상적으로는 4명 이상의 팀에서 작업해야 한다는 강한 의견을 가지고 있습니다.
오, 팀워크는 완전히 다른 이야기입니다! 그리고 프로그래머 팀을 관리하는 것은 참가자 수와 같은 정도의 노래입니다.
토요일 저녁에 이야기를 들려드리겠습니다. 우리 회사가 철 조각을 뿌렸을 때. 죄송합니다. 반복이 이야기를 독살시켰을 수도 있습니다.
상사가 저에게 전화를 걸어 묻습니다. 직장에서 매우 바쁘십니까? 나는 그렇게 많이 말하지 않는다.
-지금 뭐하고있어? 상사는 나 자신에게 지속적인 결근을 포함하는 개인 일정을 가지고 있기 때문에 내가 무엇을 하고 있는지 전혀 몰랐습니다))
예, 조정자를 위한 장비 테스트 패키지를 작성 중입니다. 추장은 매우 기뻤습니다. 훌륭합니다. 시베리아의 조건에서 그것을 경험할 수 있습니다. Aleksey, 글쎄, 우리는 날아야합니다. 사람들은 거기에 붙어있어 알아낼 수 없습니다. 글쎄, 필요하다, 필요하다, 나는 일반적으로 출장, 완전한 자유를 좋아했습니다.
내가 Krasnoyarsk에 도착하고, 그 남자들이 나를 만나고, 나는 그들이 어떻게든 죄책감을 가지고 행동하고, 분명히 구겨집니다. 우리는 카페에 가서 술을 마시고 이야기를 나눕니다. 무엇이 작동하지 않는지 묻습니다. 거기 실장님은 이미 헤매고 계시고, 3개월째 출장을 다녀오셨고, 어느 지점에 갇히셨습니다. 그는 송금을 통해서만 돈을 보낼 수 있습니다.
글쎄, 그들은 열었습니다. 우리는 시베리아 마을에 도착했고, 기다리기 위해 들렀습니다. 그리고 두 명의 젊은 자매가 있었습니다. 글쎄, 사랑이 돌기 시작했고 친구도 끌려서 아무도 화를 내지 않았습니다.
나는 당신을 포기하지 않겠다고 말합니다. 나 자신도 마찬가지입니다. 하지만 계속 전진해야 합니다. 이렇게하자. 전체 화환을 설정하고 쓰레기 만 남고 500km가 남습니다. 그러면 내가 보상하겠습니다. 상사로부터 돈을 갈취하고 당신과이 친구들은 새해 전날을 축하합니다. 알겠습니까?
이제 여자들은 분개하겠지만, Lyokha가 먼저 동의했습니다. 그는 내 아내가 출산해야 한다고 말합니다. 여기서 마음을 바꾸는 것이 좋습니다! 모두 결혼했고 어떤 이유로 아무도 집에 서두르지 않았습니다.)))
그러나 나는 젊고 아름다운 시베리아 인들이 그들을 기다리고있을 때 남자들이 어떻게 쟁기질 할 수 있는지 직감으로 이해했습니다))
논거는 전혀 아닙니다. OOP를 사용하거나 사용하지 않고 모든 작업을 해결할 수 있습니다. OOP가 없으면 다시 사용할 통합 기능을 쉽게 만들 수 있으며 변경 사항으로 인해 전체 프로그램이 중단되지 않습니다. OOP를 사용하면 코드가 조금 더 늘어납니다. OOP를 사용하면 가독성이 향상됩니까? 엑스 각 클래스가 별도의 파일에 저장되어 있고 각 함수도 별도의 파일에 저장되어 있습니다. 습관과 편리함의 문제일 뿐입니다.
논거는 전혀 아닙니다. OOP를 사용하거나 사용하지 않고 모든 작업을 해결할 수 있습니다. OOP가 없으면 다시 사용할 통합 기능을 쉽게 만들 수 있으며 변경 사항으로 인해 전체 프로그램이 중단되지 않습니다. OOP를 사용하면 코드가 조금 더 늘어납니다. OOP를 사용하면 가독성이 향상됩니까? 엑스 각 클래스가 별도의 파일에 저장되어 있고 각 함수도 별도의 파일에 저장되어 있습니다. 습관과 편리함의 문제일 뿐입니다.
여기 이 주제에서는 OOP 없이 해결할 수 있는 작업의 예가 있지만 그다지 합리적이지 않습니다.
논거는 전혀 아닙니다. OOP를 사용하거나 사용하지 않고 모든 작업을 해결할 수 있습니다. OOP가 없으면 다시 사용할 통합 기능을 쉽게 만들 수 있으며 변경 사항으로 인해 전체 프로그램이 중단되지 않습니다. OOP를 사용하면 코드가 조금 더 늘어납니다. OOP를 사용하면 가독성이 향상됩니까? 엑스 각 클래스가 별도의 파일에 저장되어 있고 각 함수도 별도의 파일에 저장되어 있습니다. 습관과 편리함의 문제일 뿐입니다.
나는 개인 개발에 OOP가 필요하지 않다고 절대적으로 확신할 수 있지만, 대규모 프로젝트에서 팀의 작업에 대해 완전한 확신은 없습니다. 다양한 프로그래머들이 만든 코드를 개발하고 연결하는 것은 생각해본 적도 없고, 어떻게 구현해야 할지 모르겠습니다. 이것이 내가 현재 수용하는 개발에서 OOP를 지지하는 유일한 주장입니다.
Реter Konow : 나는 개인 개발에 OOP가 필요하지 않다고 절대적으로 확신할 수 있지만, 대규모 프로젝트에서 팀의 작업에 대해 완전한 확신은 없습니다. 다양한 프로그래머들이 만든 코드의 개발과 연결은 제가 생각해 본 적이 없고, 어떻게 제 마음대로 구현해야 할지 모르겠습니다. 이것이 내가 현재 수용하는 개발에서 OOP를 지지하는 유일한 주장입니다.
효과적인 솔루션이란 무엇을 의미합니까?
결정의 효율성이란 결정의 품질을 의미하며, 여기서 메커니즘(및 프로그램은 의심할 여지 없이 메커니즘)이 가장 안정적으로 작동합니다. 메커니즘은 명확하고 일관성 있고 생산적이어야 합니다. 메커니즘의 기능은 할당된 모든 작업을 구현해야 합니다. 메커니즘은 불필요한 것을 허용하지 않으며이 메커니즘의 개발에서 불필요한 것은 차단해야합니다.
그렇지 않으면 발전이 없거나 효율성이 없을 것입니다.
추신. 이것은 제 생각일 뿐 누구에게도 강요하지 않습니다.
나는 OOP의 팬이 아닙니다.
그러나 유지 관리, 확장성 및 타사의 사용 용이성 측면에서 TS(Karputov가 아니라 Peter)를 밀어붙이는 것은 석기 시대에 불과합니다.
나는 모든 프로그래머가 코드의 효율성과 다양성이 이 코드가 좋은 것을 의미하지 않는다는 것을 이해하기 위해 이상적으로는 4명 이상의 팀에서 작업해야 한다는 강한 의견을 가지고 있습니다.
나는 여기서 holivar를 만들고 싶지 않지만 OOP 지지자가 OOP가 없는 솔루션보다 이 솔루션이 더 효율적이라는 것을 분명히 알 수 있는 일부 문제를 해결하는 코드를 여기에 제공할 수 있는지 궁금합니다.
저는 OOP가 없는 문제 해결사이고 OOP가 있는 문제 해결사와 경쟁하고 싶습니다.
나는 당신에게 설명하려고 노력할 것입니다. 당신이 계약자이고 끊임없이 일을 던지는 고객이 있다고 가정 해 봅시다 .. 그리고 5-6 개의 주문 후에 당신은 그의 모든 작업이 어떤 의미에서 같은 유형이라는 것을 알게됩니다 .. 그리고 템플릿으로 결합할 수 있다는 것 .. 또한 고객은 이러한 템플릿을 서로 많은 수로 결합하는 것을 좋아합니다. OOP의 관점에서 보면 결과가 위치할 템플릿을 생성해야 합니다. 클래스 내에서 계산됨) 그런 다음 고객이 다시 어려운 작업을 수행하면 이 템플릿(클래스)의 원하는 수 인스턴스(예: 10개)를 만들고 속성(생성자에서)을 설정하기만 하면 됩니다. 고객이 제안한 각각의 주문... 결과적으로 주문을 열기로 한 결정은 10개의 각 인스턴스와 모든 항목에서 결과를 살펴보는 루프를 기반으로 합니다. 이러한 주문을 리벳팅할 수 있습니다. 5 분..
그리고 OOP가 없으면 복사본을 만들 수 없으며 거의 모든 것을 다시 실행해야 하며 변경 사항으로 인해 손상되지 않기를 바랍니다. 결과적으로 훨씬 더 많은 시간이 소요됩니다. ..
결론: OOP를 아는 프로그래머는 문제(OOP에 적합한)를 훨씬 더 빠르고 훨씬 적은 오류로 해결할 수 있습니다.
나는 당신에게 설명하려고 노력할 것입니다. 당신이 연기자이고 끊임없이 일을 던지는 고객이 있다고 가정 해 봅시다 .. 그리고 5-6 개의 주문 후에 당신은 그의 모든 작업이 어떤 의미에서 같은 유형임을 알 수 있습니다 .. 그리고 템플릿으로 결합할 수 있다는 것 .. 또한 고객은 이러한 템플릿을 서로 많은 수로 결합하는 것을 좋아합니다. OOP의 관점에서 결과가 위치할 템플릿을 생성해야 합니다. 클래스 내에서 계산됨) 그런 다음 고객이 다시 어려운 작업을 수행하면 이 템플릿(클래스)에 필요한 수의 인스턴스(예: 10개)를 만들고 속성(생성자에서)을 설정하기만 하면 됩니다. 고객이 제안한 각각의 주문... 결과적으로 주문을 열기로 한 결정은 10개의 인스턴스 각각에서 결과를 살펴보는 주기를 기반으로 합니다. 5분 안에 그러한 명령을 거부합니다.
그리고 OOP가 없으면 복사본을 만들 수 없으며 거의 모든 것을 다시 실행해야 하며 변경 사항으로 인해 손상되지 않기를 바랍니다. 결과적으로 훨씬 더 많은 시간이 소요됩니다. ..
결론: OOP를 아는 프로그래머는 문제(OOP에 적합한)를 훨씬 더 빠르고 훨씬 적은 오류로 해결할 수 있습니다.
어쩌면 당신이 옳습니다. 나는 주문을 완료 한 적이 없고 고객이 무엇을 원하는지 모릅니다. 당신이 설명하는 것은 일상적인 작업과 비슷하며 여기서 개발에 대해 이야기하고 있습니다. 아마도 일상적인 작업(팀에서 수행하는 작업)의 경우 OOP는 대체할 수 없습니다. 저는 그런 경험이 없어서 잘 모르겠습니다.
OOP 없이 하지 않는 것이 더 나은 동일한 유형의 이러한 작업에 대한 구체적인 예를 제공할 수 있습니까?
나는 OOP의 팬이 아닙니다.
그러나 유지 관리, 확장성 및 타사의 사용 용이성 측면에서 TS(Karputov가 아니라 Peter)를 밀어붙이는 것은 석기 시대에 불과합니다.
나는 모든 프로그래머가 코드의 효율성과 다양성이 이 코드가 좋은 것을 의미하지 않는다는 것을 이해하기 위해 이상적으로는 4명 이상의 팀에서 작업해야 한다는 강한 의견을 가지고 있습니다.
오, 팀워크는 완전히 다른 이야기입니다! 그리고 프로그래머 팀을 관리하는 것은 참가자 수와 같은 정도의 노래입니다.
토요일 저녁에 이야기를 들려드리겠습니다. 우리 회사가 철 조각을 뿌렸을 때. 죄송합니다. 반복이 이야기를 독살시켰을 수도 있습니다.
상사가 저에게 전화를 걸어 묻습니다. 직장에서 매우 바쁘십니까? 나는 그렇게 많이 말하지 않는다.
-지금 뭐하고있어? 상사는 나 자신에게 지속적인 결근을 포함하는 개인 일정을 가지고 있기 때문에 내가 무엇을 하고 있는지 전혀 몰랐습니다))
예, 조정자를 위한 장비 테스트 패키지를 작성 중입니다. 추장은 매우 기뻤습니다. 훌륭합니다. 시베리아의 조건에서 그것을 경험할 수 있습니다. Aleksey, 글쎄, 우리는 날아야합니다. 사람들은 거기에 붙어있어 알아낼 수 없습니다. 글쎄, 필요하다, 필요하다, 나는 일반적으로 출장, 완전한 자유를 좋아했습니다.
내가 Krasnoyarsk에 도착하고, 그 남자들이 나를 만나고, 나는 그들이 어떻게든 죄책감을 가지고 행동하고, 분명히 구겨집니다. 우리는 카페에 가서 술을 마시고 이야기를 나눕니다. 무엇이 작동하지 않는지 묻습니다. 거기 실장님은 이미 헤매고 계시고, 3개월째 출장을 다녀오셨고, 어느 지점에 갇히셨습니다. 그는 송금을 통해서만 돈을 보낼 수 있습니다.
글쎄, 그들은 열었습니다. 우리는 시베리아 마을에 도착했고, 기다리기 위해 들렀습니다. 그리고 두 명의 젊은 자매가 있었습니다. 글쎄, 사랑이 돌기 시작했고 친구도 끌려서 아무도 화를 내지 않았습니다.
나는 당신을 포기하지 않겠다고 말합니다. 나 자신도 마찬가지입니다. 하지만 계속 전진해야 합니다. 이렇게하자. 전체 화환을 설정하고 쓰레기 만 남고 500km가 남습니다. 그러면 내가 보상하겠습니다. 상사로부터 돈을 갈취하고 당신과이 친구들은 새해 전날을 축하합니다. 알겠습니까?
이제 여자들은 분개하겠지만, Lyokha가 먼저 동의했습니다. 그는 내 아내가 출산해야 한다고 말합니다. 여기서 마음을 바꾸는 것이 좋습니다! 모두 결혼했고 어떤 이유로 아무도 집에 서두르지 않았습니다.)))
그러나 나는 젊고 아름다운 시베리아 인들이 그들을 기다리고있을 때 남자들이 어떻게 쟁기질 할 수 있는지 직감으로 이해했습니다))
논거는 전혀 아닙니다.
OOP를 사용하거나 사용하지 않고 모든 작업을 해결할 수 있습니다. OOP가 없으면 다시 사용할 통합 기능을 쉽게 만들 수 있으며 변경 사항으로 인해 전체 프로그램이 중단되지 않습니다. OOP를 사용하면 코드가 조금 더 늘어납니다. OOP를 사용하면 가독성이 향상됩니까? 엑스
각 클래스가 별도의 파일에 저장되어 있고 각 함수도 별도의 파일에 저장되어 있습니다. 습관과 편리함의 문제일 뿐입니다.
바로 표면에 있는 또 다른 간단한 예입니다. 메타에디터의 어드바이저 생성기... 프로그래밍 방법조차 모르는 사람은 10초 안에 수많은 지표와 조건으로 구성된 어드바이저를 리벳팅할 수 있습니다)) ) 그리고이 모든 것이 OOP입니다))
논거는 전혀 아닙니다.
OOP를 사용하거나 사용하지 않고 모든 작업을 해결할 수 있습니다. OOP가 없으면 다시 사용할 통합 기능을 쉽게 만들 수 있으며 변경 사항으로 인해 전체 프로그램이 중단되지 않습니다. OOP를 사용하면 코드가 조금 더 늘어납니다. OOP를 사용하면 가독성이 향상됩니까? 엑스
각 클래스가 별도의 파일에 저장되어 있고 각 함수도 별도의 파일에 저장되어 있습니다. 습관과 편리함의 문제일 뿐입니다.
여기 이 주제에서는 OOP 없이 해결할 수 있는 작업의 예가 있지만 그다지 합리적이지 않습니다.
논거는 전혀 아닙니다.
OOP를 사용하거나 사용하지 않고 모든 작업을 해결할 수 있습니다. OOP가 없으면 다시 사용할 통합 기능을 쉽게 만들 수 있으며 변경 사항으로 인해 전체 프로그램이 중단되지 않습니다. OOP를 사용하면 코드가 조금 더 늘어납니다. OOP를 사용하면 가독성이 향상됩니까? 엑스
각 클래스가 별도의 파일에 저장되어 있고 각 함수도 별도의 파일에 저장되어 있습니다. 습관과 편리함의 문제일 뿐입니다.
나는 개인 개발에 OOP가 필요하지 않다고 절대적으로 확신할 수 있지만, 대규모 프로젝트에서 팀의 작업에 대해 완전한 확신은 없습니다. 다양한 프로그래머들이 만든 코드의 개발과 연결은 제가 생각해 본 적이 없고, 어떻게 제 마음대로 구현해야 할지 모르겠습니다. 이것이 내가 현재 수용하는 개발에서 OOP를 지지하는 유일한 주장입니다.
이것은 주요 주장이 아닙니다.
글쎄요, 절차적 프로그래밍에는 다형성 의 유사점이 없습니다.