Но почти ни одна формулировка из 5ти не понятны. А именно :
1. Принцип единственности ответственности На каждый объект должна быть возложена одна единственная ответственность.
Что значит ответственность ? Допустим есть объект Box — у него несколько методов Scale() , Move() получается он отвечает уже за 2 действия. Или три свойства Width, Top, Height — отвечает за 3 параметра. А также Width, Top, Heigth могут быть не просто Integer, а объектами типа SizeMeasure, получается что Box будет отвечать за состояние 3х объектов.
2.Принцип открытости/закрытости Программные сущности … должны быть открыты для расширения, но закрыты для изменения.
Не понятно, как можно открыть сущность для изменения ? Допустим есть класс с методами, изменить его можно только изменив исходный текст, перекрытие методов возможно но уже в другом классе, а текущий никак не изменить, кроме редактирования исходного кода.
3. Принцип подстановки Лисков Объекты в программе могут быть заменены их наследниками без изменения свойств программы.
И к чему это интересно ? Зачем заменять объект наследником, не изменяя поведение наследника, а другое поведение наследника — это разве не новое/улучшенное/ухудщеное свойство программы. Если нет, то зачем создавать наследника который не меняет свойств программы.
4.
Принцип изоляции интерфейса Много специализированных интерфейсов лучше, чем один универсальный.
Тоже странно, получается по этому правилу нужно делать на каждую сущность свой интерфейс, т.к. допустим есть команда ICommand, у нее 2 метода Execute и CanExecute, интерфейс достаточно универсальный, подходит для всех команд, но каждая команда имеет свои особенности, и получается согласно этому правилу на них нужно плодить специализированные интерфейсы. И в чем будет практическое удобство от этого ?
5.Принцип инверсии зависимостей Зависимости внутри системы строятся на основе абстракций. Модули верхнего уровня не зависят от модулей нижнего уровня. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
А это как понимать , получается например слой над драйверами не должен от них зависеть, а как извините обращаться к драйверу не завися от его интерфейса.
А потом — фраза " Зависимости внутри системы строятся на основе абстракций." и "Абстракции не должны зависеть от деталей." т.е. получаем что в абстракциях не должно быть деталей, и тут вспоминаем п.4. где нам рекомендуют создавать специализированные интерфейсы , которые являются абстракцией, а их специализация означает включение деталей и конкретики.
Очень советую прочитать книгу Роберта Мартина (Robert Martin) — Agile Principles, Patterns, and Practices in C#. Там достаточно хорошо объясняются эти принципы.
А>1. Принцип единственности ответственности На каждый объект должна быть возложена одна единственная ответственность.
А>Что значит ответственность ? Допустим есть объект Box — у него несколько методов Scale() , Move() получается он отвечает уже за 2 действия. Или три свойства Width, Top, Height — отвечает за 3 параметра. А также Width, Top, Heigth могут быть не просто Integer, а объектами типа SizeMeasure, получается что Box будет отвечать за состояние 3х объектов.
Нет. "Отвественность" кто-то из мэтров определил как потенциальную причину изменять объект. На твоем примере это показать невозможно ибо ты не определил назначение твоего объекта Box.
А>3. Принцип подстановки Лисков Объекты в программе могут быть заменены их наследниками без изменения свойств программы. А>И к чему это интересно ? Зачем заменять объект наследником, не изменяя поведение наследника, а другое поведение наследника — это разве не новое/улучшенное/ухудщеное свойство программы. Если нет, то зачем создавать наследника который не меняет свойств программы.
Слово "свойств" неточное. Формально принцип звучит так:
Если тип B является подтипом A, то все предусловия B должны быть должны быть не сильнее предусловий A, а постусловия для B должны быть не слабее постусловий A.
В ООП отношение тип-подтип создается наследованием. Таким образом, выполняя LSP, можно в любом месте программы где требуется объект типа A подставить объект типа B и программа будет работать как и раньше.
А>2.Принцип открытости/закрытости Программные сущности … должны быть открыты для расширения, но закрыты для изменения.
Фактически означает что надо базовые классы строить так чтобы наследники не могли нарушить LSP.
А>4. А>Принцип изоляции интерфейса Много специализированных интерфейсов лучше, чем один универсальный.
А>Тоже странно, получается по этому правилу нужно делать на каждую сущность свой интерфейс, т.к. допустим есть команда ICommand, у нее 2 метода Execute и CanExecute, интерфейс достаточно универсальный, подходит для всех команд, но каждая команда имеет свои особенности, и получается согласно этому правилу на них нужно плодить специализированные интерфейсы. И в чем будет практическое удобство от этого ?
Если ты не отдаешь наружу методов и не принимаешь команды, отличные от ICommand, то никаких интерфейсов тебе плодить не надо.
Собственно принцип и говорит что если ты отдаешь\принимаешь интерфейс, то лучше много маленьких и специализированных, чем один большой и универсальный.
А> А>5.Принцип инверсии зависимостей Зависимости внутри системы строятся на основе абстракций. Модули верхнего уровня не зависят от модулей нижнего уровня. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций. А> А>А это как понимать , получается например слой над драйверами не должен от них зависеть, а как извините обращаться к драйверу не завися от его интерфейса.
Откровенно хреновая формулировка. Подробнее про IoC можешь прочитать тут.
Здравствуйте, MozgC, Вы писали:
MC>Очень советую прочитать книгу Роберта Мартина (Robert Martin) — Agile Principles, Patterns, and Practices in C#. Там достаточно хорошо объясняются эти принципы.
«Если вы ученый, квантовый физик, и не можете в двух словах объяснить пятилетнему ребёнку, чем вы занимаетесь, — вы шарлатан»
Интересно, а когданить у программистов такое получится?
Здравствуйте, MozgC, Вы писали:
MC>Здравствуйте, gandjustas, Вы писали:
G>>
G>>«Если вы ученый, квантовый физик, и не можете в двух словах объяснить пятилетнему ребёнку, чем вы занимаетесь, — вы шарлатан»
G>>Интересно, а когданить у программистов такое получится?
MC>Это ты сейчас о чем?
О том что эти принципы были придуманы хзкогда, а до сих пор внятного объяснения найти трудно, а чтобы понять пять буковок нужно прочитать минимум несколько заумных книжек.
Здравствуйте, gandjustas, Вы писали:
G>О том что эти принципы были придуманы хзкогда, а до сих пор внятного объяснения найти трудно, а чтобы понять пять буковок нужно прочитать минимум несколько заумных книжек.
Мне объяснения у Мартина нравятся. Несколько заумных книжек тоже не надо. Можно просто у Мартина прочитать эти главы (они совсем небольшие) + для полноты посмотреть определения в других источниках.
Здравствуйте, Аноним, Вы писали:
А>1. Принцип единственности ответственности На каждый объект должна быть возложена одна единственная ответственность.
А>Что значит ответственность ? Допустим есть объект Box — у него несколько методов Scale() , Move() получается он отвечает уже за 2 действия. Или три свойства Width, Top, Height — отвечает за 3 параметра. А также Width, Top, Heigth могут быть не просто Integer, а объектами типа SizeMeasure, получается что Box будет отвечать за состояние 3х объектов.
Ответственность можно понимать как назначение объекта. Т.е., если объект класса Box отвечает за положение ящика в пространстве, то отвечать за отрисовку этого ящика на экране или сохранение состояния в файл он уже не должен. Как уже сказали, одна ответственность = одна причина изменения класса. При таком подходе изменяя у класса Box логику расположение в пространстве мы не можем повредить логику сохранения, так как она будет в отдельном классе.
На практике такое разделение помогает чётче понять предметную область, способствует более качественному анализу. В процессе разработке одна ответственность может разделиться на несколько — это нормальное явление, главное при этом соответствующим образом разделить класс.
А>2.Принцип открытости/закрытости Программные сущности … должны быть открыты для расширения, но закрыты для изменения.
А>Не понятно, как можно открыть сущность для изменения ? Допустим есть класс с методами, изменить его можно только изменив исходный текст, перекрытие методов возможно но уже в другом классе, а текущий никак не изменить, кроме редактирования исходного кода.
Возьмём тот же класс Box, допустим его ответственность — расположение ящика в пространстве. Класс имеет ограниченное число методов для изменения положения — Scale и Move. Рано или поздно, возможно в другом проекте, нам потребуется средство для поворота ящика.
Согласно принципу OCP мы должны ещё на этапе проектирования класса Box добавить в него метод Transform(), которые принимает, например, матрицу трансформации координат, т.е. позволяет осуществить любое преобразование. Если этого не сделать, то для реализации поворота ящика нам нужно править исходный код класса Box, что не есть хорошо.
Вообще говоря, суть принципа в том, чтобы предвидеть направления расширения ответственности класса и в данных направлениях реализовывать класс так, чтобы расширение не требовало изменения исходного кода. Естественно, всё предвидеть невозможно, и в один прекрасный момент в код класса всё-таки придётся вмешиваться. Принцип позволяет уменьшить вероятность такого вмешательства.
А>3. Принцип подстановки Лисков Объекты в программе могут быть заменены их наследниками без изменения свойств программы. А>И к чему это интересно ? Зачем заменять объект наследником, не изменяя поведение наследника, а другое поведение наследника — это разве не новое/улучшенное/ухудщеное свойство программы. Если нет, то зачем создавать наследника который не меняет свойств программы.
Тут уже написали про предусловия постусловия.
Суть в том, что тот код, который работает с базовым классом, рассчитывает на некоторое поведение, если производный класс будет нарушать это поведение, то ничего хорошего не получится.
Например, в базовом классе Box сеттер свойства Width изменяет ширину и только ширину. А в производном классе Cube, мы решили, что в сторона куба будет задаваться только свойством Height, а сеттер Width ничего изменять не будет. Это и есть нарушение LSP. Аналогично будет, если при изменении свойства Width будет изменяться ещё и Height.
А>4. А>Принцип изоляции интерфейса Много специализированных интерфейсов лучше, чем один универсальный.
А>Тоже странно, получается по этому правилу нужно делать на каждую сущность свой интерфейс, т.к. допустим есть команда ICommand, у нее 2 метода Execute и CanExecute, интерфейс достаточно универсальный, подходит для всех команд, но каждая команда имеет свои особенности, и получается согласно этому правилу на них нужно плодить специализированные интерфейсы. И в чем будет практическое удобство от этого ?
Можно сказать, что ISP — это принцип единственности ответственности для интерфейсов. Каждый интерфейс должен описывать один аспект поведения, выделенный на основе какой-либо надобности. Т.е., интерфейсы мы должны проектировать не "от класса", а от способов использования класса; на каждое использование мы делаем отдельный интерфейс, даже не смотря на то, что все эти интерфейсы будут реализованы в одном классе.
Например, пусть выполнение некоторых команд можно прерывать. ISP запрещает нам добавлять в ICommand метод Cancel, а вместо этого предлагает создать интерфейс ICancelable. Тот код, который отвечает за прерывание выполнения команды по нажатию Esc, будет хранить ссылку не на ICommand, а на ICancelable.
А> А>5.Принцип инверсии зависимостей Зависимости внутри системы строятся на основе абстракций. Модули верхнего уровня не зависят от модулей нижнего уровня. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций. А>
А>А это как понимать , получается например слой над драйверами не должен от них зависеть, а как извините обращаться к драйверу не завися от его интерфейса.
По DI в сети достаточно много информации.
Пусть верхний стой — программа, нижний слой — драйвер. Программа взаимодействует с драйвером, получает от него информацию. Драйвер ничего не знает о программе его использующей.
Принцип зависимости на основе абстракций предлагает нам выделить интерфейс IDriver (или базовый класс DriverBase) и построить слой программы так, чтобы он зависел от этого интерфейса (т.е. от абстракции), а не от самого драйвера (реализации). Тогда изменения в коде драйвера не потребуют перекомпиляции программы. При этом, сам интерфейс IDriver (или базовый класс) не должен находиться в том же модуле (сборке, файле), что и драйвер. Он может находиться в отдельном модуле или в модуле с программой.
На мой взгляд на практике главное не переусердствовать с выделением абстракций. Абстракции хороши на межмодульном (межуровневом, межслойном и т.п.) уровне, внутри отдельно взятого самостоятельного модуля тотальное выделение абстракций только мешает.
После 15 лет использования ООП прихожу к тому же выводу: парадигма ООП — полная бредятина, не имеющая ничего общего с реальностью. Программа в ООП стиле либо слишком запутанна, либо полна компромиссов, а чаще — и то и другое.
G>О том что эти принципы были придуманы хзкогда, а до сих пор внятного объяснения найти трудно, а чтобы понять пять буковок нужно прочитать минимум несколько заумных книжек.
Настоящая проблема мне видится в том, что даже прочитав несколько книжек, скорее всего "понять" эти принципы не получится.
Действительно их "понять" получится только столкнувшись с проблемами, которые они решают. Т.е. нужен собственный опыт.
ZEN>Программа в ООП стиле либо слишком запутанна, либо полна компромиссов, а чаще — и то и другое.
Склонен считать, что программа (делающая то же самое) вне стиля ООП будет еще более запутана.
Т.е. это свойство не подхода к решению проблемы, а самой проблемы.
Здравствуйте, ylem, Вы писали:
ZEN>>Программа в ООП стиле либо слишком запутанна, либо полна компромиссов, а чаще — и то и другое.
Y>Склонен считать, что программа (делающая то же самое) вне стиля ООП будет еще более запутана. Y>Т.е. это свойство не подхода к решению проблемы, а самой проблемы.
Каждой парадигме своя область применения. Для гуйни все мапится на ооп хорошо, для процессионговых серверов все лучше мапится на всякие функциональные дкомпозиции и иже с ними.. Надо быть гибким
Re[2]: Объясните принцип SOLID
От:
Аноним
Дата:
30.03.11 16:00
Оценка:
Здравствуйте, Poul_Ko, Вы писали:
P_K>Здравствуйте, Аноним, Вы писали:
А>>1. Принцип единственности ответственности На каждый объект должна быть возложена одна единственная ответственность.
А>>Что значит ответственность ? Допустим есть объект Box — у него несколько методов Scale() , Move() получается он отвечает уже за 2 действия. Или три свойства Width, Top, Height — отвечает за 3 параметра. А также Width, Top, Heigth могут быть не просто Integer, а объектами типа SizeMeasure, получается что Box будет отвечать за состояние 3х объектов.
P_K>Ответственность можно понимать как назначение объекта. Т.е., если объект класса Box отвечает за положение ящика в пространстве, то отвечать за отрисовку этого ящика на экране или сохранение состояния в файл он уже не должен. Как уже сказали, одна ответственность = одна причина изменения класса. При таком подходе изменяя у класса Box логику расположение в пространстве мы не можем повредить логику сохранения, так как она будет в отдельном классе. P_K>На практике такое разделение помогает чётче понять предметную область, способствует более качественному анализу. В процессе разработке одна ответственность может разделиться на несколько — это нормальное явление, главное при этом соответствующим образом разделить класс.
Вроде как понятно, но не совсем. Допустим у ящика появился контейнер Items который хранит объекты внутри него. В понятие геометрии это не вписывается,
где грань между новой и старой ответственностью ?
Здравствуйте, Аноним, Вы писали:
А>Вроде как понятно, но не совсем. Допустим у ящика появился контейнер Items который хранит объекты внутри него. В понятие геометрии это не вписывается, А>где грань между новой и старой ответственностью ?
Суть в том, чтобы сделать методы Add/Remove у Items, а не AddItem/RemoveItem у Box.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Poul_Ko, Вы писали:
P_K>>Здравствуйте, Аноним, Вы писали:
А>>>1. Принцип единственности ответственности На каждый объект должна быть возложена одна единственная ответственность.
А>>>Что значит ответственность ? Допустим есть объект Box — у него несколько методов Scale() , Move() получается он отвечает уже за 2 действия. Или три свойства Width, Top, Height — отвечает за 3 параметра. А также Width, Top, Heigth могут быть не просто Integer, а объектами типа SizeMeasure, получается что Box будет отвечать за состояние 3х объектов.
P_K>>Ответственность можно понимать как назначение объекта. Т.е., если объект класса Box отвечает за положение ящика в пространстве, то отвечать за отрисовку этого ящика на экране или сохранение состояния в файл он уже не должен. Как уже сказали, одна ответственность = одна причина изменения класса. При таком подходе изменяя у класса Box логику расположение в пространстве мы не можем повредить логику сохранения, так как она будет в отдельном классе. P_K>>На практике такое разделение помогает чётче понять предметную область, способствует более качественному анализу. В процессе разработке одна ответственность может разделиться на несколько — это нормальное явление, главное при этом соответствующим образом разделить класс.
А>Вроде как понятно, но не совсем. Допустим у ящика появился контейнер Items который хранит объекты внутри него. В понятие геометрии это не вписывается, А>где грань между новой и старой ответственностью ?
Ты опиши зачем применяется Box. Не бывает "хорошего дизайна" в отрыве от решаемых задач.
Здравствуйте, iZEN, Вы писали:
ZEN>После 15 лет использования ООП прихожу к тому же выводу: парадигма ООП — полная бредятина, не имеющая ничего общего с реальностью. Программа в ООП стиле либо слишком запутанна, либо полна компромиссов, а чаще — и то и другое.
Поддерживаю, у мартин Р. Чистый код... хорошое пояснение по поводу одного из аспектов. Я так понимаю что любой паттерн проектирования улучшая что-то другое ухудшает и нет никаких принципов,
следовать которым нужно любой ценой. Думаю тут дело даже не в компромисах, а в полном отсутствии однозначного решения любой проблемной ситуации. Неопределенность или даже принцип неопределенностей лучше подходит.
Антисимметрия да иных/объектов
Два предыдущих примера показывают, чем объекты отличаются от структур
данных. Объекты скрывают свои данные за абстракциями и предоставляют функции,
работающие с этими данными. Структуры данных раскрывают свои данные и не
имеют осмысленных функций. А теперь еще раз перечитайте эти определения.
Обратите внимание на то, как они дополняют друг друга, фактически являясь
противоположностями. Различия могут показаться тривиальными, но они
приводят к далеко идущим последствиям.
...(пример)...
(1) У проблемы существуют обходные решения, хорошо известные опытным объектно-
ориентированным программистам: например, паттерн ПОСЕТИТЕЛЬ или двойная
диспетчеризация. Но у этих приемов имеются собственные издержки, к тому же они обычно
возвращают структуру к состоянию процедурной программы.
И снова мы наблюдаем взаимодополняющую природу этих двух определений.
В этом проявляется основополагающая дихотомия между объектами и
структурами данных.
Процедурный код (код, использующий структуры данных) позволяет легко
добавлять новые функции без изменения существующих структур данных. Объектно —
ориентированный код, напротив, упрощает добавление новых классов без
изменения существующих функций.
Обратные утверждения также истинны.
Процедурный код усложняет добавление новых структур данных, потому что оно
требует изменения всех функций. Объектно-ориентированный код усложняет
добавление новых функций, потому что для этого должны измениться все классы.
Таким образом, то, что сложно в ОО, просто в процедурном программировании,
а то, что сложно в процедурном программировании, просто в ОО!
В любой сложной системе возникают ситуации, когда вместо новых функций
в систему требуется включить новые типы данных. Для таких ситуаций объекты
и объектно-ориентированное программирование особенно уместны. Впрочем,
бывает и обратное — вместо новых типов данных требуется добавить новые
функции. Тогда лучше подходит процедурный код и структуры данных.
Опытные программисты хорошо знают: представление о том, что все данные
должны представляться в виде объектов — миф. Иногда предпочтительны
простые структуры данных и процедуры, работающие с ними.
Здравствуйте, Аноним, Вы писали:
А>Вроде как понятно, но не совсем. Допустим у ящика появился контейнер Items который хранит объекты внутри него. В понятие геометрии это не вписывается, где грань между новой и старой ответственностью ?
В принципе, уже всё сказали.
Хорошие решения (c точки зрения SRP):
1. Для хранения и манипулирования коллекцией Items создать класс BoxItems (или использовать стандартную коллекцию, если этого достаточно). Добавить свойство Items типа BoxItems в класс Box. В данном случае можно сказать, что хранение ссылки на коллекцию не является значительной ответственностью и внесением её в класс Box можно пренебречь, однако если таких дополнительных ответственностей станет много, то желательно перейти ко второму варианту.
2. Старый класс Box переименовать в BoxGeometry, для хранения и манипулирования коллекцией Items создать класс BoxItems, создать новый класс Box, который хранит ссылку на BoxGeometry и BoxItems. Ответственность нового класса Box — создание и инициализация объектов BoxGeometry и BoxItems. Это самый "идеологически чистый" вариант.
3. Для хранения и манипулирования коллекцией Items создать класс BoxItems, в нём создать неизменяемое поле Box — ссылку на объект Box, коллекцию элементов которого хранит объект BoxItems. Здесь ссылка на Box является своего рода идентификатором и не добавляет никакой ответственности в класс BoxItems.
Плохое с точки зрения SRP решение:
Добавить в класс Box свойство Items и методы для манипулирования коллекцией (AddItem, RemoveItem, FindItem, ...). Управление коллекцией — это отдельная ответственность.
Здравствуйте, Vaako, Вы писали:
V>Здравствуйте, iZEN, Вы писали:
ZEN>>После 15 лет использования ООП прихожу к тому же выводу: парадигма ООП — полная бредятина, не имеющая ничего общего с реальностью. Программа в ООП стиле либо слишком запутанна, либо полна компромиссов, а чаще — и то и другое.
V>Я так понимаю что любой паттерн проектирования улучшая что-то другое ухудшает и нет никаких принципов, следовать которым нужно любой ценой.
Неверно понимаешь. Подавляющее большинство "паатернов" ничего не ухудшают, они дают рецепт для решения типовой задачи. В современных языках многие такие паттерны включены в сам язык. Например observer — event_ы в .NET и Delphi, аналогично итераторы.
V>Думаю тут дело даже не в компромисах, а в полном отсутствии однозначного решения любой проблемной ситуации.
Неверно. Это в конкретном языке могут отсутствовать средства адекватно выразить задачу, тогда возникает проблема как её эффективно решить в конкретном случае.
Большинство современных языков имею так называемую Expression Problem. Суть её заключается в невозможности одновременно расширять структуры данных а операции над ними. Ни один ООП язык этого не позволяет.
