Одно из ключевых преимуществ MVC в том, что V и C можно при желании безболезненно отрезать и использовать только M. Или наоборот — подменить одно M на другое без необходимости что-то менять в V и C. Как в вашем «этом, скорее, логическом разделении на три группы. Например, функций-членов.» провернуть вышеописанное?
> Мой опыт показал: проще реализовать всю кухню внутри одного класса, чем искусственно делить на некие абстракции, которые к тому же слишком сильно связаны, что грозит адскими интерфейсами
Пример: я хочу использовать вашу систему объектов с её, судя по описаниям, невероятно сложной алгоритмической нагрузкой. Но с небольшим отличием: я хочу разместить ваш код на сервере приложений и дёргать его через веб. Вопрос: зачем мне впились ваши Button и ComboBox в классах бизнес-логики?
FYI, «sic» означает, что приведённая цитата написана именно так. Например, если в цитате опечатка, то можно добавить sic, указав, что опечатка — не ваша. «sic» не имеет никакой эмоциональной окраски.
> Пароль получается так — base64(md5('фраза')). Фраза берется длинная — цитата какого-нибудь известного мыслителя (Кант, Гегель, Шопенгауэр, Ницше, Маркс, Хайдеггер — да кто угодно), которую вы помните НАИЗУСТЬ (со всеми знаками препинания)
Опять какие-то сферические кони в вакууме. Это называется musturbation — говорить о том, какой ситуация должна быть, игнорируя реальность. Кто выгонит человека, если он делает свою работу — пусть и не так хорошо, как мог бы сделать специалист высокого класса? Заметьте, я говорю о больших конторах, а не о мелких, где человека могут запросто пнуть на мороз и всё.
У меня был печальный опыт с прототипированием. Однажды я начал делать внутренний проект с прототипа. Но так получилось, что вместо того, чтобы отложить прототип и начать делать реальную систему, фичи начали накатывать прямо на прототип. Это было неприятно. Впрочем, там во многом я сам был виноват. Вообще в таких случаях нужно чётко оговаривать, что это прототип и что в продакшн будет идти совсем другое и его ещё надо разработать. Ибо начальник может не понять и сказать — хуле, вы ж уже разработали, чо вам ещё надо. И сунет ваш прототип в продакшн.
Вы как-то смешиваете заказчика и документацию по архитектуре. Интересно было бы услышать Ваши аргументы, почему документация по архитектуре не работает?
«Документация не нужна. Ваш код — лучшая документация» — это сверическая ситуация в вакууме. В реальности же есть, во-первых, недобросовестные разработчики, которые считают, что лучше, извините, нах*ячить, чем выискать хорошую, самодокументирующую структуру кода и данных. Во-вторых, в любой системе со временем появляются различные неочевидные вещи, которые просто обязаны быть документированны. Ибо смотришь, например, на некоторый алгоритм расчёта, и думаешь — like, WTF? O_O
Мне кажется, что это могут себе позволить немногие компании: либо небольшие софтверно-ориентированные конторы, либо софтверные конторы, где этот механизм поставлен на поток. В большинстве же компаний IT — непрофильный ресурс, и для бухгалтерии проще повесить их на фиксированную ставку. Может, у вас другие соображения?
Так мне непонятно, Вы предлагает пару недель ковыряний оценить как 2-3 часа рабочего времени, или 2-3 часа рабочего времени оценить как пару недель ковыряний? :)
> Да какая разница когда сотрудники приходят и уходят. Система «отсиживания» должна умереть. Главное о чем должны заботиться руководители — это об эффективности труда, а не о времени, которое сотрудник провел в офисе.
Вы в плане — «мне пофигу когда ты сегодня уйдёшь из офиса, но чтобы завтра всё было готово»?
Пример: я хочу использовать вашу систему объектов с её, судя по описаниям, невероятно сложной алгоритмической нагрузкой. Но с небольшим отличием: я хочу разместить ваш код на сервере приложений и дёргать его через веб. Вопрос: зачем мне впились ваши Button и ComboBox в классах бизнес-логики?
FYI, «sic» означает, что приведённая цитата написана именно так. Например, если в цитате опечатка, то можно добавить sic, указав, что опечатка — не ваша. «sic» не имеет никакой эмоциональной окраски.
Я читал, что с введением этого свойства volatile по производительности стали практически как обычные блокировки. Вы не подскажете, так ли это?
мне непонятно, это такой тонкий троллинг? :-\
Неправильно проектируете архитектуру? ;)
какой-то рунглиш
Вы в плане — «мне пофигу когда ты сегодня уйдёшь из офиса, но чтобы завтра всё было готово»?