Из-за бурного роста неконтрольной деятельности т.н. «черного» seo, завалившего весь интернет дорвеями и прочей хренью, понятие «поисковая оптимизация» теперь неразрывно связывается с понятием «проплаченное гуано», так же, как php связан быдлокод.
И есть стойкое ощущение, что при полном отсутствии усилий seo всех мастей результаты поиска «в среднем по интернету» были бы куда более справедливыми, чем это есть сейчас.
У меня в качестве такого бедняги 4 маленьких стеклянных ежика перед монитором. Пока всем 4ём расскажу — обязателньо находится баг. Отладка методом «резиновой уточки» :)
Для рассылки событий на сайте написать свой простой движок движок будет проще, чем найти и адаптировать готовый, тем более от которого вы хотите «тесной интеграции с БД». На java, например, для этого можно воспользоваться связкой JavaMail + Jdbc + Quartz. Это решит все проблемы, кроме Rich Formatting и UI.
Если я правильно понял, то согласно вашему заявлению единая теория поля в принципе не может быть построена на существующем базисе, т.к. уравнение для гравитации будет находиться в пространстве с размерностью, на единицу (то самое u) большей, чем остальные существующие уравнения для поля, например? Радикально :)
Если вам нужно значительно изменять состояние объекта, лучше это сделать методом. Если же нужно изменить только это свойство, и никаких side-эффектов то лучше — свойством.
Потому что операция AddDays логически изменяет не только это свойство, но и весь объект в целом. Клиент объекта со свойством ожидает, что методы могут менять состояние объекта как угодно, а операции над полем — только это поле. Не стоит его разочаровывать :)
Можно немного переделать ваш пример с БД — допустим, в сеттере свойства у объекта выставляется признак IsDirty, который говорит о том, что объект был изменен и теперь отличается от того, который счас лежит в БД. Не суть. Ответ я получил :)
Прежде всего, прочтите мой ответ выше (http://habrahabr.ru/blogs/development/59570/#comment_1618086). Я вас уверяю — я знаю, зачем они нужны.
Во-первых, пример был неудачен, и я на него указал, только и всего.
Во-вторых, ваш пример с БД также неудачен — я первым оторву руки тому, кто в сеттере или геттере напишет код доступа к данным в БД. Свойства имитируют поля, поэтому им следует копировать и семантику полей, а именно:
— они не должны обладать серьезными side-эффектами, типа запись чего-то в БД или отправка email на Марс;
— должно выполняться равенство (obj.SomeProperty == obj.SomeProperty), в противном случае очень легко нарваться на долгие ночные бдения под отладчиком.
Говорю вам как архитектор/техлидер проекта (C# + Spring.NET + NHibernate)
Тут еще вот какая вещь — программист-фрилансер постепенно отвыкает работать в команде и общаться, и начинает доверять только себе. Вплоть до того, что потом с ним невозможно работать — он принимал так много решений, ни с кем их не согласуя, что и дальше привык к своей 100% непогрешимости.
И если к дизайнеру это относится не так сильно (дизайнер и так сам себе жюри), то для программистов — настоящая беда.
И есть стойкое ощущение, что при полном отсутствии усилий seo всех мастей результаты поиска «в среднем по интернету» были бы куда более справедливыми, чем это есть сейчас.
Для рассылки событий на сайте написать свой простой движок движок будет проще, чем найти и адаптировать готовый, тем более от которого вы хотите «тесной интеграции с БД». На java, например, для этого можно воспользоваться связкой JavaMail + Jdbc + Quartz. Это решит все проблемы, кроме Rich Formatting и UI.
javaws — это не панель управления, это Java Web Start хелпер, для запуска файлов jnpl
Во-первых, пример был неудачен, и я на него указал, только и всего.
Во-вторых, ваш пример с БД также неудачен — я первым оторву руки тому, кто в сеттере или геттере напишет код доступа к данным в БД. Свойства имитируют поля, поэтому им следует копировать и семантику полей, а именно:
— они не должны обладать серьезными side-эффектами, типа запись чего-то в БД или отправка email на Марс;
— должно выполняться равенство (obj.SomeProperty == obj.SomeProperty), в противном случае очень легко нарваться на долгие ночные бдения под отладчиком.
Говорю вам как архитектор/техлидер проекта (C# + Spring.NET + NHibernate)
Тут еще вот какая вещь — программист-фрилансер постепенно отвыкает работать в команде и общаться, и начинает доверять только себе. Вплоть до того, что потом с ним невозможно работать — он принимал так много решений, ни с кем их не согласуя, что и дальше привык к своей 100% непогрешимости.
И если к дизайнеру это относится не так сильно (дизайнер и так сам себе жюри), то для программистов — настоящая беда.