Мы оба понимаем принцип верно, просто говорим о разном.
Слово «модуль» оставляет большое пространство для фантазии и неправильного понимания, т.к. статья никак не раскрывает этот принцип.
Я хотел подчеркнуть, что использующий всегда зависит от используемого. На этом принципе строится граф зависимостей, позволяющий понять что вообще происходит с архитектурой в проекте.
В моём примере, проект, использующий карты, всегда будет от них зависеть.
Вопрос только в том, в каком виде — будет он зависеть от реализации, или от абстракции
И да, вы правы, в конце концов и проект и реализация будут завязаны на абстракцию.
В этом и инверсия, что вместо старого графа
Ок, если претендуем на точность, то нужна ссылка на источник. Могу назвать свой — Clean Architecture, Robert C.Martin, Chapter III — Design Principles:
The code that implements high-level policy should not depend on the code that
implements low-level details. Rather, details should depend on policies
Собственно Роберт Мартин это первоисточник в этом вопросе.
А если говорить о сути, то если бы в статье была часть про
Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций
То я бы не писал развёрнуто смысл, который был потерян.
Дело в смысле, а не в формулировке.
DIP (принцип инверии зависимостей) описан так, что больше путает, чем объясняет что это и зачем надо.
Модули верхних уровней не должны зависеть от модулей нижних уровней
Это в корне неверно. Модуль верхнего уровня всегда зависит от модуля нижнего уровня, который он использует.
Пример: ваше приложение использует Яндекс.Карты. Теперь ваше приложение зависит от этой библиотеки и её реализации. Яндек.Карты же напротив, понятия не имеют что вы их используете и никак не зависит от кода вашего приложения.
Теперь о чём действительно говорит DIP:
Код, реализующий высокоуровневую политику, не должен зависеть от кода, реализующего низкоуровневые детали
Звучит похоже, но смысл совершенно другой.
На примере тех же карт, если вы хотите сделать свой код гибким, то вы должны выделить абстракцию MapImageInterface, содержащей допустим метод drawMap. Тогда реализация на яндекс картах, допустим YaMapImage будет имплементить этот интерфейс (это низкоуровневые детали). YaMapImage зависит от MapImageInterface, но не наоборот. Ваше приложение работает только используя MapImageInterface, не зная конкретных деталей (инстанцировать объект может например абстрактная фабрика). При этом код будет гибким и не будет проблем завтра добавить новую реализацию, например GoogleMapImage.
И раз уж вы описываете исключительно SRP, то и ограничьтесь его упоминанием в заголовке без кликбейта. SOLID не раскрыт.
Люди, я вам поражаюсь. Человек поделился своим опытом восстановления зрения. Про Жданова лишь одна строчка, как ссылка на источник так сказать. Вроде бы ни хвалебных од «чудо-профессору», ничего такого. Так нет, надо человека заминусовать, а самим прыгать как бабуинам и кричать про пиздёж, провокацию, и что Хабр не тот! Так вот Хабр не тот брагодаря вам, а не автору статьи, друзья. Любой адекватный человек понял бы что статья про восстановление зрения, а не боже упаси про Жданова. Получаётся где живём там и срём. Очень грустно, небо не видело таких позорных хабраюзеров.
Теперь по теме: какое-то время занимался по методике Бейтса\Жданова — как хотите. Занимался около месяца, после этого зрение заметно улучшилось (субъективно). Перед компом стало напряжно сидеть и одел очки на единицу попроще. Потом забросил упражнения, и зрение где-то за полгода вернулось к прежнему. Думаю если не забрасывать, а заниматься регулярно, то можно добиться значительных результатов.
Бабушка в далёком Брянске, через недельку тетя отвезёт, тогда уж после будет ясно =) Вобщем то искалась именно модель с большими кнопками, потому что с прошлым телефоном (вроде обычных не тач-скринных) бабушка не совладала именно из-за меленьких неудобных\непонятных кнопок и сложного меню.
Зачем Нокии адаптироваться? У них есть Maemo, и у них есть хорошая фора, т.к. Android еще сыроват, а Maemo уже вылизан и в плане юзабилити и в плане доступного софта. А Symbian действительно пора на свалку истории, не смешно уже
Зайти в приложение и посмотреть ближайшие электрички не займёт много времени. Не вижу простого способа вывести ближайшие электрички в статусе приложения, т.к. для этого на своём сервере(которого нет) придётся раз в n минут перебирать всех пользователей приложения, обращаться к tutu.ru, парсить и обновлять статус. Это излишняя нагрузка и на tutu.ru и на свой сервер(которого нет :D)
Думаю в приложении сделать пункт «попутчики» чтобы сразу узнать кто из твоих друзей едет на этой же электричке — полезно для студентов =)
Через недельку доделаю приложение для вконтакта — расписание электричек на основе tutu.ru — как раз пункт 1. С пунктами 0 и 2 tutu.ru и так неплохо справляется
Аналогично есть проект которому больше 7 лет, написано с нагромождением iframe'ов друг в друга. В те далекие времена это считалось ajaxом =( И переписать не дают и количество неявных связей и зависимостей между частями столько за это время создалось, что рефакторинг только микрошажками возможен и смысла особого нет. Остаётся только вооружившись мачете каждый раз пробираться сквозь быдлокод, исправляя очередной баг или расширяя функционал.
Попробуйте найти подход к заказчику. Ему редко интересно, что разработчику сложно ориентироваться в нагромождении быдлокода, попробуйте объяснить что после рефакторинга время на внесение изменений и дополнительного функционала сократится в несколько раз (соответственно упадёт стоимость этих измений)
Слово «модуль» оставляет большое пространство для фантазии и неправильного понимания, т.к. статья никак не раскрывает этот принцип.
Я хотел подчеркнуть, что использующий всегда зависит от используемого. На этом принципе строится граф зависимостей, позволяющий понять что вообще происходит с архитектурой в проекте.
В моём примере, проект, использующий карты, всегда будет от них зависеть.
Вопрос только в том, в каком виде — будет он зависеть от реализации, или от абстракции
И да, вы правы, в конце концов и проект и реализация будут завязаны на абстракцию.
В этом и инверсия, что вместо старого графа
Появляется инверсия от реализации к абстракции:
Собственно Роберт Мартин это первоисточник в этом вопросе.
А если говорить о сути, то если бы в статье была часть про
То я бы не писал развёрнуто смысл, который был потерян.
Дело в смысле, а не в формулировке.
Это в корне неверно. Модуль верхнего уровня всегда зависит от модуля нижнего уровня, который он использует.
Пример: ваше приложение использует Яндекс.Карты. Теперь ваше приложение зависит от этой библиотеки и её реализации. Яндек.Карты же напротив, понятия не имеют что вы их используете и никак не зависит от кода вашего приложения.
Теперь о чём действительно говорит DIP:
Звучит похоже, но смысл совершенно другой.
На примере тех же карт, если вы хотите сделать свой код гибким, то вы должны выделить абстракцию MapImageInterface, содержащей допустим метод drawMap. Тогда реализация на яндекс картах, допустим YaMapImage будет имплементить этот интерфейс (это низкоуровневые детали). YaMapImage зависит от MapImageInterface, но не наоборот. Ваше приложение работает только используя MapImageInterface, не зная конкретных деталей (инстанцировать объект может например абстрактная фабрика). При этом код будет гибким и не будет проблем завтра добавить новую реализацию, например GoogleMapImage.
И раз уж вы описываете исключительно SRP, то и ограничьтесь его упоминанием в заголовке без кликбейта. SOLID не раскрыт.
а то как-то голословно.
Теперь по теме: какое-то время занимался по методике Бейтса\Жданова — как хотите. Занимался около месяца, после этого зрение заметно улучшилось (субъективно). Перед компом стало напряжно сидеть и одел очки на единицу попроще. Потом забросил упражнения, и зрение где-то за полгода вернулось к прежнему. Думаю если не забрасывать, а заниматься регулярно, то можно добиться значительных результатов.
Думаю в приложении сделать пункт «попутчики» чтобы сразу узнать кто из твоих друзей едет на этой же электричке — полезно для студентов =)