Appleman
11.10.2018, 12:19
Друзья, по итогам года самоучительства ООП с вашей неоценимой (без иронии) помощью, потянуло на порассуждать.
Сделал вывод, что главное в ООП (имхо) - это не наследование и композиция, и даже не полиморфизм, а абстракция. Именно хорошая абстракция позволяет извлечь максимум пользы из всех остальных свойств ООП. Отметил для себя с удивлением, что в литературе и статьях этому аспекту уделяется мало внимания. Может от того, что это тяжело объяснять новичкам, которые не в теме... Чаще сразу напирают на практические аспекты ООП и их применение. Разве что в знаменитых "Паттернах проектирования" тема качественной абстракции как обязательного требования к хорошей архитектуре, рассмотрена на должном уровне.
У меня в проекте недостаточная или неточная абстракция - главная причина тупиковых ситуаций и последующих весьма комплексных изменений. Причём косячу в обе стороны. Когда начинал, грешил тем, что много чего рисовал под конкретный случай, а потом мучительно расширял. Теперь случается и в обратную сторону, когда решаешь какую-то ситуацию на высоком уровне абстракции, а она в итоге пригождается для единственного частного случая. Сейчас начинает появляться какая-то интуиция. Она напомнила ситуацию с музыкальным слухом, которого ещё недостаточно, чтобы спеть чисто, но уже хватает, чтобы услышать, что фальшивишь.
Выработал для себя пока такую тактику. При появлении частных случаев, выпадающих из уже построенной логики, не парюсь и программирую "в лоб", воткнув блок if. Если подобная частность возникает повторно, начинаю всерьёз задумываться о выделении её в качестве отдельной сущности.
Сделал вывод, что главное в ООП (имхо) - это не наследование и композиция, и даже не полиморфизм, а абстракция. Именно хорошая абстракция позволяет извлечь максимум пользы из всех остальных свойств ООП. Отметил для себя с удивлением, что в литературе и статьях этому аспекту уделяется мало внимания. Может от того, что это тяжело объяснять новичкам, которые не в теме... Чаще сразу напирают на практические аспекты ООП и их применение. Разве что в знаменитых "Паттернах проектирования" тема качественной абстракции как обязательного требования к хорошей архитектуре, рассмотрена на должном уровне.
У меня в проекте недостаточная или неточная абстракция - главная причина тупиковых ситуаций и последующих весьма комплексных изменений. Причём косячу в обе стороны. Когда начинал, грешил тем, что много чего рисовал под конкретный случай, а потом мучительно расширял. Теперь случается и в обратную сторону, когда решаешь какую-то ситуацию на высоком уровне абстракции, а она в итоге пригождается для единственного частного случая. Сейчас начинает появляться какая-то интуиция. Она напомнила ситуацию с музыкальным слухом, которого ещё недостаточно, чтобы спеть чисто, но уже хватает, чтобы услышать, что фальшивишь.
Выработал для себя пока такую тактику. При появлении частных случаев, выпадающих из уже построенной логики, не парюсь и программирую "в лоб", воткнув блок if. Если подобная частность возникает повторно, начинаю всерьёз задумываться о выделении её в качестве отдельной сущности.