Any fool can write code that a computer

Any fool can write code that a computer can understand. Good programmers write code that humans can understand!

Software Architecture • What frameworks are you going to use? • Are you using MVC? What other architectural patterns make sense for you? • Are you building a RESTful app or using SOAP and WSDL or something else entirely? • How will you test your system? Unit Testing? ? ? • Will you build a continuous deployment environment? • Where will you keep your code? How will you handle version control?

Good Code vs Bad Code Smells: Rigidity Fragility Immobility Viscosity Needless Complexity • Needless Repetition • Opacity • • • * What the frapachino?

Doing a great job at this stage makes next term easy!!! Unfortunately, mistakes made here are magnified when you start coding… It always takes longer than you expect, even when you take into account Hofstadter's Law. — Hofstadter's Law

Writing Clean Code

Uncle Bob, Joshua and the SOLID principles Joshua Bloch Robert C Martin

What does this do? • Hmmm…

Good Naming helps…

But it’s still too long and complicated…

What does this do? public double calc. Pizza. Price() throws Exception { double pizza. Price = this. calculate. Pizza. Size. Price (this. pizza. Size); pizza. Price += this. calculate. Pizza. Toppings. Price(); pizza. Price += this. calculate. Taxes. On. Pizza. Order(ONTARIO_TAX_RATE); return pizza. Price; } Well written code reads like a book… Make your methods as small as possible - Then make them smaller! A well-written method should not exceed 10 lines or so

What we were taught was wrong… “Every non-Javadoc comment needed in your code is an apology for not writing clear, concise code. ” - Robert C. Martin Well written code should read like a book

But does this really belong in a Pizza. Order Class? Maybe… public double calc. Pizza. Price() throws Exception { double pizza. Price = this. calculate. Pizza. Size. Price (this. pizza. Size); pizza. Price += this. calculate. Pizza. Toppings. Price(); pizza. Price += this. calculate. Taxes. On. Pizza. Order(ONTARIO_TAX_RATE); return pizza. Price; } Maybe not… The best way to decide is to have a conversation over a Class Diagram! We will re-visit this discussion later…

How to have a conversation with your team about the design of your code Class Diagrams

Dependency • Whenever a class A uses another class (or interface) B, then A depends on B. – A cannot carry out it's work without B, and A cannot be reused without also reusing B. – In such a situation the class A is called the "dependant" and the class or interface B is called the "dependency". • When there is a dependency between classes, you have coupling. Every program needs some coupling or it would do nothing. • However, we want to make our classes as loosely coupled as possible.

What does this really do? 1. 2. 3. 4. Declares a reference variable called b 1 of type Button Instantiates a Button Object from the Button Class Runs the Button Constructor Returns the address of the Button Object (which is in the heap somewhere) to the reference variable b 1. 5. b 1 now holds the address of the Button Object • Sometimes, we say that b 1 is the object for simplicity. (However, always remember that b 1 actually holds the address of the object, not the object itself)

‘Holds a Reference’ When an object has an instance variable that is a reference variable (holds the address of another object), we say that the object ‘holds a reference’ to the other object

Let me ask you… • Do you remember (in your Brain) where to find every Pay. Phone in the world? • Do you like to know where your Cell. Phone is at all times? • Is it very important to you to know where your Heart is at all times? • Are you willing to loan your Cell. Phone to a friend? • Are you willing to loan your Heart to a friend?

Hmm…There is a lot of disagreement about this… • We use a Pay. Phone (but we don’t keep its address) – Dependency • We use/own a Cell. Phone and always want to know where it is but we are willing to share it – Aggregation. • We own a Heart and it lives and dies with us. – Composition Grady Booch

Relationships Composition Aggregation Dependency

Let’s draw a Class Diagram for our Pizza CC Joint 2 2

What do you think?

What do you think? Enums make much more sense

What do you think? • Hmmm…Aren’t these just different states? • Can a pizza be cooking and on. Delivery?

What do you think? ? ? ?

What do you think? WTF? ? ?

X What do you think? Single Responsibility Principle There should never be more than 1 reason to change a class What people may ask you to change this class?

A Better way…Each class is responsible for one thing…There should only ever be one reason for a class to change … … Often, domain objects reduce to this…

Login Functionality • Security! – Prevent unauthorized access – Allow authorized access – Tokens? Session? Hmmm. – Spring? . net? Start Now!!!!

