Docstoc

Good Programing Practice 1

Document Sample
Good Programing Practice 1 Powered By Docstoc
					Programming
   Procedural
     Algorithmic
     Linear flow
   Functional
     Sequences of functions
     Applied to data variables or other functions
   Object Oriented (OOP)
     Objects
     Communicating through messages
Procedural Programming
   Wide spread
     Languages like C , Visual basic, Pascal
   Easy to understand
     General linear flow
     Can be documented with a flow chart
     approach
   Complex programs
     Difficult manage and create
Functional Programming
   Scientific Uses
     Mathematical, Statistical, etc
     Languages like S, f#
   Conceptuality easier to understand in
    certain settings
     Graphing the sine curve of some data „x‟:
     plot(sin(x))
Object Oriented Programming
   Nearly all „modern‟ programs are
    constructed this way
     Languages like Java, C++, C#, VB.net
   Eases the burden of managing complex
    projects
     Promotion of code reuse
     Quality standards
Object Oriented Programming
   Classes
     Description or implementation of a real
     object or thing
   Objects
     Within the framework of a running program it
     is one instance of a class
   Messages
     The method by which objects communicate
     with each other
Classes
 Description of a real object or things
  characteristics
 Attributes
     These are a list of defining properties for the
      class
     Hold information about the class
   Methods
     These are the defining behaviours for the class
     Do things to or for the class
     Participate in the messaging
Classes Example
 Design of a Person class
 Attributes
     Name
     DOB
   Methods
     Move
     Speak
Objects
   Instance of a class
     Usually “initialised” with at least some of its
      attributes filled
   Initialisation
     Setting up the object for use
     Setting default attributes
   Example
     Instance of the person class with
     Name initialised to Martin
     Creates the Martin Person Object
OOP Key Concepts
   Inheritance
     Sub-class
   Encapsulation
     Class interface
   Polymorphism
     Overriding
     Overloading
   Abstraction
     Composition/aggregation
Inheritance
   Sub-Class
     Specialisation of the parent class
   A sub-class has:
     Access to the parent class methods and
      attributes
     Add new method and attributes specific to
      the specialisation
   A sub-class inherits its parents methods
    and attributes
Inheritance Example
   Consider the Person Class, sub-classes could be:
     Student
     Staff
   Both would inherit
     Person attributes: Name, DOB
     Person Methods: Move, Speak
   Student would add
     Attributes: Matric. No
     Methods: Study
   Staff would add
     Attributes: Staff ID
     Methods: Teach
Encapsulation
 Present a consistent interface to other
  objects
 Hide attribute and method logic
     Allows the changing of the internal code without
      the need to modify the external messages
   Expose only what‟s necessary
   Implemented by specifying attributes or
    methods with:
     public
     protected
     private
Encapsulation (Cont)
   Public
     All classes or objects
   Protected
     Only sub-classes and itself
   Private
     Restricted to itself only
   There are others but they are mostly
    language specific
Polymorphism
 The ability for a single method or
  function to respond differently depending
  on situation
 Overriding Polymorphism
     A sub-class redefining an inherited method
     or attribute
   Overloaded Polymorphism
     A single function changing behaviour
     depending on the type of imput.
Polymorphism Example
   Overriding Polymorphism:
     The Student sub-class redefining the “move”
     method so that they always run everywhere
     instead of walk
   Overloaded Polymorphism:
     The “+” operator can be used to sum two
     numbers but it can also concatenate two
     strings together.
Abstraction
 Simplify the complexity of the problem or
  object
 A number of forms in OOP design
     All of the previous concepts are forms of
      class abstraction
     Composition or aggregation
Aggregation and Composition
 Where objects can include or be made
  of other objects
 Composition is a special form of
  Aggregation
     Distinction is by span of the aggregate
      objects life time in relation to that of the
      containing object.
     Aggregate objects can exist without the
      containing object
     Composite objects cant
Abstraction Example
 Sub-class Passenger of class Person,
  class Car and class Wheels.
 Passenger is an aggregate of Car while
  Wheels exist only in a composition
  relationship with Car
     A Car isnt a Car without wheels
     A Car is still a Car without Passengers
OOP Development
   Styles
     Are ways to structure the development
     process
   Phases
     Are key points in the development cycle
   Methodologies
     Are frameworks to develop within
Styles
   Waterfall
     First Real attempt to structure large scale
        development
       Applies the techniques learned from
        engineering projects
       Each phase follows the last directly
       Long periods of time spent in each phase
       Tendency to over design and plan
