fixxer foxovik
2 fixxer
Ну чем это отличается от Фокса или C# или VB.NET?
В фоксе чуть больше наследования и реже делегирование. В яве чаще делегирование и реже наследование. Что в лоб, что по лбу... :-)

Не путайте кислое с пресным. Наследование и делегирование это просто два разных механизма расширения функциональности существующих классов. Говорить что где чаще/реже используется некорректно. Почитайте GoF, там в начале описана разница, преимущества и недостатки.

Интересно, а каким образом GoF может помочь в данном случае?

Убедить, что RAD средства это скучно, а потому нужно писать код в ручную превращая его в нагромаждение изумительным образом взаимодействующих объектов?

Ну..., такой подход тоже имеет право на жизнь :)

foxovikЯ иногда делаю наследование даже не переопределяя ни одного метода и ни одного свойства. Исключительно как задел на будующее.
...
Почему этот подход никому не нравится из здесь присутствующих?


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

Проведение всестороннего анализа будущих изменений тербований дело заманчивое, но крайне не надёжное. Между тем занятие это требует большого вложения труда и средств, окупаемость которых остаётся под вопросом, т.к. нет никакой гарантии, что предполагаемые события когда-нибудь наступят.

Поэтому бытует мнение (особенно в среде приверженцев экстремального программирования и разработки управляемой тестами), что никаких заделов на будущее делать не нужно.

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

Тем не менее, для ряда проектов такой подход чреват проблемами, что не удивительно, т.к. следования всякого рода эвристикам (к числу которых относятся и ООА, и ТDD, да и любой процесс разработки) не может гарантировать получения результата за конечное число шагов :)
Здесь на помощь должен придти здравый смысл, который говорит:
Если верятность будущих изменений велика, то, прежде чем завершить фрагмент кода, нужно хорошенько подумать - а легко ли будет при не обходимости преобразовать текущее решение для реализации этих изменений?
Ну, а принятие решения по этому вопросу упирается прежде всего в индивидуальный опыт программиста или команды разработчиков.

Имхо, дать практически полезные рекомендации, не зная тонкостей решаемой задачи, тут не возможно.