Head First Object-Oriented Analysis and Design

Today i finished reading one great book Head First Object-Oriented Analysis and Design By Brett D. McLaughlin, Gary Pollice, Dave West.

Examples shared in the book are brillant and great learning.I personally liked Route Finder application.

Below are few key points from the book i wanted to share.

1) About Great Software?

a) First and foremost Great software must satisfy the customer.The software must do what the customer wants it to do.

b) Also,Great software is when you use tried-and-true design patterns and principles.You have kept your objects loosely coupled,and your code open for extension and closed for modification.That also makes the code more reusable,and you donot have to rework everything to use parts of your application over and over again.

c) Great Software is well designed,well-coded and easy to maintain,reuse and extend.

2) Donot Create problems to solve problems.

3) Replace String,int constants with Enums.

4) Use Textual Description of the problem you're trying to solve to make sure that your design lines up with the intended functionality of the application.

5) Encapsulation allows you to group your application into logical parts.

6) Anytime,you see duplicated code,look for a place to encapsulate.

7) Delegation is when an object needs to perform a certain task and instead of doing that task directly,it asks another object to handle the task( or sometimes just part of a task).

8) OOAD is about writing great software.
a) Customers are satisfied when the applications work.
b) Customers are satisfied when the applications keep working.
c) Customers are satisfied when the applications can be upgraded.
d) Customers are satisfied when the applications can be reused.
e) Customers are satisfied when the applications are flexible.

9) A complete path through a use case from the first step to the last is called a scenario.

10) Most Use Cases have several scenarios,but they always share the same user goal.

11) Analysis helps you ensure your system works in a real world context.

12) Delegation shields your objects from implementation changes to other objects in your software.

13) Looking at the nouns(and verbs) in your use case to figure out classes and methods is called textual analysis.

14) Abstract classes are place holders for actual implementation classes.The abstract class defines behavior,and the subclasses implement that behavior.

15) Coding to interface rather than to implementation makes your software easier to extend.

16) Each class in your application should have only one reason to change.

17) Code once,look twice.(or more).

18) When we have a set of properties that vary across your objects,use a collection,like a Map,to store those properties dynamically.You will remove lot of methods from your classes and avoid having to change your code when new properties are added to your app.

19) Most Good designs come from analysis of bad designs.Never be afraid to make mistakes and then change things around.

20) A cohensive class does one thing really well and does not try to do or be something else.

21) Always strive for high cohension as you move through your software's design life cycle.

22) Using proven OO design principles results in more maintainable,flexible,and extensible software.

a) The Open-Closed Principle: Classes should be open for extension and closed for modification.Please remember that only way to follow OCP is not by extending another class. For example you had several private methods in a class those are closed for modification.We can add several public methods that invoked those private methods in different ways.You are extending the behavior of private methods without changing them.This is also another example of OCP.Remember its really a combination of encapsulation and abstraction.we are finding behavior that stays the same and abstracting the behavior away into the base class and then locking that code up from modification.But then when we need new behavior your subclasses handle the changes by extending the base class.This is where encapsulation comes in.You are encapsulating what varies(behavior in subclasses) away from what stays the same(the common behavior in base class).

b) Donot repeat yourself(DRY): Avoid duplicate code by abstracting out things that are common and placing those things in a single location.

c) The Single Responsibility Principle(SRP): Every object in the system should have a single responsibility and all the object services should be focused on carrying out the single responsibility.

d) Liskov Substitution Principle(LSP): SubTypes must be substitutable for their base types.

23) If you need to use functionality in another class,but you donot want to change that functionality,consider using delegation instead of inheritance.

24) Favor delegation,composition and aggregation over inheritance your software will usually be more flexible and easier to maintain,extend and reuse.

25) You should test your software for every possible usage you can think of.Be Creative!Donot forget to test for incorrect usage of the software too.You'll catch errors early,and make your customers very happy.

26) Steps involved in Typical Object Oriented Analysis & Design Project Lifecycle are

a) Feature List: Figure Out what your app is supposed to do at a higher level.

b) Use Case Diagrams: Nail Down the big processes that your app performs and any external forces that are involed.

c) Break Up The Problem: Break your application up into modules of functionality,and then decide on an order in which to tackle each of your modules.

d) Requirements: Figure out indivudual requirements for each module and make sure those fit in big picture.

e) Domain Analysis: Figure out how your usecases map to objects in your app and make sure your customer is on the same page.

f) Premilarly Design: Fill in details about your objects,define relationships between objects and apply principles and patterns.

g) Implementation: Write code,test it and make sure it works.Do this for each behavior,each feature,each use case,each problem until you're done.

i) Delivery: You are done.Release the software.

27) Your design decisions should be based on how your system will be used,as well as good OO principles.They should always make your implementation better not more complicated or harder to understand.

28) Sometimes the best code for a particular problem has already been written.Don't get hung up on writing code yourself if someone already has a working solution.

29) Use Inheritance when one object behaves like another,rather than just when the IS-A relationship applies.

Hope you will also enjoy reading this book.