Адекватный интерфейс под винду — это очень немаленький проектик.
И тяп-ляп решения тут не прокатывают — пользователи очень уж разные по всем параметрам.
Возможность настройки большинство пользователей скорее ненавидят, чем используют.
Так что нужно N интерфейсов под N категорий пользователей.
В зависимости от специфики работы — домашний комп или рабочая станция (зависит от направленности работы, опять же).
Это хорошо, когда пишем проект с нуля.
А в случае работающего большого проекта, где что-то нужно регулярно подпиливать, это плохо работает — времени-то на это не выделяют, а подобное изменение в одном месте может вызвать лавинообразное изменение по всему коду.
Не зря было сказано про legacy.
Read-only getter работает только для примитивных типов.
Для объектов будет константная ссылка.
А я говорю про аналог const в Си.
Причем read-only должно быть поведение по-умолчанию, а read/write — только там, где действительно нужно.
Ведь const в Си не пишут там, где следует, именно по причине лени или забывчивости.
Для того, чтобы можно было отразить в коде то, что обычно пишут в доках.
Код, как известно, лучшая документация.
И желательно чтобы это было так даже в случае отсутствия исходников.
Если такая магия и нужна, то ее лучше обернуть классом, и использовать как объект-значение.
Жаль, что в Java (как и в большинстве языков) нельзя создавать производных типов над примитивными.
На самом деле нужно доказывать корректность для всего множества значений :-)
И желательно приложить сокращенный вариант доказательства прямо в JavaDoc.
Лучше запретить null'ы на уровне языка :-)
Ясно-понятно, что уже не Java.
А еще лучше запрещать не только null'ы, но и вообще целые классы значений, чтобы избежать большинства runtime-проверок как таковых. Runtime-проверки должны быть только там, где есть внешние данные. Согласованность внутренней логики должна проверяться на уровне компиляции.
Хороший пример этой идиомы — enum'ы вместо именованных констант, generic'и.
Да, деление ответственности — обязательная часть review, иначе это все голословно.
А вот когда головой отвечаешь за чужой код — волей-неволей прочитаешь и проверишь частные случаи.
А разбор сценариев «а что если» нужно делать еще ДО реализации. Т.е. проводить не только review кода, но и review дизайна предполагаемого решения.
Особенно если сказать «Приходи, когда статический анализатор будет показывать отсутствие косяков в твоем коде».
В итоге большая часть времени проверяющих код экономится.
intermediate, senior…
Ребята (и да простите мне это выражение!), это все спор о словах.
Вся соль в широте охвата (знать о том, что такое уже есть и где оно есть), в его глубине (знание деталей, тонкостей, частых ошибок и т.д.) и в умении интегрировать эти знания по разным областям.
Остальное — либо лирика и разговор ни о чем, либо конкретика.
И тяп-ляп решения тут не прокатывают — пользователи очень уж разные по всем параметрам.
Возможность настройки большинство пользователей скорее ненавидят, чем используют.
Так что нужно N интерфейсов под N категорий пользователей.
В зависимости от специфики работы — домашний комп или рабочая станция (зависит от направленности работы, опять же).
:-)
А в случае работающего большого проекта, где что-то нужно регулярно подпиливать, это плохо работает — времени-то на это не выделяют, а подобное изменение в одном месте может вызвать лавинообразное изменение по всему коду.
Не зря было сказано про legacy.
И понизить криптостойкость на несколько порядков.
P.S. Как ни странно, часто наблюдается в JavaScript'ах.
Для объектов будет константная ссылка.
А я говорю про аналог const в Си.
Причем read-only должно быть поведение по-умолчанию, а read/write — только там, где действительно нужно.
Ведь const в Си не пишут там, где следует, именно по причине лени или забывчивости.
Код, как известно, лучшая документация.
И желательно чтобы это было так даже в случае отсутствия исходников.
Жаль, что в Java (как и в большинстве языков) нельзя создавать производных типов над примитивными.
И желательно приложить сокращенный вариант доказательства прямо в JavaDoc.
Ясно-понятно, что уже не Java.
А еще лучше запрещать не только null'ы, но и вообще целые классы значений, чтобы избежать большинства runtime-проверок как таковых. Runtime-проверки должны быть только там, где есть внешние данные. Согласованность внутренней логики должна проверяться на уровне компиляции.
Хороший пример этой идиомы — enum'ы вместо именованных констант, generic'и.
А вот когда головой отвечаешь за чужой код — волей-неволей прочитаешь и проверишь частные случаи.
А разбор сценариев «а что если» нужно делать еще ДО реализации. Т.е. проводить не только review кода, но и review дизайна предполагаемого решения.
В итоге большая часть времени проверяющих код экономится.
Ребята (и да простите мне это выражение!), это все спор о словах.
Вся соль в широте охвата (знать о том, что такое уже есть и где оно есть), в его глубине (знание деталей, тонкостей, частых ошибок и т.д.) и в умении интегрировать эти знания по разным областям.
Остальное — либо лирика и разговор ни о чем, либо конкретика.