Насчет интерфейса тоже не совсем верно.
Раздувание интерфейса часто приводит к разрушению его целостности.
Хотя имеются примеры очень больших, но продуманных целостных интерфейсов (например, ResultSet в Java).
Мучение = восприятие воздействия как приносящего боль.
Боль = нечто, приводящее к разрушению системы. В зависимости от рода повреждений (физические, моральные) работают разные механизмы.
С физической болью все более-менее понятно, это рефлекторный механизм, можно не реагировать, но сигнал зависит только от внешних воздействий и исправности датчиков (болевых нервов).
А вот психологическая боль зависит от восприятия действия как разрушительного. Причем как сознательно, так и неосознанно.
Т.е. ее понимание упирается в понимание механизма сознания.
Можно сказать, что есть адаптер, который оба вида боли выдает через один и тот же выход. Однако, создание, на выходе которого считывается психологическая боль, представляется черным ящиком с неизвестной природой.
Т.е. даже поняв связи и работу остальной части системы, нельзя понять, есть ли в данной системе сознание или нет.
А вспоминая такие феномены, как интуиция, все становится еще сложнее.
В моем понимании стандарты нужны, чтобы любой разработчик мог читать чужой код как свой.
Неверно.
Стандарт нужен для того, чтобы было представление о стиле кодирования.
Также он создает некоторое уважение к стандарту.
И, наконец, позволяет с помощью автоматизированных средств приводить код к единообразию, если, например, при копировании съехали отступы.
А еще иногда стандарты кодирования позволяют избегать конкретных ошибок — сам стиль кодирования нивелирует вероятность появления подобных ошибок.
P.S. Холивар по copy_n_paste оставим в стороне, ладно?
А работа в паре, видимо, способствует всего лишь овладению этими навыками.
Не только навыками, а также обеспечивает быстрое вливание в команду нового человека.
Я думаю, что это самый логичный случай использования парного программирования.
При этом новичок пишет код, а наблюдатель корректирует и отвечает на вопросы.
Насчет BDD Вы совершенно правы.
Этот подход действительно приносит большую пользу, в отличие от более слабого TDD.
Документирующие тесты, которые можно читать непрограммисту — это стоит того, чтобы применять данный подход.
Вот только это должны быть не тесты реализации, а тесты спецификации, протокола взаимодействия.
Иначе это не BDD, и коэффициент полезности будет недалек от нуля.
Когда проект вырастет я хочу чтобы всё, что может произойти с юнитом, было описано в классе юнита, а не в пяти разных местах, где он используется.
IMHO, Вы еще не достигли просветления. Все, что может произойти с unit'ом, в один класс может оказаться очень трудно упихать.
И это будет напоминать именно упихивание, а не архитектуру.
ООП придуман для распиливания обязанностей на части.
Если обязанностей становится много — необходимо разделить по принципу единой ответственности.
Неустойчивость требований влечет необходимость обсуждений и внесения изменений.
Чем выше степень неустойчивости — тем органичнее смотрится Agile. И наоборот.
P.S. Интереснее всего решать те задачи, для которых не понятно, в какую сторону вообще идти.
Кстати, само Ваше положение представляет собой интереснейшую задачку :-)
Если хочешь разобраться в себе…
Понаблюдай за дикой природой.
За птицами, за животными, за растениями, за облаками, ветром, солнцем…
Попробуй почувствовать мир.
Когда заходишь в тупик — ничто так не помогает, как вдумчивая остановка.
Здесь не слои. Слои располагаются друг за другом, и общаются только с соседними слоями.
В web-модели приложения же и контроллер, и вид обращаются к одним и тем же данным.
Так что если считать данные моделью, то концепция слоев нарушается. Поэтому хочется четкой терминологии.
Если же вообще отказаться от понятия модели, и ввести понятия «провайдер данных» и «операция», то эта модель приложения хорошо ложится на request/response-архитектуру.
Это будет не MVC (см. мой комментарий выше).
Оно может хорошо работать, зарекомендовать себя на практике, то тем не менее это не MVC.
И каждый подобный вид взаимодействия имеет смысл рассматривать отдельно от других. Какие-то решения могут быть паттернами, какие-то — скорее, единичными явлениями.
Если же рассматривать MVC как концепцию… То необходимо ее как-нибудь адекватно назвать. MVC уже используется как наименование четко описанного паттерна, давайте так и оставим, чтобы можно было сослаться на первоисточник и говорить об одном и том же.
Так что жду предложений по наименованию концепции.
Так что нотификация вида об изменениях через события модели — обязательная часть MVC.
Иначе это уже что-то другое (возможно, также успешное, но другое).
Раздувание интерфейса часто приводит к разрушению его целостности.
Хотя имеются примеры очень больших, но продуманных целостных интерфейсов (например, ResultSet в Java).
Жизнь проходит слишком быстро.
Заразившись оптимизмом,
Можно рухнуть до нуля.
Осмотрись. Пойми причины.
Помни: много есть дорог.
Хоть не пустишь на порог,
Мнения учти иные.
Мудрость жизнью познается,
Многих тенью обделив.
Только тем, кто был пытлив,
Понимание удается.
(с)
Боль = нечто, приводящее к разрушению системы. В зависимости от рода повреждений (физические, моральные) работают разные механизмы.
С физической болью все более-менее понятно, это рефлекторный механизм, можно не реагировать, но сигнал зависит только от внешних воздействий и исправности датчиков (болевых нервов).
А вот психологическая боль зависит от восприятия действия как разрушительного. Причем как сознательно, так и неосознанно.
Т.е. ее понимание упирается в понимание механизма сознания.
Можно сказать, что есть адаптер, который оба вида боли выдает через один и тот же выход. Однако, создание, на выходе которого считывается психологическая боль, представляется черным ящиком с неизвестной природой.
Т.е. даже поняв связи и работу остальной части системы, нельзя понять, есть ли в данной системе сознание или нет.
А вспоминая такие феномены, как интуиция, все становится еще сложнее.
Неверно.
Стандарт нужен для того, чтобы было представление о стиле кодирования.
Также он создает некоторое уважение к стандарту.
И, наконец, позволяет с помощью автоматизированных средств приводить код к единообразию, если, например, при копировании съехали отступы.
А еще иногда стандарты кодирования позволяют избегать конкретных ошибок — сам стиль кодирования нивелирует вероятность появления подобных ошибок.
P.S. Холивар по copy_n_paste оставим в стороне, ладно?
Не только навыками, а также обеспечивает быстрое вливание в команду нового человека.
Я думаю, что это самый логичный случай использования парного программирования.
При этом новичок пишет код, а наблюдатель корректирует и отвечает на вопросы.
Этот подход действительно приносит большую пользу, в отличие от более слабого TDD.
Документирующие тесты, которые можно читать непрограммисту — это стоит того, чтобы применять данный подход.
Вот только это должны быть не тесты реализации, а тесты спецификации, протокола взаимодействия.
Иначе это не BDD, и коэффициент полезности будет недалек от нуля.
IMHO, Вы еще не достигли просветления.
Все, что может произойти с unit'ом, в один класс может оказаться очень трудно упихать.
И это будет напоминать именно упихивание, а не архитектуру.
ООП придуман для распиливания обязанностей на части.
Если обязанностей становится много — необходимо разделить по принципу единой ответственности.
Чем выше степень неустойчивости — тем органичнее смотрится Agile. И наоборот.
Кстати, само Ваше положение представляет собой интереснейшую задачку :-)
Понаблюдай за дикой природой.
За птицами, за животными, за растениями, за облаками, ветром, солнцем…
Попробуй почувствовать мир.
Когда заходишь в тупик — ничто так не помогает, как вдумчивая остановка.
Calendar.getInstance()тогда уж, грамотей :-)58 = 22 + 36 = 2(2 + 3)6 = 256 = 2 + 56 = 58
С праздником! :-)
В web-модели приложения же и контроллер, и вид обращаются к одним и тем же данным.
Так что если считать данные моделью, то концепция слоев нарушается. Поэтому хочется четкой терминологии.
Если же вообще отказаться от понятия модели, и ввести понятия «провайдер данных» и «операция», то эта модель приложения хорошо ложится на request/response-архитектуру.
Оно может хорошо работать, зарекомендовать себя на практике, то тем не менее это не MVC.
И каждый подобный вид взаимодействия имеет смысл рассматривать отдельно от других. Какие-то решения могут быть паттернами, какие-то — скорее, единичными явлениями.
Если же рассматривать MVC как концепцию… То необходимо ее как-нибудь адекватно назвать. MVC уже используется как наименование четко описанного паттерна, давайте так и оставим, чтобы можно было сослаться на первоисточник и говорить об одном и том же.
Так что жду предложений по наименованию концепции.
Иначе это уже что-то другое (возможно, также успешное, но другое).