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

Вот, к примеру, реализация кода шаблона проектирования Property Container.

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

В этой ветке по-другому получается редко.  


Стоит читать?

это так, художественная литература
читать можно, когда думать лень

по моему это ерунда какая-то, шаблон property - бесполезен, так как он не позволяет задать свои get/set методы для свойства, поэтому смысла я в нем не вижу, а второй вариант - довольно утомителен, в каждом новом классе писать одно и то-же?
я бы сделал что-то вроде:


что-бы можно было использовать так:

код скорее всего не рабочий, это просто иллюстрация идеи )

с помощью здравого смысла и такой-то матери  

Это сообщение отредактировал(а) Lazin - 4.12.2009, 15:34

Буду судить своей практики.

Проектированием могу заниматься только тогда, когда на это есть время! В рабочем режиме, как правило требуют результат "Димон, уже вчера надо было! У клиентов малвара бабло ворует, а ты тут думаешь!!!".

Одним словом встает ряд вопросов :
1) "Для кого пишется программа ?" 
2) "В каких условиях будет работать программа и всегда ли она будет работать только в этих условиях ?"
3) "Как быстро нужно эту программу написать ?"
4) "Что является самым главным в программе, что принесет заказчику бабло\экономии времени\качество хранения данных ?"
5) И самый главный вопрос, когда принято решение "ПИСАТЬ программу!" , это "Что будет если моя программа откажет ?", т.е. зная каковы последствия будут ожидать нас, мы будем знать как правильно завершится, т.е. что нужно сделать СТОПУДОВО !!!

Как правило клиент заказывает видя для себя мистические выгоды, что будут храниться документы, что программа ему всегда напомнит обо всем. Но он забывает что он может ноутбук\комп выключить или забыть включить! Или же админ почистил комп и с нес с автозагрузки и она у него пропала! Условий работы масса!!!

Первый и главный вопрос, считаю п.1. Потому что если клиент не знает какую выгоду принесет прога, то он будет тебе парить мозг!!! А если он скажет "Знаю что компы посчитают эту хрень за 1 час, а я бы считал за 2 дня" или "Пока эти документы подготовлю, у меня уже пенни по ...., вот если ваша прога в нужный день за эн дней до срока сделает, то.... 
Только зная с кем рабоешь ты будешь четко знать - будет ли он хавать тебе мозг ? Сделанная четко по целям клиента прога дает тебе ФАНАТОВ , а это твои бабки!!!

 А когда нет времени - то проектированию надо уделить гораздо больше времени, чем когда оно есть ;)
К сожалению ихз реальной жизни.

Естественно никто не будет ничего проектировать для продукта <$1k, но мелкие продукты без посл. доработки и не требовательны к проектированию.

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