Click here to Skip to main content
15,072,422 members
Articles / Desktop Programming / MFC
Technical Blog
Posted 25 Feb 2010

Tagged as


78 bookmarked

The S.O.L.I.D. Object Oriented Programming(OOP) Principles

Rate me:
Please Sign up or sign in to vote.
4.78/5 (36 votes)
25 Feb 2010CPOL4 min read
What does it take to be an Object Oriented Programmer?


What does it take to be an Object Oriented Programmer? There was a time where I believed all that meant was that you worked with a language such as C#, C++, or Java. However, the more I get acquainted with newer technologies, the more I realize that there is a set of fundamentals core to the title. And really, these fundamentals are about architecting the best, most update-able, scalable systems. Just yesterday while diving into DataObjects.NET, I was greeted by Domain Driven Design(DDD)-- a popular architectural abstraction. It motivated me to think about the basics, which is the purpose of this article.

The S.O.L.I.D. Principles of Class Design

The S.O.L.I.D. principles seem to be the least common denominator of creating great classes; even before Design Patterns. I recommend taking some time to really think about each of them and how you can apply them. Let's dive in, one by one.

The Single Responsibility Principle

There should never be more than one reason for a class to change. Basically, this means that your classes should exist for one purpose only. For example, let's say you are creating a class to represent a SalesOrder. You would not want that class to save to the database, as well as export an XML-based receipt. Why? Well if later on down the road, you want to change database type (or if you want to change your XML schema), you're allowing one responsibility's changes to possibly alter another. Responsibility is the heart of this principle, so to rephrase there should never be more than one responsibility per class.

The Open Closed Principle

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. At first, this seems to be contradictory: how can you make an object behave differently without modifying it? The answer: by using abstractions, or by placing behavior(responsibility) in derivative classes. In other words, by creating base classes with override-able functions, we are able to create new classes that do the same thing differently without changing the base functionality. Further, if properties of the abstracted class need to be compared or organized together, another abstraction should handle this. This is the basis of the "keep all object variables private" argument.

The Liskov Substitution Principle

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it. In other words, if you are calling a method defined at a base class upon an abstracted class, the function must be implemented properly on the subtype class. Or, "when using an object through its base class interface, [the] derived object must not expect such users to obey preconditions that are stronger than those required by the base class." The ever-popular illustration of this is the square-rectangle example. Turns out a square is not a rectangle, at least behavior-wise.

The Dependency Inversion Principle

Depend on abstractions, not on concretions or High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions. (I like the first explanation the best.) This is very closely related to the open closed principle we discussed earlier. By passing dependencies (such as connectors to devices, storage) to classes as abstractions, you remove the need to program dependency specific. Here's an example: an Employee class that needs to be able to be persisted to XML and a database. If we placed ToXML() and ToDB() functions in the class, we'd be violating the single responsibility principle. If we created a function that took a value that represented whether to print to XML or to DB, we'd be hard-coding a set of devices and thus be violating the open closed principle. The best way to do this would be to:

  1. Create an abstract class (named DataWriter, perhaps) that can be inherited from for XML (XMLDataWriter) or DB (DbDataWriter) Saving, and then
  2. Create a class (named EmployeeWriter) that would expose an Output(DataWriter saveMethod) that accepts a dependency as an argument. See how the Output method is dependent upon the abstractions just as the output types are? The dependencies have been inverted. Now we can create new types of ways for Employee data to be written, perhaps via HTTP/HTTPS by creating abstractions, and without modifying any of our previous code! No rigidity--the desired outcome.

The Interface Segregation Principle

Clients should not be forced to depend upon interfaces that they do not use. My favorite version of this is written as "when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class." Kinda sounds like the inheritance specific single responsibility principle.


This article was originally posted at


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Chief Technology Officer
United States United States
Pittsburgh-based developer.

Comments and Discussions

QuestionVery wonderful article Pin
Berehane24-Sep-15 7:06
MemberBerehane24-Sep-15 7:06 
GeneralMy vote of 5 Pin
Daniel Belu20-Jun-14 22:28
MemberDaniel Belu20-Jun-14 22:28 
GeneralMy vote of 2 Pin
buddy.james27-Feb-14 21:40
Memberbuddy.james27-Feb-14 21:40 
GeneralMy vote of 3 Pin
Farid Bekran29-Apr-13 1:01
professionalFarid Bekran29-Apr-13 1:01 
GeneralMy vote of 1 Pin
adglopez23-Apr-13 18:24
professionaladglopez23-Apr-13 18:24 
GeneralMy vote of 1 Pin
adglopez23-Apr-13 18:23
professionaladglopez23-Apr-13 18:23 
GeneralMy vote of 5 Pin
Aamir Khan Developer20-Apr-13 3:05
professionalAamir Khan Developer20-Apr-13 3:05 
GeneralMy vote of 2 Pin
CLX-Soft26-Feb-13 4:03
MemberCLX-Soft26-Feb-13 4:03 
GeneralMy vote of 5 Pin
Arthanarieaswaran Shanmugaraj16-Oct-12 20:41
MemberArthanarieaswaran Shanmugaraj16-Oct-12 20:41 
GeneralHelpful for new comers Pin
SERokon22-Feb-12 21:40
MemberSERokon22-Feb-12 21:40 
GeneralNice Summary Pin
MKlaus2-Mar-10 7:02
MemberMKlaus2-Mar-10 7:02 
GeneralRe: Nice Summary Pin
User 505364330-Nov-12 7:16
MemberUser 505364330-Nov-12 7:16 
GeneralMy vote of 1 Pin
NilsKodeApe1-Mar-10 22:43
MemberNilsKodeApe1-Mar-10 22:43 
General[My vote of 1] Plagiarism at its worst! Pin
usrdwz1-Mar-10 11:10
Memberusrdwz1-Mar-10 11:10 
GeneralRe: [My vote of 1] Plagiarism at its worst! Pin
micahs8-Dec-12 2:45
Membermicahs8-Dec-12 2:45 
GeneralDependency question Pin
supercat925-Feb-10 8:50
Membersupercat925-Feb-10 8:50 
GeneralRe: Dependency question Pin
Rozis26-Feb-10 13:26
MemberRozis26-Feb-10 13:26 
GeneralRe: Dependency question Pin
CurtainDog2-Mar-10 10:58
MemberCurtainDog2-Mar-10 10:58 
GeneralRe: Dependency question Pin
supercat93-Mar-10 7:30
Membersupercat93-Mar-10 7:30 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.