У меня уже есть наброски:) А я знаю, какой тяни-толкай может получиться при совместной работе над подобными вещами.
А вот от ревьюеров не откажусь, это однозначно!
Может быть DIP? (я не вижу у себя сокращения DI). Если таки да, то это Dependency Inversion Principle (кстати, именно он по ссылке и приведен), и именно он является прородителем Dependency Injection Pattern-а.
Разница в том, что на том уровне, на котором файл открывают, обычно не просто его открывают в блоке try/catch, его открывают в try/finally, чтобы закрыть его успешно в случае успешной и неуспешной работы.
При этом кэтчить исключение на том уровне, где происходит работа с файлом обычно не имеет смысла, поскольку восстановиться от этой проблемы все равно на этом уровне нельзя.
Мне кажется, что вы черезчур узко смотрите на понятие полиморфизма. Этот пример — это самый настоящий полиморфизм, но скорее основанный на статической утиной типизации, нежели на общности типов некоторой иерархии.
LSP по своему определению говорит лишь о динамическом полиморфизме (вы сами пишите об иерархии классов), но это не единственный вид полиморфизма. Есть же еще и статический полиморфизм.
По вашему, нарушает ли этот код OCP:
template<typename T> void draw(const T& t) {
// и много чего другого, для обеспечения рисования фигуры
t.Draw();
}
Очевидно, что нет, но и принцип замещения Лисков здесь тоже не применим, поскольку T может быть чем угодно и не связан отношениями подтип/надтип. Вот и получается, что именно на основе полиморфизма (как более общего понятия) реализуется принцип OCP, а не на основе LSP.
> Книжка то толковая, никто не обещал каноничных трактовок SOLID и паттернов, какой был бы в ней толк?
А каких еще трактовок ожидать от *автора* этих принципов? В том-то и проблема книги, что описание принципов не слишком-то детальнее, описания из википедии. Так вопрос: зачем мне покупать книгу, если я могу с тем же успехом получить всю ту же информацию на вики;)
Я, например, от книги хочу большего контекста, при этом не вижу смысла описывать принципы в книге столь категоричным образом, чтобы потом писать еще две книги о их применимости.
Ведь с тем же open-closed принципом вообще беда. У того же Джона Скита есть заметка под названием The Open-Closed Principle, in review, в результате чего Роберт Мартин написал ответ «An Open and Closed Case», в котором английским по белому соглашается с тем, что был пьян молод и через чур категоричен в формулировке этого принципа:
2.They are “Closed for Modification”. The source code of such a module is inviolate. No one is allowed to make source code changes to it.
OK, as an isolated sound-bite, point two is a bit overstated. I mean: «no one is allowed...»? I'm not sure why I phrased it that way 17 years ago. I was young and impressionable back then, a mere 43 years old. So I can only chalk the stridence of that phrase up to my immaturity.
Но проблема остается: многие ведь читают книгу, рассматривая ее как современный источник информации и не знают о том, что ее автор уже не столь категоричен в своих суждениях;)
1. (verb) To work on something when you don't understand the problem space, the market, the actual goal of the product or really any engineering at all.
2. Agile is a generalized term for a group of anti-social behaviors used by office workers to avoid doing any work while simultaneously giving the appearance of being insanely busy. Agile methods include visual distraction, subterfuge, camouflage, psycho-babble, buzzwords, deception, disinformation, and ritual humiliation. It has nothing to do with the art and practice of software engineering.
Но ведь «дядюшка» Боб — не единственный автор, который пишет о дизайне, архитектуре и кодинге.
Есть, например, упомянутый выше Мейер. Его труд «Объектно-ориентированное конструирование программных систем» является признанной классикой в этой области и он не позволяет себе выражений типа «делайте так и будет все классно». Есть Мартин Фаулер, который пишет о Ынтырпрайз паттернах, это архитектура, но тоже без таких заявлений. Есть те же Фриманы с их Паттернами проектирования, но и они не делают вида, что нашли серебрянную пулю.
Так что в этой книге напрягает категоричность, которой в нашей области просто не существует. У меня в команде есть джуниоры и при решении любых задач я стараюсь показать, что дизайн — это постоянный поиск компромиса и идеального решения нет по определению. Так и здесь, книга не идеальна и главный недостаток ее в том (ИМХО), что она не дает понять, когда приведенные правла можно и нужно нарушать. Вот и все.
ИМХО, смело и безрассудно критиковать алгоритмы в книгах Кнута, ОО подходы в книгах Мейера, фундаментальность трудов Хоара. Камрада Мартина я к этим товарищам в один список поставить никак не могу, поскольку его книги и статьи никогда не носили фундаментального характера. Что не плохо, нужно сказать, это его стиль, который я уважаю.
Цель таких рецензий в том, чтобы при чтении книг у разработчиков не возникало карго культа, а было прагматичное и взвешенное отношение, как к решениям, принимаемым за клавиатурой, и такое же отношение было и при чтении авторитетных книг или статей.
Думайте, подвергайте сомнению, доказывайте и не принимайте советы о том, что такое хорошо, а что плохо, за чистую монету.
Ничего зубодробительного там не будет, но наличие опыта будет нужно, чтобы осело в голове больше.
А вот от ревьюеров не откажусь, это однозначно!
Я же про GoF (книга 1994-года), и про другие классические паттерны, движение вокруг которого началось именно в начале 90-х.
З.Ы. Паттерны — это универсальное понятие, они были, есть и будут. Речь здесь именно о класических паттернах!
При этом кэтчить исключение на том уровне, где происходит работа с файлом обычно не имеет смысла, поскольку восстановиться от этой проблемы все равно на этом уровне нельзя.
По вашему, нарушает ли этот код OCP:
Очевидно, что нет, но и принцип замещения Лисков здесь тоже не применим, поскольку T может быть чем угодно и не связан отношениями подтип/надтип. Вот и получается, что именно на основе полиморфизма (как более общего понятия) реализуется принцип OCP, а не на основе LSP.
А каких еще трактовок ожидать от *автора* этих принципов? В том-то и проблема книги, что описание принципов не слишком-то детальнее, описания из википедии. Так вопрос: зачем мне покупать книгу, если я могу с тем же успехом получить всю ту же информацию на вики;)
Я, например, от книги хочу большего контекста, при этом не вижу смысла описывать принципы в книге столь категоричным образом, чтобы потом писать еще две книги о их применимости.
Ведь с тем же open-closed принципом вообще беда. У того же Джона Скита есть заметка под названием The Open-Closed Principle, in review, в результате чего Роберт Мартин написал ответ «An Open and Closed Case», в котором английским по белому соглашается с тем, что был
пьянмолод и через чур категоричен в формулировке этого принципа:Но проблема остается: многие ведь читают книгу, рассматривая ее как современный источник информации и не знают о том, что ее автор уже не столь категоричен в своих суждениях;)
1. (verb) To work on something when you don't understand the problem space, the market, the actual goal of the product or really any engineering at all.
2. Agile is a generalized term for a group of anti-social behaviors used by office workers to avoid doing any work while simultaneously giving the appearance of being insanely busy. Agile methods include visual distraction, subterfuge, camouflage, psycho-babble, buzzwords, deception, disinformation, and ritual humiliation. It has nothing to do with the art and practice of software engineering.
Есть, например, упомянутый выше Мейер. Его труд «Объектно-ориентированное конструирование программных систем» является признанной классикой в этой области и он не позволяет себе выражений типа «делайте так и будет все классно». Есть Мартин Фаулер, который пишет о Ынтырпрайз паттернах, это архитектура, но тоже без таких заявлений. Есть те же Фриманы с их Паттернами проектирования, но и они не делают вида, что нашли серебрянную пулю.
Так что в этой книге напрягает категоричность, которой в нашей области просто не существует. У меня в команде есть джуниоры и при решении любых задач я стараюсь показать, что дизайн — это постоянный поиск компромиса и идеального решения нет по определению. Так и здесь, книга не идеальна и главный недостаток ее в том (ИМХО), что она не дает понять, когда приведенные правла можно и нужно нарушать. Вот и все.
Цель таких рецензий в том, чтобы при чтении книг у разработчиков не возникало карго культа, а было прагматичное и взвешенное отношение, как к решениям, принимаемым за клавиатурой, и такое же отношение было и при чтении авторитетных книг или статей.
Думайте, подвергайте сомнению, доказывайте и не принимайте советы о том, что такое хорошо, а что плохо, за чистую монету.