Что должно быть в контрольном списке, который помог бы кому-то разработать хорошее программное обеспечение OO?
UITapGestureRecognizer *singleTap = [[UITapGestureRecognizer alloc] initWithTarget:self action:@selector(oneTap:)];
singleTap.numberOfTapsRequired = 1;
singleTap.numberOfTouchesRequired = 1;
singleTap.delegate = self;
[imageview1 addGestureRecogniser:singleTap];
[singleTap1 release];
imageview1.userInteractionEnabled = YES; //disabled by default
12 ответов
Похоже, вы хотите задать себе несколько простых вопросов типа да / нет. Все составили несколько замечательных списков «делай это» и «думай так», так что вот мой ответ на несколько простых «да / нет».
Могу я ответить утвердительно на все эти вопросы?
- Представляют ли мои классы те существительные, которые меня интересуют?
- Предоставляют ли мои классы методы для действий / глаголов, которые он может выполнять?
Могу ли я ответить «нет» на все эти вопросы?
- Есть ли у меня глобальные данные состояния, которые могут быть помещены в синглтон или сохранены в реализациях класса, которые работают с ним?
- Могу ли я удалить любые общедоступные методы класса и добавить их в интерфейс или сделать их частными / защищенными, чтобы лучше инкапсулировать поведение?
- Должен ли я использовать интерфейс, чтобы отделить поведение от других интерфейсов или реализующего класса?
- Есть ли у меня код, который повторяется между связанными классами, который я могу переместить в базовый класс для лучшего повторного использования кода и абстракции?
- Проверяю ли я тип чего-то, чтобы решить, что делать? Если да, то можно ли включить это поведение в базовый тип или интерфейс, который используется в рассматриваемом коде, чтобы обеспечить более эффективное использование абстракции, или следует ли реорганизовать рассматриваемый код для использования лучшего базового класса или интерфейса?
- Я постоянно проверяю некоторые данные контекста, чтобы решить, какой тип создать? Если да, можно ли это абстрагировать в шаблон проектирования фабрики для лучшей абстракции логики и повторного использования кода?
- Является ли класс очень большим с множеством функциональных сфер? Если да, могу ли я разделить его на несколько классов, каждый со своей единственной целью?
- Могу ли я унаследовать несвязанные классы от одного и того же базового класса? Если да, могу ли я разделить базовый класс на более качественные абстракции или использовать композицию для получения доступа к функциональности?
- Не стала ли моя иерархия наследования ужасно глубокой? Если да, могу ли я сгладить его или разделить элементы через интерфейсы или разделить функциональность?
- Я слишком много беспокоился о своей иерархии наследования?
- Когда я объясняю дизайн резиновой уточке, чувствую ли я себя глупым по поводу дизайна или глупым насчет разговора с уткой?
Просто несколько быстрых слов из моей головы. Надеюсь, это поможет, ООП может стать довольно сумасшедшим. Я не включил никаких да / нет для более сложных вещей, которые обычно возникают в больших приложениях,
Книга Стива МакКоннелла Code Complete 2 содержит множество готовых к использованию контрольных списков для создания хорошего программного обеспечения.
Роберт С. Мартин Agile Principles, Patterns, and Практики в C # содержат множество принципов хорошего объектно-ориентированного проектирования.
Оба дадут вам прочную основу для начала.
- Данные принадлежат к коду, который с ними работает (то есть к тому же классу). Это улучшает ремонтопригодность, поскольку многие поля и методы могут быть закрытыми ( инкапсуляция ) и, таким образом, в некоторой степени исключены из рассмотрения при рассмотрении взаимодействия между компонентами.
- Используйте полиморфизм вместо условий - всякий раз, когда вы должны делать разные вещи в зависимости от того, к какому классу относится объект, попробуйте поместить это поведение в метод, который разные классы реализуют по-разному, чтобы все, что вам нужно было сделать, это вызвать этот метод
- Используйте наследование экономно, предпочитайте композицию - Наследование является отличительной чертой объектно-ориентированного программирования и часто рассматривается как «сущность» объектно-ориентированного программирования. Фактически, им злоупотребляют, и его следует классифицировать как наименее важную особенность
Убедитесь, что вы прочитали и поняли следующую инкапсуляцию
-
- (Убедитесь, что вы предоставляете только минимальное состояние и функциональность для выполнения работы)
- Полиморфизм
- (Способность производных объектов вести себя как их родители)
- Разница между интерфейсом и и абстрактным классом
- (Абстрактный класс позволяет функциональность и состояние для совместного использования с его потомками, интерфейс это только обещание, что будет реализована функциональность)
Мне нравится этот список, хотя он мог бы быть немного сложным для использования в качестве контрольного списка.
Одним из лучших источников может быть книга Мартина Фаулера «Рефакторинг», которая содержит список (и вспомогательные детали) запахов объектно-ориентированного кода, которые вы, возможно, захотите рассмотреть при рефакторинге.
Я бы также порекомендовал контрольные списки из "Чистого кода" Роберта Мартина.
UML - унифицированный язык моделирования, для моделирования объектов и определения структуры и отношений между классами
http://en.wikipedia.org/wiki/Unified_Modeling_Language
Тогда, конечно методы программирования для объектно-ориентированного программирования (большинство уже упоминалось)
- Скрытие информации
- Абстракция
- Интерфейсы
- Инкапсуляция
- Наследование / полиморфизм
- Объекты делают вещи. (Самый важный момент во всем ООП!) Не думайте о них как о «держателях данных» - отправьте им сообщение, чтобы они что-то сделали. Какие глаголы должны быть в моем классе? Школа мышления, основанная на ответственном дизайне, отлично подходит для этого. (См. Дизайн объекта: роли, обязанности и сотрудничество , Ребекка Вирфс-Брок и Алан МакКин, Addison-Wesley 2003, ISBN 0201379430.)
- Для каждой вещи, которую должна делать система, следует . с набором конкретных сценариев, описывающих, как объекты взаимодействуют друг с другом для выполнения работы . Это означает мышление в терминах диаграмм взаимодействия и выполнение вызовов методов. - Не начинайте с диаграммы классов - это мышление SQL, а не объектно-ориентированное мышление.
- Изучите разработку через тестирование. Никто не получает свою объектную модель сразу, но если вы используете TDD, вы закладываете фундамент, чтобы убедиться, что ваша объектная модель выполняет то, что ей нужно, и делает безопасным рефакторинг, когда что-то изменится позже.
- Выполняйте сборку только для тех требований, которые у вас есть сейчас - не зацикливайтесь на «повторном использовании» или прочем, что «пригодится позже». Если вы создаете только то, что вам нужно прямо сейчас, вы сохраняете пространство дизайна, которое вы могли бы сделать позже, гораздо более открытым.
- Забудьте о наследовании при моделировании объектов. Это всего лишь один из способов реализации общего кода. Когда вы моделируете объекты, просто представляйте, что смотрите на каждый объект через интерфейс, описывающий, что его можно попросить сделать.
- Если метод принимает множество параметров или если вам необходимо многократно вызывать группу объектов для получения большого количества данных, возможно, метод находится в неправильном классе. Лучшее место для метода - рядом с большинством полей, которые он использует в том же классе (или суперклассе ...)
- Прочтите книгу Design Patterns для вашего языка. Если это C #, попробуйте «Шаблоны проектирования на C #» Стива Мецкера. Это научит вас ряду приемов, которые вы можете использовать для разделения работы между объектами.
- Не проверяйте объект, чтобы узнать, какой он тип, а затем предпринимайте действия на основе этого типа - это запах кода, который объект, вероятно, должен делать эту работу. Это намек на то, что вы должны вызвать объект и попросить его выполнить работу. (Если только некоторые виды объектов выполняют работу, вы можете просто "ничего не делать" реализации в некоторых объектах ... Это законное ООП.)
- Размещение методов и данных в правильных классах заставляет ОО-код работать быстрее (и дает виртуальным машинам возможность лучше оптимизироваться) - это не просто эстетично или теоретически. На это указывает исследование Шарбл и Коэн - см. http://portal.acm.org/citation.cfm?doid=159420.155839 (См. График показателей «количества инструкций, выполненных в сценарии»)
Have I clearly defined the requirements? Formal requirements documentation may not be necessary, but you should have a clear vision before you begin coding. Mind-mapping tools and prototypes or design sketches may be good alternatives if you don't need formal documentation. Work with end-users and stakeholders as early as possible in the software process, to make sure you are implementing what they need.
Am I reinventing the wheel? If you are coding to solve a common problem, look for a robust library that already solves this problem. If you think you might already have solved the problem elsewhere in your code (or a co-worker might have), look first for an existing solution.
Does my object have a clear, single purpose? Following the principle of Encapsulation, an object should have behavior together with the data that it operates on. An object should only have one major responsibility.
Can I code to an interface? Design By Contract is a great way to enable unit testing, document detailed, class-level requirements, and encourage code reuse.
Can I put my code under test? Test-Driven Development (TDD) is not always easy; but unit tests are invaluable for refactoring, and verifying regression behavior after making changes. Goes hand-in-hand with Design By Contract.
Am I overdesigning? Don't try to code a reusable component. Don't try to anticipate future requirements. These things may seem counterintuitive, but they lead to better design. The first time you code something, just implement it as straightforwardly as possible, and make it work. The second time you use the same logic, copy and paste. Once you have two working sections of code with common logic, you can easily refactor without trying to anticipate future requirements.
Am I introducing redudant code? Don't Repeat Yourself (DRY) is the biggest driving principal of refactoring. Use copy-and-paste only as a first step to refactoring. Don't code the same thing in different places, it's a maintenance nightmare.
Is this a common design pattern, anti-pattern, or code smell? Be familiar with common solutions to OO design problems, and look for them as you code - but don't try to force a problem to fit a certain pattern. Watch out for code that falls into a common "bad practice" pattern.
Is my code too tightly coupled? Loose Coupling is a principle that tries to reduce the inter-dependencies between two or more classes. Some dependencies are necessary; but the more you are dependent on another class, the more you have to fix when that class changes. Don't let code in one class depend on the implementation details of another class - use an object only according to its contract.
Am I exposing too much information? Practice information hiding. If a method or field doesn't need to be public, make it private. Expose only the minimum API necessary for an object to fulfill its contract. Don't make implementation details accessible to client objects.
Am I coding defensively? Check for error conditions, and Fail Fast. Don't be afraid to use exceptions, and let them propagate. In the event your program reaches an unexpected state, it's much, much better to abort an operation, log a stack trace for you to work with, and avoid unpredictable behavior in your downstream code. Follow best practices for cleaning up resources, such as the
using() {}statement.Will I be able to read this code in six months? Good code is readable with minimal documentation. Put comments where necessary; but also write code that's intuitive, and use meaningful class, method, and variable names. Practice good coding style; if you're working on a team project, each member of the team should write code that looks the same.
Does it still work? Test early, test often. After introducing new functionality, go back and touch any existing behavior that might have been affected. Get other team members to peer review and test your code. Rerun unit tests after making changes, and keep them up to date.
Некоторые правила не зависят от языка, некоторые правила различаются от языка к языку.
Вот несколько правил и комментариев, которые противоречат некоторым другим ранее опубликованным правилам:
ОО имеет 4 принципа: Абстракция, инкапсуляция, полиморфизм и наследование.
Прочтите о них и помните о них.Моделирование - ваши классы должны моделировать сущности в проблемной области:
Разделите проблему на поддомены (пакеты / пространства имен / сборки)
затем разделите объекты в каждой подобласти на классы.
Классы должны содержать методы, моделирующие то, что делают объекты этого типа.Используйте UML, подумайте о требованиях, вариантах использования, затем диаграммах классов, их последовательностях. (применимо в основном для высокоуровневого проектирования - основные классы и процессы.)
Шаблоны проектирования - хорошая концепция для любого языка, реализация различается между языками.
Структура и класс - в C # это вопрос передачи данных через значение или по ссылке.
Интерфейс по сравнению с базовым классом, это базовый класс, выполняет интерфейс.
TDD - это не объектно-ориентированный объект, на самом деле, он может вызвать недостаток дизайна и привести к большому количеству переписывания. (Scrum, например, не рекомендует это делать, для XP это обязательно.)
Рефлексия C # в некотором смысле переопределяет объектно-ориентированный подход (например, сериализацию на основе отражения), но это необходимо для продвинутых фреймворков.
Убедитесь, что классы этого не делают " знать о «других классах, если они не должны», разделение на несколько сборок и недостаток ссылок помогает.
АОП (Аспектно-ориентированное программирование) улучшает ООП, у них есть много полезных руководств и соглашений
Рекомендуемые книги:
Рекомендации по созданию инфраструктуры: условные обозначения, идиомы и шаблоны для многоразовых библиотек .NET
В двух словах о C # 3.0
Собран из различных книг, известных программистов C # и общих советов (не много, если что-то из этого принадлежит мне; в том смысле, что это различные вопросы, которые я задаю себе во время разработки, но это все) :
- Структуры или классы? Является ли элемент, который вы создаете, собственным значением, сделайте его структурой. Если это «объект» с атрибутами и вложенными значениями, методами и, возможно, состоянием, сделайте его объектом.
- Запечатанные классы : если вы собираетесь создавать класс и вам явно не нужно чтобы унаследовать от него, сделать его запечатанным. (Я делаю это для предполагаемого увеличения производительности)
- Don't Repeat Yourself : если вы обнаружите, что копируете (а / е) код, вам, вероятно, следует (, но не всегда ) пересмотреть свой дизайн, чтобы минимизировать дублирование кода.
- Если вам не нужно предоставлять базовая реализация для данного абстрактного класса превращает его в интерфейс.
- Принцип специализации : Каждый объект, который у вас есть, должен делать только одно. Это помогает избежать «объекта-бога».
- Использование свойств для общего доступа : Это обсуждалось снова и снова, но это действительно лучший выход. Свойства позволяют вам делать с полями то, что вы обычно не можете делать с полями, а также дают вам больше контроля над тем, как объект получен и установлен.
- Синглтоны : еще одна спорная тема, и вот идея: используйте только их когда вам это абсолютно необходимо. В большинстве случаев несколько статических методов могут служить синглтону. (Хотя, если вам абсолютно необходим одноэлементный шаблон, используйте отличный шаблон Джона Скита )
- Слабое связывание : Убедитесь, что ваши классы как можно меньше зависят друг от друга; убедитесь, что пользователи вашей библиотеки могут легко заменять части вашей библиотеки другими (или специально созданными частями). Это включает в себя использование интерфейсов, где это необходимо, инкапсуляцию (другие упоминали об этом) и большинство остальных принципов в этом ответе.
- Дизайн с учетом простоты : В отличие от глазури для торта, сейчас проще разработать что-то простое. и добавить позже, чем есть, чтобы спроектировать сложный сейчас и удалить позже.
Я мог бы выбросить часть или все это за дверь, если я:
- Написание личного проекта
- очень торопитесь, чтобы что-то сделать (но я вернусь к этому позже .... когда-нибудь .....;))
Эти принципы помогают мне в повседневной жизни кодирования и значительно улучшил качество кодирования в некоторых областях! надеюсь, что это поможет!