- Технический писатель отношения к ТЗ не имеет.
- ТЗ пишет аналитик.
- Заказчик никогда не напишет ТЗ если только он не является профессиональным разработчиком систем. Но, заказчик способен написать список своих пожеланий. Осмыслить его и сделать технически грамотный текст (требования и ТЗ) - дело аналитика.
Философствовать, открывать Америку и изобретать велосипед тут не нужно. Профессиональный составитель ТЗ называется системный аналитик.
Нда, минусование Вашего комментария, есть прямой показатель тупости хабрапользователей. И она уже становится невыносимо высокой. На каком-то этапе любому умному человеку придётся сказать - заипали необразованные хабраподростки. Хабравладельцам давно необходимо что-то предпринимать, что бы ресурс не превратился в информационный мусор. Хотя, быть может уже и поздно. Но по инерции, люди пытьаются что-то умное постить. Скоро этот ручеёк иссякнет.
В общем случе - да. Но если вам это кажется надуманным, абстрагируйтесь и примите тот факт, что этот параметр уже механически реализован в зубцах физическокго ключа. Уровень абстракции при этом сохраняется. ;)
Не любой. Но любой квадрат является прямоугольником. Я тут битых шесть часов это хабравцам поясняю. А они в отместку минусуют. Видимо по человечески не согласны. Ну чтож.. будем считать что поэтам всё простительно... :-)
Чёрт его знает. Я не понимаю почему инверсия зависимостей есть более широкое понятие. Это разумеется делегирование, но делегирование это что-ли технический термин встраивания ссылки. А вот Стрэтеджи это и есть паттерн постулирующий тот факт, что некая ссылка на поле обладет предопределённым интерфейсом и может быть легко подменена другой реализацией. Весь Core Spring на этом и построен.
не-не-не... Вы всё правильно пишете, но вы ненавязчиво привнесли дополнительный уровень защиты. Автор привёл простейшиё пример - ключ (со всем барахлом типа паролей/кодов/защит) в руках у вас и вы только счёлкаете пальцами и говорите - Open! Это же был учебный пример. Не нужно его рассматривать с точки зрения аутентификации и авторизации. Опять же - абстрагируйтесь... ;)
И да, гаечный ключ - добавлю. По сути, такой же ключ как и амбарный или карточный. Им открывают моторы. Ну и что, что им надо вертеть? Это уже специфика реализации. Главное то, что им открывают! Можно на поддон картера и магнитную карту повесить. Будет работать, не сомневайтесь. Просто не целесообразно. ;-)
1. Продумывание интерфейсов это и есть часть продумывания архитектуры.
2. Интерфейс Ключ не должен ничего открывать и не должен ничего доказывать, он должен однозначно информировать как им пользоваться. Точка.
3. Делать параметр строковым - не имеет никакого отношения к правильному уровню абстракций, это лишь некая техническая гибкость за счёт использования более свободного типа данных. Это не всегда хорошо. Иногда как раз нужна жётскость. Ещё раз - это не ключевая абстракция, никаких выводов тут делать нельзя.
Не то что бы физически страшно, но количество денег которое уходит на то, что бы пояснить 90% разработчиков правильные принципы декомпозициии системы, просто потрясающе. Только 5-10% разработчиков способны быстро въехать, адекватно мыслить и вносить полезные замечания в проектирование системы. Остальные - просто информационный шум. Почитайтье дискуссию ниже. Люди тотально не понимают что такое интерфейс и зачем он нужен. Это действительно серьёзная интелектуальная проблема. Особенно учитывая тот факт, что отстранять людей от обсуждения не совсем гуманно. Приходится тратить деньги на их убеждение. Но не всех можно убедить. Есть ещё и некоторый интеллектуальный барьер. Как бы шовинистически это и не звучало.
Структура зубчиков главное в реализации тяжелого амбарного ключа. А в интерфейсе ключ главное тот факт, что тому кто будет пользоваться реализацией этого интерфейса, будет достаточно вызвать метод Open(), дабы что-то нужное открыть. В этом его божественное предназначение.
Угу. Я и раньше предполагал, что серъёзный уровень абстракции доступен лишь одному проценту людей. Остальные выглядят как слепые котята. Грустно конечно. :-(
Я и говорю, профессионалы также пошли на этот путь. Оно понятно, что мастеру всё равно чем "махать", но при прочих равных, более мощным и удобным инструментом вы "махали" бы куда как более эффективно. Просто в силу эффективности инструмента. Оно и лук мощное оружие для опытного полководца, но с автоматом как-то сподручнее. Особенно для того же мощного полководца. :-)
Ключ и не должен ничего открывать. Назначение интерфейса Ключ - сказать, что для того, что бы что-то открыть, надо вызвать метод Open(). Именно его и с таким названием. А что он фактически будет делать, зависит от реализации. Возможно он будет как раз закрывать бутылку, дабы открыть мозг для ясности восприятия. :-)
Это не я спросил. Я не писал, не пишу и никогда не буду писать на PHP. Для меня это соседняя тупиковая улица на которую люди забрели по юношеской наивности. Популярность этго языка обусловлена всего-лишь низким порогом вхождения, который был сделан для того, что бы популяризовать WEB для чайников. То, что по этой дорожке пошло много профессионалов, никак не делает этот язочёнок хоть сколь-либо интересным и мощным.
Зависит от уровня абстракции. Если интерфейс Ключ заявлен как предмет для открытия дверей, то штопор - не катит. Если как предмет для вскрытия чего бы то не было, то штопор есть также реализация ключа. То есть этот уровень уже диктует Ваша задача.
- ТЗ пишет аналитик.
- Заказчик никогда не напишет ТЗ если только он не является профессиональным разработчиком систем. Но, заказчик способен написать список своих пожеланий. Осмыслить его и сделать технически грамотный текст (требования и ТЗ) - дело аналитика.
Философствовать, открывать Америку и изобретать велосипед тут не нужно. Профессиональный составитель ТЗ называется системный аналитик.
Я не ставлю, я их только получаю, пытаясь пояснить, что квадрат это также прямоугольник. :-)
1. Продумывание интерфейсов это и есть часть продумывания архитектуры.
2. Интерфейс Ключ не должен ничего открывать и не должен ничего доказывать, он должен однозначно информировать как им пользоваться. Точка.
3. Делать параметр строковым - не имеет никакого отношения к правильному уровню абстракций, это лишь некая техническая гибкость за счёт использования более свободного типа данных. Это не всегда хорошо. Иногда как раз нужна жётскость. Ещё раз - это не ключевая абстракция, никаких выводов тут делать нельзя.
Угу. Я и раньше предполагал, что серъёзный уровень абстракции доступен лишь одному проценту людей. Остальные выглядят как слепые котята. Грустно конечно. :-(