What principles do you generally follow when doing class design?
Asked
Active
Viewed 2,234 times
12 Answers
28
Principles Of Object Oriented Class Design (the "SOLID" principles)
- SRP: The Single Responsibility Principle A class should have one, and only one, reason to change.
- OCP: The Open Closed Principle You should be able to extend a classes behavior, without modifying it.
- LSP: The Liskov Substitution Principle Derived classes must be substitutable for their base classes.
- ISP: The Interface Segregation Principle Make fine grained interfaces that are client specific.
- DIP: The Dependency Inversion Principle Depend on abstractions, not on concretions.
Source: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
Video (Uncle Bob): Clean Coding By Robert C. Martin ( Uncle Bob )
Sumit Chourasia
- 2,394
- 7
- 30
- 57
Patrick McElhaney
- 57,901
- 40
- 134
- 167
5
The S.O.L.I.D. principles.
Or at least I try not to steer away too much from them.
Germán
- 4,525
- 3
- 31
- 37
4
The most fundamental design pattern should be KISS (keep it simple stupid) Which means that sometimes not using classes for some elements at all it the right solution.
That and CRC(Class, Responsibility, Collaborators) cards (write the card down in your header files, not on actual cards that way they because easy to understand documentation too)
Robert Gould
- 68,773
- 61
- 187
- 272
3
As mentioned above, some of the fundamental Object Oriented Design principles are OCP, LSP, DIP and ISP.
An excellent overview of these by Robert C. Martin (of Object Mentor) is available here: OOD Principles and Patterns
Michael Harding
- 171
- 1
- 2
- 5
2
The "Resource Acquisition Is Initialization" paradigm is handy, particularly when writing in C++ and dealing with operating system resources (file handles, ports, etc.).
A key benefit of this approach is that an object, once created, is "complete" - there is no need for two-phase initialization and no possibility of partially-initialized objects.
Matt Dillard
- 14,677
- 7
- 51
- 61
1
Domain Driven Design is generally a good principle to follow.
Patrick McElhaney
- 57,901
- 40
- 134
- 167
Ian P
- 12,840
- 6
- 48
- 70
0
A thing which I would like to add to all this is layering, Define layers in your application, the overall responsibility of a layer, they way two layers will interact. Only classes which have the same responsibility as that of the layer should be allowed in that layer. Doing this resolves a lot of chaos, ensures exceptions are handled appropriately, and it makes sure that new developers know where to place their code.
Another way to design is by designing your class to be configurable creating a mechanism where the configuration can be plugged in your class, rather than overriding methods in sub classes, identify what changes, see if that can be made configurable and ensures that this functionality is derived from configurations
prashant
- 1,382
- 1
- 13
- 19
0
Basically I get away with programming to interfaces. I try to encapsulate that which changes through cases to avoid code duplication and to isolate code into managable (for my brain) chunks. Later, if I need, I can then refactor the code quite easily.
Statement
- 3,888
- 3
- 36
- 45
0
SOLID principles and Liskov's pattern, along with Single responsibility pattern.
-
3"Single responsibility" is the S in SOLID, and "Liskov" is the L. :-) – Patrick McElhaney Nov 05 '08 at 15:39
-2
I usually try to fit the class into one of the oo design patterns.
lajos
- 25,525
- 19
- 65
- 75
-
2Don't fit classes into a design pattern - use the pattern if it fits. Or your code wil be bloated! – khebbie Feb 03 '09 at 12:08
-
That's the usual behavior of someone that just learned the patterns. Don't use a design pattern just for the sake of it. – Padu Merloti Jan 12 '10 at 19:53