Про абстракцию
 

Друзья, по итогам года самоучительства ООП с вашей неоценимой (без иронии) помощью, потянуло на порассуждать.

Сделал вывод, что главное в ООП (имхо) - это не наследование и композиция, и даже не полиморфизм, а абстракция. Именно хорошая абстракция позволяет извлечь максимум пользы из всех остальных свойств ООП. Отметил для себя с удивлением, что в литературе и статьях этому аспекту уделяется мало внимания. Может от того, что это тяжело объяснять новичкам, которые не в теме... Чаще сразу напирают на практические аспекты ООП и их применение. Разве что в знаменитых "Паттернах проектирования" тема качественной абстракции как обязательного требования к хорошей архитектуре, рассмотрена на должном уровне.

У меня в проекте недостаточная или неточная абстракция - главная причина тупиковых ситуаций и последующих весьма комплексных изменений. Причём косячу в обе стороны. Когда начинал, грешил тем, что много чего рисовал под конкретный случай, а потом мучительно расширял. Теперь случается и в обратную сторону, когда решаешь какую-то ситуацию на высоком уровне абстракции, а она в итоге пригождается для единственного частного случая. Сейчас начинает появляться какая-то интуиция. Она напомнила ситуацию с музыкальным слухом, которого ещё недостаточно, чтобы спеть чисто, но уже хватает, чтобы услышать, что фальшивишь.

Выработал для себя пока такую тактику. При появлении частных случаев, выпадающих из уже построенной логики, не парюсь и программирую "в лоб", воткнув блок if. Если подобная частность возникает повторно, начинаю всерьёз задумываться о выделении её в качестве отдельной сущности.

На своих ошибках долго будешь учиться, постарайся влиться в проект к другим профессионалам.

Не надо сильно злоупотреблять абстракциями. Когда у тебя на каждую фигню будет по стопицот уровней абстракции, ты поймешь, что поддерживать этот код станет очень сложно

Tails, я бы и рад, да как говорится, грехи не пускают. У меня двое детей и флэт в ипотеке, мне всё это не вытянуть будет в случае столь радикальной смены карьеры.

caseyryan, я поэтому и написал, что в обе стороны ошибаюсь. Пока сформулировал для себя такое правило. Если блоков else if набирается больше двух по одному поводу, то пора задумываться о решении вопроса абстрактно.

Если ты не знаешь, в какую сторону будет двигаться проект – то иди по принципу DRY. Два if'а не заслуживают абстракции, но если есть повторение в 3 раза, то рефакторь, чтобы повторений не было.

Если же есть вся спека проекта, то попробуй порисовать сущности на бумажке, кто с кем связывается, кто к кому имеет доступ и всё такое, сводя абстракцию к минимуму.

Идеальный код = минимально необходимая абстракция. Больше – раздуто, меньше – костыльно.

Psycho Tiger, спасибо за наводку. С интересом про DRY прочитал. Как оказалось, сам интуитивно всего на разок ошибся :) Вообще, как мне представляется, сама философия ООП в значительной мере соответствует этому принципу.

Не там читаете :). А точнее большинство книг - про практическое применение ООП, что-то типа "документация ООП".
Дорогу в филосовское/академическое ОПП вам откроет SOLID. Если конечно ещё не встречали это.