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>
