Summary of Programming Methods: Programming in the Large with Design Patterns and slides
52 views 3 purchases
Course
Programming Methods (2IPC0)
Institution
Technische Universiteit Eindhoven (TUE)
Summary of "Programming in the Large with Design Patterns" with addition of the information from the slides. It contains all the information on different design patterns.
- Product: machine-executable `working' program or component
- Product documentation: artifacts to support product (design)
- Process: the way persons work (individually, or as a team)
- Process documentation: describes/prescribes a process
- Technique: `Divide and Conquer'
o Split problem into subproblems ( Decomposition)
o Solve subproblems independently ( Recursion possible)
o Combine subproblem solutions into total solution ( Integration )
- Precondition: Predicate in terms of global variables and parameters
- Postcondition: Predicate in terms of global variables and parameters
o \old(v) denotes value of v on entry
o Typically used for procedures, not for functions, but can involve pseudo-variable \result
- Returns: Function of global variables and parameters – typically used for functions
- Contract species which problem is solved, by precondition and postcondition
o User doesn’t need to know how the problem is solved
o Provider doesn’t need to know what the solution is used for
- Abstract = to ignore/ suppress what is considered irrelevant
- Abstract from how a subproblem is solved, through a speciation.
- Abstract from which subproblem is solved, through parameters.
- Abstract from how a solution is used, through a speciation.
- Thinking in terms of dependencies is key (A depends on B so if B changes so should A but not wise versa)
- Advantages of divide and conquer
o Gives solution of more complex problems
o Organizes communication about solution domain
o Facilitates parallel construction by a team
o Improves ability to plan work and track progress
o Improves ability to work together – review design, unit testing, stepwise integration
o Improves so that changes affect few components
o Improves possibilities for reuse
- Disadvantages of divide and conquer
o Top level divisions are hard to make
o Separation often brings overhead
o Result looks bigger but has explicit structure
o Functions cant be specified/designed/implemented in isolation – considered in related groups
- Guidelines for Functional Decomposition
o Maximize cohesion (what belongs together goes together)
o Minimize coupling (measure of connectedness between modules), so minimized dependency
o Each function should solve a single well defined problem
o Limit the size of the interface, so not pass unnecessary data
o Each problem solved in one place – don’t repeat yourself
o Avoid code replication
o No more that few dozen lines with limited nesting depth
o Cyclomatic complexity is a good metric – if more than 8 should consider a sub division
- Generalization
o Solving a more general problem than required – improves reusability
o Generalize by means of parameters not global variables
o Decomposing a problem into simpler versions of itself gives tise to recursion
- Failure : product deviates from requirements during use/operation
- Defect: product can somehow lead to failure
o Decrease predictability
o Concern risks – uncertainty
, o Increases with higher system complexity
o Detecting = Reviewing and Testing, Removing Defects = Testing and Debugging
- Mistake: human action causing a fault
o Misunderstandings
o Overlooking a case in requirements
o Having incorrect algorithm
o Ty[ping error
o Making an unwanted assumption
o Dealing
Admit, prevent, minimize consequences, detect presence, localize defects, repair, trace,
learn from them
- Error : difference between actual and specified/expected result
- Test cases
o Black-box, or test-to-specifications, or functional – tests functionality
o Glass-box, or test-to-code, or structural – tests internal logic
- A Design Pattern is an outline of a general solution to a design
- problem, reusable in multiple, diverse, specific contexts.
Chapter 4: Programming in the Large I – Subroutines
4.1 Black Boxes
- Subroutines help with complexity
- Referred to as black boxes
- Inside of the black box is implementation
- Rules of black boxes:
o The interface of a black box should be straightforward, well-defined, and easy to understand.
o To use a black box, you shouldn't need to know anything about its implementation; all you need to know
is its interface. (should be able to change the implementation of the box if the behavior seen from
outside is the same).
o The implementor of a black box should not need to know anything about the larger systems in which the
box will be used.
- Interface also includes a specification of what the box does and how it can be controlled - interface of a subroutine
has a semantic as well as a syntactic component.
- Syntactic part of the interface tells you just what you have to type in order to call the subroutine
- Semantic component specifies exactly what task the subroutine will accomplish
- Syntactic and semantic -- collectively as the contract of the subroutine
- Comments that you write for the subroutine should make the contract very clear
- Subroutines are not the only example of black boxes in programming
4.2 Static Subroutines and Static Variables
- Every subroutine in java must be defined inside some class
- Static vs non-static subroutines
o A static subroutine is a member of the class itself.
o Non-static subroutines only become relevant when you are working with objects.
- Subroutines = method
- Body of subroutine = the statements within the { … }
- Modifier = such as static/public/etc. before the method name
- Void = no value is returned
- Parameter list = method something( int paremeter_1, double parameter_2), where int and double are type
parameter names
- Subroutine-name(parameters); if the subroutine that is being called is in the same class.
- class-name. Subroutine-name(parameters); if the subroutine is defined elsewhere, in a different class.
- Local variables = declared inside subroutines
- Global variables = declared inside the class
- When you declare a local variable in a subroutine, you have to assign a value to that variable before you can do
anything with it
- Member variables, on the other hand are automatically initialized with a default value.
, 4.3 Parameters
- Parameters in a subroutine definition are called formal parameters or dummy parameters ( like a name )
- The parameters that are passed to a subroutine when it is called are called actual parameters or arguments (
like a value )
- Signature of subroutine = knowing the name of it and the type of parameters it has
- Overloading = having subroutines with the same name, but different parameter. If have same parameters but
different return types would not work.
- If the caller violates the contract by passing an invalid string as the actual parameter, the subroutine responds
by throwing an exception of type NumberFormatException.
- IllegalArgumentExceptions in response to bad parameter values.
o throw new IllegalArgumentException( error-message );
o static void print3NSequence(int startingValue) {
o
o if (startingValue <= 0) // The contract is violated!
o throw new IllegalArgumentException( "Starting value must be positive." );
o .
o . // (The rest of the subroutine is the same as before.)
- Javadoc comment must be placed just before the subroutine that it is commenting on
- If comment will contain only basic information such as the name and type of a member variable or the name,
return type, and parameter list of a subroutine = syntactic information
- Doc tags for Javadoc
o @param parameter-name description-of-parameter
o
o @return description-of-return-value
o
o @throws exception-class-name description-of-exception
- static import
o import static package-name.class-name.static-member-name;
- convenient way to express the contract of a subroutine is in terms of preconditions (something that must be true
when the subroutine is called) and postconditions (something that will be true after the subroutine has run).
- public class Bank {
o private static double interestRate;
o interestRate = 0.05; // ILLEGAL:
o . // Can't be outside a subroutine!:
- "final" can be applied to a variable declaration to ensure that the value stored in the variable cannot be changed
after the variable has been initialized
- The portion of the program source code where the variable is valid is called the scope of the variable.
Programming in the Large with Design Patterns Chapter 1: Introduction to Design Patterns
- Facade defines a higher-level interface that makes the subsystem easier to use.
- Important characteristics of patterns:
o design (and more generally engineering) is about balancing conflicting forces or constraints.
o design patterns provide general solutions (not exact solutions)
o designs can’t be generalized to all situations/cases
- A software design pattern is a reusable solution to a reoccurring software design problem. A design pattern
provides a mapping from a specific design problem to a generic solution.
- Four main categories of software patterns are: analysis patterns, architectural patterns, design patterns and
programming idioms.
- Architectural Patterns:
o At the architectural level, components are programs and subsystems – Programming Idioms – “recipe” so
platforms (like Java) contain “cookbooks” of simple functions available.
o For mid-level design, components are classes and objects – Design Patterns.
o Architectural Pattern - high-level plan for organizing the top-level components of a program or software
system.
- Algorithms are not design patterns:
The benefits of buying summaries with Stuvia:
Guaranteed quality through customer reviews
Stuvia customers have reviewed more than 700,000 summaries. This how you know that you are buying the best documents.
Quick and easy check-out
You can quickly pay through credit card or Stuvia-credit for the summaries. There is no membership needed.
Focus on what matters
Your fellow students write the study notes themselves, which is why the documents are always reliable and up-to-date. This ensures you quickly get to the core!
Frequently asked questions
What do I get when I buy this document?
You get a PDF, available immediately after your purchase. The purchased document is accessible anytime, anywhere and indefinitely through your profile.
Satisfaction guarantee: how does it work?
Our satisfaction guarantee ensures that you always find a study document that suits you well. You fill out a form, and our customer service team takes care of the rest.
Who am I buying these notes from?
Stuvia is a marketplace, so you are not buying this document from us, but from seller YAGOARUS. Stuvia facilitates payment to the seller.
Will I be stuck with a subscription?
No, you only buy these notes for $3.74. You're not tied to anything after your purchase.
