Существуют ли какие-либо правила для ООП?

Ответ 1

Похоже, что вы ищете, это Принципы объектно-ориентированного проектирования.

Подведены итоги принципов, шаблонов и практик гибкой разработки программного обеспечения. Эти принципы - с трудом завоеванный продукт многолетнего опыта разработки программного обеспечения. Они не являются продуктом единого мнения, но представляют собой интеграцию и работу большого числа разработчиков и исследователей программного обеспечения. Хотя они представлены здесь как принципы объектно-ориентированного проектирования, они действительно являются частными случаями давних принципов разработки программного обеспечения.

SRP Принцип единой ответственности У класса должна быть только одна причина для изменения.

OCP Объекты открытого программного обеспечения (классы, пакеты, методы и т.д.) Должны быть открыты для расширения, но закрыты для модификации.

LSP Принцип подстановки Лискова Подтипы должны быть заменяемыми для их базовых типов.

DIP Абстракции принципа обращения зависимостей не должны зависеть от деталей. Детали должны зависеть от абстракций.

ISP Принцип сегрегации интерфейса Клиенты не должны зависеть от методов, которые они не используют. Интерфейсы принадлежат клиентам, а не иерархиям.

REP Принцип эквивалентности повторного использования релиза Гранула повторного использования - гранула выпуска.

CCP Общий принцип закрытия Классы в пакете должны быть закрыты друг от друга против одинаковых изменений. Изменение, которое затрагивает закрытый пакет, затрагивает все классы в этом пакете и никакие другие пакеты.

CRP Общий принцип повторного использования Классы в пакете повторно используются вместе. Если вы повторно используете один из классов в пакете, вы снова используете их все.

ADP Принцип ациклических зависимостей Не допускайте циклов в графе зависимостей.

SDP Принцип стабильных зависимостей Зависит от стабильности.

SAP Принцип стабильных абстракций Пакет должен быть настолько абстрактным, насколько он стабилен.

Ответ 2

Не уверен в каких-либо правилах. Все эти упомянутые вещи больше похожи на парадигмы ОО для меня. Есть несколько советов, которые мы следуем,

• Разделение беспокойства
• Единая ответственность за класс
• Предпочитают композицию над наследованием
• Программирование на интерфейс
• Плюс все упомянутое Биллибобом уже

Ответ 3

Эти ОО-принципы прямо из Head First Design Patterns:

• Инкапсулируйте то, что изменяется
• Программа для интерфейса, а не реализация
• Фавор состав по наследству
• Класс должен иметь только одну причину для изменения (принцип единой ответственности)
• Подтипы должны быть заменяемыми для их базы (принцип подстановки Лискова)
• Классы должны быть открыты для расширения, но закрыты для модификации (принцип открытого закрытия)

Ответ 4

Это понятия, а не правила. На самом деле нет правил, просто решений, чтобы сделать, некоторые проекты лучше других, некоторые намного лучше других:-)

Есть много рекомендаций, хотя:-) Некоторые из них специфичны для языка (С++ пронизан ими), другие - OO. Слишком много, чтобы перечислять: -)

Сверху моей головы важны следующие:

• Свободная связь, высокая степень сцепления
• Напишите тестируемые классы, которые вы тестируете
• Использовать наследование экономно и только там, где это имеет смысл (предпочитайте композицию)
• Попробуйте придерживаться принципа открытия/закрытия.
• (самое главное) KISS

Многократно расширять и добавлять: -)

EDIT: я должен добавить, правила, которые вы указали, не уникальны для OO

Ответ 5

Согласно Прагматическим Программистам - правила:

• Держите его сухим (не повторяйте сами)
• Держите его SHY (убедитесь, что ваши классы имеют высокую степень сцепления и низкое сцепление).
• и рассказать другой GUY (Разделение проблем)

http://media.pragprog.com/articles/may_04_oo1.pdf

Ответ 6

В ООП нет "правил".

Есть 4 свойства языка, которые делают язык объектно-ориентированным или нет (это то, что вы указали в своем вопросе).

Остальная часть материала есть рекомендации. Лучшие/наиболее полезные рекомендации, которые я прочитал, GRASP

Многие из предложений не совсем понятны непрофессионалам (не-CS-майоры). Я думал, что GRASP является прагматичным и доступным.

Я думаю, что GRASP хорош, потому что он предлагает самую важную часть OO в своем названии - Assignment of Responsibility (для объектов, а не для программистов).

Два наиболее важных понятия GRASP, из которых все остальное происходит, - это связь и сплоченность. Эти две концепции/принципы управляют всеми другими шаблонами и подходами.

Кстати - я просто взял у вас интервью? Вы неправильно описали вопрос...