1. Or how to work smarter when building solutions

2.  2:30 – 3:30 Mondays – focus on problem solving (with some terminology thrown in upon occasion)  All are welcome although those that were struggling with 139 and now 239 are particularly encouraged to attend  Review tab in Blackboard will contain assignments and schedule for the sessions (up this afternoon)

3.  Review from lab  Design

4.  What did you learn?  What is still fuzzy?  Which command characters signal EOF?  Unix  DOS

5.  Goals  To maximize programmer efficiency  By Promoting reuse Breaking a problem down into a series of small components Easy to understand Easy to repair if components are independent Spending time up front on design Rework costs more money than writing it right the first time

6.  There is no one “right” way to write code.  There are better designs and poorer designs.  Examine alternatives before proceeding.

7.  Designs should be modular  Design should follow local standards  Design should look for simplicity  Designs can/should be elegant  Designs should be generalizable to the extent possible

8.  Humans can only comprehend so much  Localizing code where each “module” does only one thing makes it easier to write and to maintain  Such design enables teams to break solutions down into pieces that each can do  Promotes reuse – a small solution may be able to be used in many other solutions. A large complex solution must often stand alone.

9.  Help us to understand.  Think of language. Our language gives us a common set of terms with which we can communicate.  Coding standards do the same.  Not following standards can lead to your code not being reused or maintained.

10.  Why write 5 lines of code when one will do?  But avoid cramming 5 different statements into one.  It is simpler to use a library routine than to build one on your own.  Simple code is more easily understood.  Simple code is more likely to be reused.

11.  There is beautiful code.  Elegant code is studied and is more likely to be reused.  Elegant code is clearly understood.

12.  You can write a solution for individual cases  OR  You can find out what those cases have in common and write a solution that will work for all of them  Look for ways to generalize what you are doing... if the exceptions overwhelm the rule, change the rule.

13.  Encapsulation – Combining into a well designed unit data and methods pertaining to an “actor” in a solution.  Requires thinking not about the task to be done, but about the different data to be manipulated.  Divides a problem up into “actors” and the “actions” that those actors take.

14.  Should be isolation – information detail should be hidden from other classes  Methods that are public should provide well known ways of interacting with those objects.  By encapsulation and hiding the details, we can make appropriate changes to the class without affecting the programs that use the class.

15.  Class and instance data – only provide public access to values that will serve users of the class.  Helper methods – any method that is designed to help other methods of the class and that are not intended for public use should be private  A method should hide how it is accomplishing its task. Documentation should include what we expect to come in (input) and what will be produced (output) and any side effects (exceptions, mutation of data). That is all!

16.  Cohesion – The degree to which parts of a module are related to one another.  In designing good modules you want a high level of cohesion.  Separate input, input validation, calculations and output.  Modules should relate to “real world” as most applications are simulating some real process.

17.  The degree to which modules require one another  We want to reduce the degree of coupling in designing modules.  Modules that access one another’s public data have a high degree of coupling.  Privatizing data and strengthening the use of method interfaces reduces coupling.

18.  Classes are the definition of the characteristics of some set of objects  An object is one member of the set.  Classes encapsulate data and operations on that data.  Objects know themselves and can answer questions about themselves through methods.  Objects (through the classes that define them) know their own “rules”.

19.  BaseStat.java BaseStat.java