What do you think? User name address username password +login +logout +add. User +delete. User +update. User +order. Supplies +pay. Supplier

Open Closed Principle “Software entities (classes, modules, functions, etc. ) should be open for extension, but closed for modification“ If it ain’t broke, don’t touch it!!! SOLID If we want to add functionality to our program, we don’t want to change what we’ve already written

Open Closed Principle • Beware of ‘Shotgun Surgery’!!! – Violating the Open Closed Principle results in the need for shotgun surgery. – Every time we want to add functionality to our code-base, we need to make changes in many, many classes!!! – This leads to higher code viscosity and lower efficiency as you approach the deadline!

Demo 0 a Lighting our way…

Just for fun… What is the relationship between Button and Lamp? Composition

Tightly Coupled Button Lamp Button and Lamp are tied together for life!

Demo 0 b Injecting an object through the Constructor

• At least now the lamp has a separate life from the button • We can pass the same lamp to multiple buttons if we like

Just for fun… What is the relationship between Button and Lamp? Aggregation

Still Tightly Coupled (But slightly looser) Button Lamp Button and Lamp are tied together, but not for life!

Dependency Inversion Principle “Entities should depend on abstractions and not on concretions. It states that the high level module must not depend on the low level module, but they should depend on abstractions. ” SOLID

Demo 0 c Polymorphic Interfaces Remember that a reference variable can hold a reference to a child object. . . or an object that implements a particular interface!

UML Loosely Coupled Code!

Loosely Coupled ce to n e r e f e r a holds Button Polymorphic Interface Implements Lamp . . . Fan Heater

Why Bother? Tightly Coupled Code Loosely Coupled Code

Good Rule of Thumb Depend on abstractions, not on concretions. Rich’s thought: You don’t need to do this everywhere. Just between major architectural boundaries Separate out the Database, the web view, any physical devices, any frameworks, services, or any code that you think could change, etc

TDD – Test Driven Development • Who has heard of this? • Who intends to use this? • What does TDD really buy us? ? ? – Consistent Viscosity!!!!! – Make changes, without fear. Find errors immediately! Uncle Bob’s Parable…Losing our Tests or Losing our Code… The tests become our specifications

TDD Works! • http: //weblogs. asp. net/mhawley/114005

Connecting to our Database… p p A Code Smells: ain M st rking e t n’t a wo a • Rigidity c We ithout a. DAO w Pizz • Fragility • Immobility • Viscosity • Needless Complexity • Needless Repetition • Opacity Not Easily Testable Main. App is dependent on our Pizza. DAO 1 Class (Ho w and Pizza. DAO 1 be Slo the w w Class is tightly da n w ill t bound to the it) tab e hes eve as hav e t ry e (a e t ests database tim nd o h e w res it e t tor est e ? ) If we want to change to a different DAO, We have to change Main. App

A Better Way…DAO Pattern We can ‘inject’ the object that we want to use DAO Note that we can plug in any DAO we want without having to change Main. App!!!

A better way…DAO Pattern http: //best-practice-software-engineering. ifs. tuwien. ac. at/patterns/dao. html http: //www. tutorialspoint. com/design_pattern/data_access_object_pattern. htm https: //en. m. wikipedia. org/wiki/Loose_coupling

Dependency Injection Containers • Dependency Injection is important to understand. • It sounds scary but it’s not • Factory Patterns. • Many Container Frameworks – Spring (Java and. NET) – Unity – Etc. http: //www. javacreed. com/why-should-weuse-dependency-injection/

This is just the tip of the iceberg… • Clean Code is a complete discipline and philosophy… • It includes a set of principles, a bunch of design patterns and a whole lot of arguments. • It is like chess…learn in an hour, perfect over a lifetime. • It is the difference between a coder and a software architect. .

Put this on your office wall I’m much too busy to waste time writing code quickly! ZOP

A Stitch in time…saves nine! • A little effort expended sooner to fix a small problem prevents it from becoming a larger problem requiring more effort to fix later. • A little preparation can eliminate the need for repairs later.

Watch this!!! • https: //www. lynda. com/Javatutorials/Foundations-Programming-Object. Oriented-Design/96949 -2. html

Uncle Bob, Joshua and the SOLID principles Joshua Bloch Robert C Martin