일단 객체지향을 하지 말잔건 당연하게도 아님.
그거야말로 약팔이고 딱히 들을 가치가 없음.
다만... 객체지향을 처음 아 이해했다 한뒤... 그 직관적임에 취해서 너무 직관적으로 프로그래밍을 하거나
아니면 어느정도 짬빠가 쌓인 다음에도 단순히 설계하는게 귀찮아서 직관적으로 프로그래밍을 하면
굉장히 비효율적일수도 있다고 생각함.
처음 객체를 짤때부터 그 효율성을 중심으로 설계를 해야지. 아 모든것은 객체. 이것도 객체 저것도 객체 해버리면
두가지 문제가 있는데
1. 성능이 처참해짐.
가령 카드게임을 만든다 치면 특정 카드의 능력치를 다른 카드로 합할때 그냥 수치만 가져오면 되는데... 그걸 그짓거리를 할때마다 카드 객체를 삭제 안하고 그대로 소환해서 그런 카드가 수십장 수백장이 되면 뭔 카드게임 렉이 3d게임하고 삐까뜰 지경임. 개인적으로 하스스톤이 이딴식으로 만들지 않았나 의심을 하고 있음. 전장에서 기계하고 악마만 하면 렉이 심한데 정황상... 다른 카드 참고하는 경우가 많고 게임특성상 몇십장 몇백장 쳐먹는 경우도 많아서...
2. 구조적으로 취약해짐.
사실 성능 문제는 좀 부차적이긴 함. 하스스톤도 뭐 멀쩡히 잘 돌아가고 있고... 아니 언제 망할지 모르지만 어쨌든 코드가 개떡같아서 망한건 아니고 10년 넘게 하다가 망하면 호상이기도 하고 근데 진짜 문제는 그렇게 무차별적으로 이것도 객체 저것도 객체 하는 식으로 해버리면... 필연적으로 서로 간에 참조하는 거대한 스파게티가 완성되며... 이는 성능은 물론이오 생산성이나 유지보수성에 필연적으로 악영향을 끼치고 결국....
설계를 할때 같은걸 표현하면서도 최대한 단순하게. 서로 참조를 덜하도록 설계해야 하는데....
결국 시간도 부족하고 컨디션도 개떡같으면 좀 병신같은걸 알면서도 직관적으로 짜겠지 뭐
이제까지 그랬듯이 아프로도...
맞음. 세상에 절대적으로 옳은 신념체계는 없는듯. 목적과 가용자원에 맞게 배합을 잘 해야지. 적정기술의 중요성 ㅇㅅㅇ
이 모든것은 객체다
최대한 단순하게 서로 참조를 덜하도록 설계를 하는게 객체지향임 그렇게 안하고 의존도 막 섞이는건 주로 백엔드에서 rdbms의 데이터 구조를 클래스에다가 끼워맞춰서 그러는거고 성능은 딸리는게 맞는데 2번은 객체지향이 문제가 아니라 객체지향이 아닌걸 객체지향이라고 우기는게 문제 ㅇㅇ