Are there any rules for OOP?

Question

Hey all,

Recently I heard that there are 9 rules for OOP(Java). I know only four as Abstraction, Polymorphism, Inheritance and Encapsulation. Are there any more rules for OOP?

Answer 1

These are concepts, not rules. There are no rules really, just decisions to make, some designs are better than others, some much better than others :-)

There are plenty of guidelines though :-) Some are language specific (C++ is riddled with them) others are OO specific. Too many to list though :-)

Off the top of my head, important ones are:

• Loose coupling, high cohesion
• Write testable classes, which you test
• Use inheritence sparingly and only where it makes sense (prefer composition)
• Try stick to the open/close principle.
• (most important) KISS

Plenty to expand upon and add :-)

EDIT: I should add, the rules which you listed are not unique to OO

Answer 2

Not sure about any rules. All these mentioned things are more like OO paradigms to me. There are few advices we follow like,

• Separation of Concern
• Single Responsibility per Class
• Prefer Composition over Inheritance
• Programming to Interface
• Plus all mentioned by Billybob, already

Answer 3

Seems like what you're looking at are the Principles of Object-Oriented Design.

Summarized from Agile Software Development Principles, Patterns, and Practices. These principles are the hard-won product of decades of experience in software engineering. They are not the product of a single mind, but they represent the integration and writings of a large number of software developers and researchers. Although they are presented here as principles of object-oriented design, they are really special cases of long-standing principles of software engineering.

SRP The Single Responsibility Principle A class should have only one reason to change.

OCP The Open-Closed Principle Software entities (classes, packages, methods, etc.) should be open for extension, but closed for modification.

LSP The Liskov Substition Principle Subtypes must be substitutable for their base types.

DIP The Dependency Inversion Principle Abstractions should not depend upon details. Details should depend upons abstractions.

ISP The Interface Segregation Principle Clients shold not be forced to depend upon methods that they do not use. Interfaces belong to clients, not to hierarchies.

REP The Release-Reuse Equivalency Principle The granule of reuse is the granule of release.

CCP The Common Closure Principle The classes in a package should be closed together against the same kinds of changes. A change that affects a closed package affects all the classes in that package and no other packages.

CRP The Common Reuse Principle The classes in a package are reused together. If you reuse one of the classes in a package, you reuse them all.

ADP The Acylcic Dependencies Principle Allow no cycles in the dependency graph.

SDP The Stable Dependencies Principle Depend in the direction of stability.

SAP The Stable Abstractions Principle A package should be as abstract as it is stable.

Answer 4

These OO principles are straight from Head First Design Patterns:

• Encapsulate what Varies
• Program to an Interface, rather than an Implementation
• Favour Composition over Inheritance
• A Class should have only one reason to Change (Single Responsibility Principle)
• Sub-Types must be substitutable for their Base (Liskov Substitition Principle)
• Classes shoule be Open for extension, but Closed for Modification (Open-Closed Principle)

Answer 5

According to the Pragmatic Programmers - the rules are:

• Keep it DRY (Don't Repeat Yourself)
• Keep it SHY (Ensure that your classes have high cohesion and low coupling)
• and tell the other GUY (Separation of concerns)

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

Answer 6

There are no "Rules" to OOP.

There are 4 language properties that make a language object-oriented or not (these are the things you listed in your question).

The rest of the material out there are guidelines. The best/most helpful guidelines I've read are GRASP

Many of the suggestions are not readily understandable by laymen (non-CS majors). I thought GRASP was pragmatic and approachable.

I think GRASP is nice because it suggests the most critical part of OO in its name - Assignment of Responsibility (to objects not programmers).

The two most critical GRASP concepts from which everything else derives are coupling and cohesion. These two concepts/principals drive all other patterns and approaches.

BTW - did I just interview you? You transcribed the question incorrectly...