Object-Oriented

Understand our problem, plan our solution, and build it, or rather analysis, design, and programming is the key to good ~ just about anything.  Partly the key to life. Define or frame the problem or challenge, think up some idea of how to solve the problem, and figure out how to execute that idea or plan, AND go do it.  Object-Oriented, you will usually see another word right beside them, Object-Oriented Programming, Object-Oriented Design, or Object-Oriented Analysis. These are all connected and refer to the idea that to write any piece of software we need to do three things.  Analysis, design, and build it, which could be framed development or programming are the keys to understanding our problem, planning our solution, and solving the problem.

I will admit Object-Oriented Programming, Object-Oriented Design, or Object-Oriented Analysis are a bunch of buzz words and we do love our Buzzword-Bingo. I may have to build an online Buzzword-Bingo board to play on my phone someday. But they do really help. There is a conceptual idea of the design of the solution.  And by conceptual I mean writing no code, diagrams YES, sketches on the whiteboard, YES, written descriptions, YES, but no code. This is a thing people need to practice almost as much as they need to practice writing lines of code that work. I remember in school, there was a class on Programming Logic and Design. Students took the class, and from then on, I never saw them referring back to the steps or techniques used taught in that class.

So how do we go about learning Analysis of a problem, or to turn it to Object-Oriented Analysis? What are the steps here?

What is an object?
What is a class, and then an abstraction of that class? And how do we encapsulate that?
How do we apply inheritance and polymorphism, and what are they?

How does UML play into this?
What about Use Cases, with their actors, scenarios, and user stories?
And what about Domain Modeling, which is really like modeling the application, with its classes, and class relaationships and responsibilites?
 So somewhere along the lines you should learn about class diagrams, and how you can convert them to code.
But are we really ready to code yet, or do we still need to think about sequence diagrams and understanding design patterns.


Ok fine, I guess I will write more about this phase of Object-Oriented in another blog.  I guess we could talk about SOLID over there. But for now, know that SOLID is S is for the Single Responsibility Principle; O, the Open/Closed Principle; L, the Liskov Substitution Principle; I is the Interface Segregation Principle; and D is the Dependency Inversion Principle.