Действительно ли единственный Принцип Ответственности является правилом ООП? [закрытый]
Я думаю, что люди здесь должны заметить Poster, что: Static Nest Class - это только первый внутренний класс. Например:
public static class A {} //ERROR
public class A {
public class B {
public static class C {} //ERROR
}
}
public class A {
public static class B {} //COMPILE !!!
}
Итак, суммируем, статический класс не зависит от того, какой класс содержит его. Таким образом, они не могут в нормальном классе. (потому что нормальному классу нужен экземпляр).
6 ответов
Очень немного правил, если таковые имеются, в разработке программного обеспечения без исключения. Некоторые люди думают, что нет никакого места для goto, но они неправы.
, Насколько ООП идет, нет единственного определения объектно-ориентированности так в зависимости от того, кто Вы просите, чтобы Вы получили различный набор твердых и мягких принципов, шаблонов и методов.
классическая идея ООП состоит в том, что сообщения отправляются в в других отношениях непрозрачные объекты, и объекты интерпретируют сообщение со знанием их собственных внутренностей и затем выполняют какую-то функцию.
SRP является принципом разработки программного обеспечения, который может относиться к роли класса, или функции или модулю. Это способствует сцеплению чего-то так, чтобы это вело себя хорошо соединенное без несвязанных битов, зависающих прочь его или имеющих несколько ролей, которые переплетают и усложняют вещи.
Даже со всего одной ответственностью, которая может все еще колебаться от единственной функции до группы свободно связанных функций, которые являются частью общей темы. Пока Вы стараетесь не сооружать элемент на скорую руку для взятия ответственности чего-то, что она не была, прежде всего, разработана для или выполнение некоторой другой специальной вещи, которые растворяют простоту объекта, затем нарушают любой принцип, Вы хотите.
, Но я нахожу, что легче заставить SRP, корректный затем делать что-то более тщательно продуманное, которое столь же устойчиво.
Ни одно из этих правил не законы. Они - больше инструкций и лучших практик. Существуют времена, когда не имеет смысла следовать "правилам", и необходимо сделать то, что является лучшим для ситуации.
не боятся сделать то, что Вы думаете, является правильным. Вы могли бы на самом деле придумать более новые и лучшие правила.
Заключить капитану Barbossa в кавычки:
".. И во-вторых, необходимо быть пиратом для кода пирата для применения, и Вы не. И в-третьих, код больше, что Вы назвали бы "инструкциями", чем фактические правила.... "
, Чтобы заключить Jack Sparrow в кавычки & Gibbs. "Я думал, что Вы, как предполагалось, придерживались кода". Г-н Gibbs: "Мы полагали, что они были более фактическими инструкциями".
, Таким образом, ясно Пираты понимают это вполне прилично.
"правила" могли быть поняты через перемещение шаблонов как "Силы"
, Таким образом, существует сила, пытающаяся заставить класс нести единственную ответственность. (сцепление)
, Но существует также сила, пытающаяся сохранять связь с другими классами вниз.
Как со всем дизайном (не только кодируют) ответ - то, что он зависит.
Ahh, я предполагаю, что это принадлежит ответу, который я дал.:)
Как с большинством правил и законов, там лежат в основе побуждений, которыми эти правила релевантны - если базовый повод не присутствует или применим к Вашему случаю, то Вы свободны изогнуться/повредить правила согласно своим собственным потребностям.
Однако SRP не является правилом ООП по сути, но считается лучшими практиками для создавания приложений ООП, которые являются и легко расширяемыми и тестируемыми единицей.
Оба - характеристики, которые я рассматриваю с наибольшей важности в разработке корпоративного приложения, где обслуживание существующих приложений занимает больше времени, чем новая разработка.
Как во многих из других плакатов было сказано, все правила сделаны быть нарушенными.
Однако я действительно думаю, что SRP является одним из более важных правил для записи хорошего кода. Это не характерно для Объектно-ориентированного программирования, но часть "инкапсуляции" ООП очень трудно сделать правильно, если класс не несет единственную ответственность.
, В конце концов, как делают Вас правильно и просто инкапсулировать класс с несколькими обязанностями? Обычно ответ является несколькими интерфейсами и на многих языках, которые могут помочь вполне немного, но это все еще сбивает с толку пользователей Вашего класса, который это может применить совершенно другими способами в различных ситуациях.
SRP является просто другим выражением ISP:-).
И "P" означает "принцип", не "управляйте": D