Я понял что речь о жиме от груди ))) О жиме ногами через вероятно какие-то блоки - об этом даже не подумал ))

Да, зачастую бытует такое мнение у людей - раз повесили, значит реклама. Раз реклама - значит нужно сорвать! А лепящие эти наклейки - козлы !.. ))

Клеил наклейки "workout.su". На следующий день приходил посмотреть как наклейки висят, и отмечал, что то ли Коли, то ли Васи уже подходили к этим наклейкам, и успешно их сорвали. А если наклейки сидели крепко, то остатки так и висели ошметками.. как-то оно вот так.

Или ютуб, или gmail - посмотри

WasD, насколько помню, на ютубе волпейпа оформляется на канал. Т.е оформляется фон (в верхней части странички) а на общем фоне уже рисуется ава пользователя. Как-то так.

Крешь...

Может очевидны еще какие-то огрехи ? Можно увидеть на архитектурной схеме реализацию паттернов ?
Я паттернами не особо заморачивался. Могу сказать что interface, state, singletone в проекте есть. Может в показательной архитектуре еще какие-то паттерны должны быть задействованы (вернее, может отсутствие каких-то паттернов напрямую свидетельствует о дилетантском подходе к подходу ООП)???

Я смотрю, что по данному приближению модели к рассмотрению, недочеты выявить не получается. За исключением наличия объектов и связей - ничего не просматривается.
С "елкой" - та же ситуация.

Если же взять большее приближение (пример на скриншоте),
то видно, видно, что с инкапсуляцией - хреново. Да, не у всех методов неободимость быть пабликами, но в приват они не занесены - плохо.
Полиморфизм - хз как его на схеме увидеть. Встречал упоминание, что если в коде присутствуют "swith... case" - значит полиморфизм не задействован.
Применительно к моему коду - у меня кейсы на ID элементов в обработчике задействуются сплошь и рядом. Значит с полиморфизмом тоже не гуд.
Наследование. Хм. Что по схеме видно - стрелочки одного типа. Ну и еще кружочки с крестиками - этого мало.
Что-то типа такого (картинка под спойлером) -
проектирование по схеме А задействовано, а B и C - таких связей не наблюдается. Это не есть гуд. Это свидетельствует о том, что extends и implement abstract iterface не применяется.
Может этого в данном фрагменте (проекте) и не нужно, но так ли это ???

Такой вот ход рассуждений.

Не, забей на вэб. Это вопрос не вэба, а, похоже, это вопрос именно моделирования, т.е по сути - грамотного юзания ООП.

Хм, а если это применять не по отношению к данным, а к блок-схеме ? Как предположительно выглядит соотношение "многого-ко-многим" ? Я задумывался, что это что-то типа такого (скриншот)... но я весьма не уверен. Сейчас я считаю, что это вполне нормальная ситуация - значит, что сущности объектов, описанных в другом пакете, могут задействоваться в объектах внутри текущего пакета.

Антон уже ответил. На пока что - вот так. По другому - без вариантов.

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

Я раньше тоже так считал. И компаниям предлагал код для review. Код выдергивал из рабочих модулей - а что еще надо, ведь реально работает ?!
Тестовое задание делал людям - говорят "да, вроде как даже работает, но у нас есть вопросы..."
Собственно - а что не так ? Что нужно для того, что бы по просмотру кода был виден уровень, а не "говнокод", которые сегодня наваял, а завтра сам же за голову берешься - "и кто так пишет"? ))))

К тому же, столкнувшись с ТДД прислушался к интересным мыслям - например одна из которых, что хороший программер не пользуется дебагом (потому что код покрыт тестами, и когда что-то сломано - то ненужно дебага, а локализация ощибки проходит на ровне тестов.. тесты пищутся параллельно кодированию). Ткже столкнулся с утверждением, что "хороший код и подерживать легче". А если поддерживать тяжело - значит код гавно. А в непродуманном проекте реализовывать архитектурные изменения - каждый раз словно костыли прикручивать... ))

Вот и возник вопрос, можно ли по виду архитектуры проекта определить уровень программиста (/програмистов), реаилующего проект ? Приложение работает, но этого не достаточно.

Не помню от кого этот пример пошел, но по утверждению самый лучший собеседник для программиста - это рядом стоящий с монитором плюшевый мишка. Пока ему объяснишь как программа работает - сам начинаешь в этом разбираться ))

Все что у меня есть на сейчас (повторюсь)

По первой строке комментариев нет. Ну разве что - полиморфизм, наследование, инкапсуляция.
Большие блоки - значит много пабликов (плохо).
Полиморфизм на схеме не проявляется (особенно если он в привате).
Остается наследование.

По второму предложению - собственно, вопрос открытый, поскольку связи - это хорошо (или плохо ?). А связанность - это плохо. Теперь стоит определить что такое связанность и что превращает связи в связанность, а затем увидеть это в представлении схематики