Waterfall diagram
Styles (Cont)
   Iterative
     Short periods of time spent in each phase
     The main sequence of phases repeated
     Allows for a more dynamic development
      process
Iterative diagram
Styles (Cont)
   Combined
     Takes the best of both worlds from
      ○ Waterfall
      ○ Iterative
     Allows for
      ○ Indepth planning
      ○ Successive development cycles
Combined diagram
Development Periods
   Main Development Periods
     Requirements
      ○ Gathering information about the project from end users
     Analysis and Design
      ○ Formalisation of ideas and planning the project ahead
     Implementation
      ○ Following the plan and creating a working program
     Testing
      ○ Test defined by the requirments carried out to check
        whether the software works as expected
     Deployment
      ○ Period of rollout for the project
Development Periods
 Called Phases in a waterfall style
 Called Disciplines in a iterative style
     Where Phase is used to determine the time
      period the discipline is carried out in
     Multiple disciplines carried out
      simultaneously
Development Periods




Waterfall      Iterative
Methodologies
   Rational Unified Process (RUP)
     Initially released in 1998 by Rational Software
      (now part of IBM)
     Designed by looking at why software projects
      failed
     Created a set of good coding practices
      ○ Formalised into a development framework
     Uses a modified iterative style called a spiral
      style
      ○ Each iterative cycle shorter than the last
     Highly document driven
      ○ Both in design and expected output at the end of
        each period
Methodologies (Cont)
   Agile Development
     Developed in the mid 90‟s
     Came out of the increased dislike of the
      confining formalised approaches
     As such Agile methodologies tend not to
      produce as much paper as other methods
      ○ This is one of the biggest criticisms against it
        by the methods attackers, its also one of the
        largest pros for it by the methods heralds.
Methodologies (Cont)
   Agile Development
     Agile methods are adaptive rather than
     predictive
      ○ Plan driven methodologies try and cope with
       every eventuality up front Agile methods try
       and adapt to change as it happens
     Agile methods are people oriented not
     process oriented
      ○ More face to face contact with users
Methodologies (Cont)
   Agile Guidelines
     Customer satisfaction by rapid, continuous delivery of useful
        software
       Working software is delivered frequently (weeks rather than
        months)
       Working software is the principal measure of progress
       Even late changes in requirements are welcomed
       Close, daily cooperation between business people and
        developers
       Face-to-face conversation is the best form of communication
       Projects are built around motivated individuals, who should be
        trusted
       Continuous attention to technical excellence and good design
       Simplicity
       Self-organizing teams
       Regular adaptation to changing circumstances
Methodologies (Cont)
   Extreme Programming
     An extension of an Agile Methodology
   Has 12 main rules drawn from the agile
    manifesto:
Extreme Programming
   The Planning Game
     Requirement gathering
     User Stories
   Small Releases
     Start with the smallest useful feature set
     Release early and often
   System Metaphor
     Project has an over riding purpose which should
      influence the best practices used, ie naming
      conventions
   Simple Design
     Always use the simplest design that gets the job
      done
Extreme Programming
   Continuous Testing
     Unit Testing
     Acceptance testing
   Refactoring
     Altering the code for readability, duplicates,
      elegance, etc
   Pair Programming
     Two programmers at one machine
     Code reviewed as it is written
   Collective Code Ownership
     All programmers expected to be able to work on any
      part of the code.
Extreme Programming
   Continuous Integration
     All changes to parts of the code base are integrated in to
      the main daily
   40-Hour Work Week
     Overtime frowned upon
     Suggests problems with the project as a whole
   On-site Customer
     Development team has access to an end user at all times
     Questions answered immediately
   Coding Standards
     All code to the same standards
     All standards agreed before project starts
     All programmers code should be indistinguishable from
      others
Extreme Programming
   Emphasis on
     Continuous releases
     Simplicity
     Testing
     Refactoring
     Pair Programming
Methodologies (Cont)
   Agile Development (XP, etc)
       Low criticality
       Senior developers
       Requirements change very often
       Small number of developers
       Culture that thrives on chaos
   Formalised process (RUP, etc)
       High criticality
       Junior developers
       Requirements don't change too often
       Large number of developers
       Culture that demands order
Communication
   Groups
     End Users
     Other Developers
   Different forms
     Interview
     Documentation
      ○ Written
      ○ Diagram
     Dependent of Phase and Group
Developer Communication
   Needs
     Precise
     Concise
     Simple enough for everyday use
     Complex enough to cover most situations
   Diagrammatic
     Unified Modelling Language (UML)

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:20
posted:4/9/2010
language:English
pages:41