Final Flashcards
Method Overloading
class can have more than one method with same name (as long as parameters have different types or diff num of parameters)
Optional Arguments
includes default value
- we can choose to include or omit the parameter when calling method
ex. Calc(int a, int b = 3)
if b is not given a value when calc is called, then b takes on the value of 3
(optional parameters defined at the end of a parameter list)
Value Tuples
data structure that holds ordered list of up to 7 elements (can be of different data types
ex.
(double, double) roots = (1.1, 2.2)
Main functionality:
- return multiple values from a method
ex. Quadratic Equation
public (double, double) GetRoots()
{
return (x1, x2)
}
calling the method
(x1, x2) = eq. GetRoots();
Named Arguments vs Positional arguments
Positional:
Divide (int numerator, int denominator)
int result = Divide(4, 2)
(value of parameters associated with position they correspond to)
Named:
Divide (int numerator, int denominator)
int result = Divide(denominator: 2, numerator: 4)
(as long as your know the name of the parameter, we don’t have to match order of arguments to order of parameters)
- improves readability
- can be used with positional arguments as long as (1. positional arguments do not come after a named argument 2. they are in the correct position that they correspond to)
String Formating
Format:
{variable:Axx}
A (format specifier):
- F = floating point
- D = integer
- E = scientific
- C = currency
- P = percent
xx (precision specifier):
(for F and E): specify number of decimal digits
(for D) spcify minimum num of digits
Risks of mutation
- Alias
multiple references for same mutable object
(both reference point to same data therefore when one is modified, the other is too) - Mutation undermines Iterator
ex. mutating objects in body of a foreach loop - Mutable objects make simple –> complex
contracts cannot be enforced in 1 place due to there being multiple places for mutation - Mutable objects reduce changeability
- change could produce subtle bugs
Role of immutable types
Make Code
- Correct
- not susceptible to bugs via aliasing (immutable references point to same object) - Comprehensible
- immutable object / ref mean same thing (easier for reader to infer from code) - Changeable
- obj/ ref can’t be changed at runtime ( therefore code that depends on immutable obj / ref doesn’t need to be revised when program changes)
How specification can address risk of mutation
- assume mutation of inputs is disallowed if specification does not describe mutation
- include mutation info in method spec (include frame condition)
Recursion and its implementation
method / function calls itself
recursive functions have 2 key components:
1. base case: simplest / smallest instance of problem (cannot be decomposed)
- coresponds to emptiness: zero, empty string, list etc
- recrusive step:
- decomponses larger instance into smaller / simpler instances (solve by recursive calls + recombine results to produce solution of original problem)
When to use recursion over iteration + common mistakes in implementation
recursion is alt to iteration
1. problem is naturally recursive (Fibonacci)
2. data is naturally recursive (file)
Mistakes:
1. base case is missing
2. recursive step doesn’t reduce into a smaller problem
What is UML and its function?
UML –> unified modeling language
Function:
communicate design + visualize relationship between diff parts of program
- illustrate connection between set of classes used in program
(UML is language independent –> doesn’t matter if C#, Java etc)
UML Class Diagram
simple version: rectangle with only name of class (used to hide / abstract its members)
[] –> rectangle
[Class name]
[Fields]
[Methods]
Fields –> represents Class attributes
- list all fields (each appears on one line)
fieldName: fieldType
ex.
-polynomial: string
Methods –>
- list all methods (each on one line)
method name (paramater: type [separated by comma]): returnType)
ex.
+SetPolynomial (): bool
+ IsValidPolynomial (polynomial: string): bool
UML Visibility Symbols
Methods + Fields
- (private member)
+ (public member)
Fields:
{readonly} (read only field)
«property» (property is put in same section as fields)
Methods:
Static: (underline the whole line)
Interface: (use «_space;» on line preceding name
ex.
«interface»
IEqutable
Delegate:
«delegate» Function(a:double):double)
in/ out/ ref:
put them in [ ] just before parameter name
ex.
- GetUserInput([out] num: double): bool
UML Relationships
diff calsses are connected via diff types of line + arrows
- Association
( represents when 2 classes have a ‘using’ or ‘working’ or ‘has-a’ relationship )
(solid line with either 1 (unary associatoin) or 2 (binary association ) arrows) - Implementation (realization)
(dotted line with open arrow)
(represents relationship between interface and implementation) - Generalization (inheritance)
(solid line with open arrow)
relationship for inheriteance (‘is-a’ relationship)
interfaces
- reference type (implicitly public)
- provide contract / specification between function members (i.e methods / properties)
(doesn’t define instances/ fields)
interface IMyEquatable<T>
{
// interface members
bool Equals (T obj);
}</T>
class implement the above interface:
public class Car: IMyEquatable<Car>
{
// Class body that includes implementation of Equals
}</Car>
benefits of interface
- sole purpose to specify contract for client
- allows for multiple diff representations of ADT to coexist
!!! a class can implmement multiple interface!!!
- allow performance trade-off
- flexibility in providing invariants
- documentation for both compiler + human
- methods with intetnionally underdetermined specifications
What is abstraction
- omitting / hiding low-level details with a simpler , higher-level idea
ex.
1. Modularity
- dividing system into components / modules that can be independently designed, implemented and tested
- Encapsulation
- module is responsible for its own internal behaviour + not affected by bugs from other parts of system - Separation of Concerns
- making a feature a responsibile for only one module instead of having multiple modules share the same feature
classify operations
creators:
- create new objects from “nothing”
- takes any object as a parameter but it cannot be the same type as the object being created (can smts be null)
- ex. constructors
producers:
- creates new objects from an object of the same type
- can take multiple objects of diff types but the product has to be the same type as the object being produced
mutators:
- change objects (needs the object being mutated as a parameter (can take other parametes as well) but returns void)
observers:
- takes a parameter (at least one) and returns an object of a diff type
Designing abstract data types
- few simple operations (each with a well-defined purpose)
- set of operations should be adequate for what clients want to do
- representation independent
(use of ADT does not depend on the collection of fields used to support its operations) - preserve invariants (characterist of program / object that is always true)
- invariant is true in initial state of object and is kept true despite changes
