Object Oriented Design Principles

Object Orientated Design Principles

https://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29
https://xmruibi.gitbooks.io/interview-preparation-notes/content/OOD/index.html
http://www.coderanch.com/t/660124/Wiki/Immutable-Object


Cracking the Coding Interview Approach:

Object-oriented design questions require a candidate to sketch out the classes and methods to implement technical problems or real-life objects. These problems give-or at least are believed to givean interviewer insight into your coding style. These questions are not so much about regurgitating design patterns as they are about demonstrating that you understand how to create elegant, maintainable object-oriented code. Poor performance on this type of question may raise serious red flags.

� How to Approach

Regardless of whether the object is a physical item or a technical task, object-oriented design questions can be tackled in similar ways. The following approach will work well for many problems.

Step 1: Handle Ambiguity Object-oriented design (OOD) questions are often intentionally vague in order to test whether you'll make assumptions or if you'll ask clarifying questions. After all, a developer who just codes something without understanding what she is expected to create wastes the company's time and money, and may create much more serious issues. When being asked an object-oriented design question, you should inquire who is going to use it and how they are going to use it. Depending on the question, you may even want to go through the "six Ws": who, what, where, when, how, why. For example, suppose you were asked to describe the object-oriented design for a coffee maker. This seems straightforward enough, right? Not quite. Your coffee maker might be an industrial machine designed to be used in a massive restaurant servicing hundreds of customers per hour and making ten different kinds of coffee products. Or it might be a very simple machine, designed to be used by the elderly for just simple black coffee. These use cases will significantly impact your design.

Step 2: Define the Core Objects Now that we understand what we're designing, we should consider what the "core objects" in a system are. For example, suppose we are asked to do the object-oriented design for a restaurant. Our core objects might be things like Table, Guest, Party, Order, Meal, Employee, Server, and Host.

Step 3: Analyze Relationships Having more or less decided on our core objects, we now want to analyze the relationships between the objects. Which objects are members of which other objects? Do any objects inherit from any others? Are relationships many-to-many or one-to-many? For example, in the restaurant question, we may come up with the following design: Party should have an array of Guests. Server and Host inherit from Employee. Each Table has one Party, but each Party may have multiple Tables. There is one Host for the Restaurant. Be very careful here-you can often make incorrect assumptions. For example, a single Table may have multiple Parties (as is common in the trendy"communal tables" at some restaurants). You should talk to your interviewer about how general purpose your design should be.

Step 4: Investigate Actions At this point, you should have the basic outline of your object-oriented design. What remains is to consider the key actions that the objects will take and how they relate to each other. You may find that you have forgotten some objects, and you will need to update your design. For example, a Party walks into the Restaurant, and a Guest requests a Table from the Host. The Host looks up the Reservation and, if it exists, assigns the Party to a Table. Otherwise, the Party is added to the end of the list. When a Party leaves, the Table is freed and assigned to a new Party in the list.