<quote name=WasD post="227243">
выложи в тему "вопросы по сайту", например :></quote>
Можно по подобной схеме определить слабые места (нагромождения "гавнокода") ??
К примеру, вот такая вот схема:
Или такая вот "елка".. "Звезда" - это обработчик событий, поэтому он широко задействован. Можно что-то сказать по подобной схематике о самой архитектуре ??
??
"Принимай критику только от тех, кто добился больше тебя"(c)
В частности, "елка" - это схема официального приложения workout.su (что там - работа с картой, с шаблоном площадок, с сообщениями привата, профилем пользователя, и реализация нескольких экранов - тоже как-то не очень густо).
Объектов - много. То что на пакеты не разнесено - ладно,.. насколько неинформативно представление схемы без локализации пакетов ?
Как по мне, то вообще мутно все. Не зная алгоритма, не зная точки входа - малоинформативно (вообще не информативно).
Да виден EventListener какой-то (звезда на елке), который задействован во многих объектах, но уровень Application - вообще не схеме не прослеживается (а по идее сеттеты и геттеры с ним работают довольно активно)..
Опять таки, это мы подходим к анализу схемы, рассуждая об объеме задачи, которая по нашему представлению в нем реализована.
Лента. Представляется банальной (я не смею утверждат что это круто, но внутри крутится нечто больше, чем просто кастомизированный список). Что в ней (по быстрой памяти) под спойлером:
* чтение http-страниц (банально),
* парсер страниц на предмет определения параметров сообщения, и вложенного квотинга,
* парсер страниц форума/разделов/тем на предмет заполнения вложенных структур (разделов/тем/сообщений), определение количества страниц (для соответствующего уровня),
* реализация механизма отображения сообщений в ленту (собственно сама лента - что там: список и адаптер на кастомизацию)
* реализация циклического запроса страниц с целью определения изменений (чтобы определять и выгребать новые сообщения в ленту),
* реализация механизма проверки - а не перешло ли сообщения на новую страницу, ведь могут остаться непрочитанные сообщения на предыдущей странице,
* всякого рода "плюшки" в виде фильтров - бан на тему, автора, раздел, а также диаметральная противоположность - вынесение этого же в фавориты (отслеживание),
* подсчет статистики сообщений по пользователям (банально - но также реализовано),
* тробер,
* свайп,
* реализаця по свайпу всплывающей панели с грядкой кнопок ))
* всякая хрень типа адаптера работы с базой данных, дебага (простого логирования), еще какой-то мелочи
* всякого рода callback интерфейсы (на работу фоновых процессов по запросу http страничек, отображение троббера и связанных процессов - медиа-бряки, и еще какие-то интерфейсы - насксидку не помню),
** еще что-то - поднятие сессии авторизированного подключение через REST API, бла-бла-бла..
* парсер страниц на предмет определения параметров сообщения, и вложенного квотинга,
* парсер страниц форума/разделов/тем на предмет заполнения вложенных структур (разделов/тем/сообщений), определение количества страниц (для соответствующего уровня),
* реализация механизма отображения сообщений в ленту (собственно сама лента - что там: список и адаптер на кастомизацию)
* реализация циклического запроса страниц с целью определения изменений (чтобы определять и выгребать новые сообщения в ленту),
* реализация механизма проверки - а не перешло ли сообщения на новую страницу, ведь могут остаться непрочитанные сообщения на предыдущей странице,
* всякого рода "плюшки" в виде фильтров - бан на тему, автора, раздел, а также диаметральная противоположность - вынесение этого же в фавориты (отслеживание),
* подсчет статистики сообщений по пользователям (банально - но также реализовано),
* тробер,
* свайп,
* реализаця по свайпу всплывающей панели с грядкой кнопок ))
* всякая хрень типа адаптера работы с базой данных, дебага (простого логирования), еще какой-то мелочи
* всякого рода callback интерфейсы (на работу фоновых процессов по запросу http страничек, отображение троббера и связанных процессов - медиа-бряки, и еще какие-то интерфейсы - насксидку не помню),
** еще что-то - поднятие сессии авторизированного подключение через REST API, бла-бла-бла..
Сейчас же схема довольно прозрачна - и по ней не видно насколько где что плохо.
Вот я и в поиске ответов - может мне следует обращать снимание на какие-то кросс-комбинации связей, или связей межу пакетами, или множественных связей ?
Полагаю, что конкретно в "ленте сообщений" довольно грустно с наследованием - это видно по схеме ?
"Принимай критику только от тех, кто добился больше тебя"(c)
Name:>
Хорошая архитектура приложения - отображает принципы и использование ООП.
Плохо для приложения - отсутствие четкой архитектуры и сильная связанность всех компонентов.</quote>
Плохо для приложения - отсутствие четкой архитектуры и сильная связанность всех компонентов.</quote>
Большие блоки - значит много пабликов (плохо).
Полиморфизм на схеме не проявляется (особенно если он в привате).
Остается наследование.
По второму предложению - собственно, вопрос открытый, поскольку связи - это хорошо (или плохо ?). А связанность - это плохо. Теперь стоит определить что такое связанность и что превращает связи в связанность, а затем увидеть это в представлении схематики
"Принимай критику только от тех, кто добился больше тебя"(c)
А зачем тебе парсить HTML? Доступ к базе не дают? </quote>
</quote>Доступа к базе нет, API форума не писали пока.
кто не сворачивает тот дойдет (c) DoXoD
А зачем тебе парсить HTML? Доступ к базе не дают?</quote>
"Принимай критику только от тех, кто добился больше тебя"(c)
Плохо, когда "много ко многим" - этого надо избегать. (как? - частный случай у каждого свой, практически всегда решается увеличением количества таблиц в БД. Самое главное, что бы в итоге не возникало копипаста данных).</quote>
"Принимай критику только от тех, кто добился больше тебя"(c)
