TOPICS:  Principles

1. Principles regarding how to write code - o DRY = Don't Repeat Yourself

Clean Code  - applicable whenever we
2. Design Patterns Copy/paste a piece of code
3. Source code versioning - Git, SVN  Just use a method or a class
4. Unit Testing - Junit o KISS = Keep It Simple and Stupid
5. Software quality concepts  Whenever we want to
implement a method to do all
Software Quality means: things
 Defining product quality o YAGNI =You Ain't Gonna Need It
 Improving development process  Don't write methods which
 Preventing errors and bugs are not yet necessary (maybe
you will never need them)
Software Testing means:  Somehow related with KISS
 Identifying errors and bugs before the o SOLID
users will see them  Single responsibility (SRP)
 A class must always
Software development is a cycle of: have one and only one
 Maintenance responsibility
 Requirements  Otherwise any change
 Design of its specifications will
 Construction lead to its uselessness
 Testing and rewriting the entire
 Debugging code
 Deployment  Open-closed (OCP)
 Classes must be open
CLEAN CODE for extensions
 But closed for changes
 Why clean code?  Liskov substitution (LSP)
o There is no time to be lazy  Objects can be replaced
o Things programmers do at work: whenever by instances
 Read code 90% of their derived classes
 Write code 10% without this affecting
o Rubber Duck Programming functionality
 Take care of if(vb1=0), it is  It is also known as
not only changing the vb1 "Design by Contract"
value, but also set the  Interface segregation (ISP)
condition to false.  More specialized
 Pay attention to the code ( interfaces are always
e.g.: modify it in if(vb1==0) ). preferable to a single
o What is clean code? general interface
 Code must be easily readable  By changing the
 Code must be easily "contract" you don't
understandable risk to change other
 The code should be easily to clients contracts
be modified  Objects must not be
o CLEAN CODE = GOOD CODE forced to implement
 methods that are not
useful/needed

 Boolean variables must sound

 Dependency inversion like a question that can be
 Depend on answered with true/false
abstractions. (e.g.: isTerminated Boolean =
 Do not depend on false;)
concrete classes.  Clean code in practice
 Naming conventions o Define each variable on a single line
o Types: o Code block start with { and ends
 UpperCamelCase with } even if we have a single
 lowerCamelCase instruction.
 System Hungarian Notation o Between function header and the
 Apps Hungarian Notation its body starting bracket use a
o Classes: single space
 Choose the name based on o Write the block closing bracket on a
the Single Responsibility single line, EXCEPT FOR if-else or
Principle try-catch
 Composed of a specific noun o Methods are separated by a single
o Methods: empty line
 It must clearly describes what o Function arguments are separated
the method does by a , (comma) and a space
 If the name contains a o Use a space between operators and
conjunction ("and" / "or" ) it operands: return name + " " age;
means that you need two o Avoid comparisons with true and
methods. false
 Do not use abbreviations o Constant values should be named
o Variables: and defined (usually at the
 It is not recommended to use beginning of the class)
in variable names code strings o When conditions become too large,
form other languages (SQL, use intermediary variables
CSS)
 o It is better to exit the function as teams/pairs to implement complex
soon as possible by return or tasks; this approach promotes
throwing an exception learning and avoid code review.
o Variables should be declared as  Instruments
closer as possible to the code block  Bonus
that uses them
o Use as much as possible "this" and
implement a naming convention for UNIT TESTING WITH JUnit
constructor arguments
o Avoid methods with more than 2 Writing code means also writing the
input arguments corresponding unit tests in the same time
o Avoid long methods with more than
30 lines of code Testing Source Code A:
o Conditional structures like if and 1. Unit Testing
switch increase complexity a. Testing the smallest units of the
o Simple methods have a complexity source code (classes or methods)
=1 2. Integration Testing
o Delegate by references a. Testing more combined and
o Use interfaces integrated components
o Classes that cooperate will be 3. System testing
places in the same module/package a. Testing the entire system (all
o Good code is self-descriptive, use components). It is testing is the
less comments system works accordingly with the
o Do not comment the unused code design and specifications
o All the needed details can be put in 4. Acceptance testing
the commit notes (managed by the a. Test done by the client. Testing if
versioning system) the design is accordingly with
 Short dictionary client's needs.
o Test Driven Development (TDD) -
code development based on the
use cases/test cases Testing Source Code B:
o Refactoring - rewriting the code to 1. Regression Testing = testing the
adapt it to new specifications or to application (usually in an automate
correct it manner) after implementing changes to
o Automatic Testing (Unit Testing) - the existing code in order to avoid getting
Code automatic testing based on old bugs - checking if the changes are
use cases. Useful for refactoring affecting the application in a wrong way
phases because it helps you check if 2. Black-box testing = testing the public
all the functionalities have been interface of components without any info
preserved. (regression testing) regarding their implementation, internal
o Code review - procedure used in structure etc.
AGILE (SCRUM) that requires that 3. White-box testing (glass-box testing) =
any source code should be checked Testing components for which the
(reviewed) by a different implementation is known and accessible.
programmer
o Pair programmer - programming
technique specific to AGILE based
on which programmers work in
WHAT IS UNIT Testing? 6. Run the tests
 A simple and rapid method to test source 7. If they fail go back to step 1
code for the programmers
 Used in the development phase
 An instrument for the programmers The Right-BICEP
 A unit test is a code sequence written by  Right . Are the results right for the right
the programmer to evaluate a reduced input? •
size, clear defined code sequence from its  B . Are all the boundary conditions
tested source code -a class or a method CORRECT? •
 A unit test assesses how a method runs in  I . Can you check inverse relationships? •
a well defined context (It’s all about input  C . Can you cross-check results using
and results) other means? •
 A unit test is the basic block for  E . Can you force error conditions to
implementing TEST-DRIVEN happen? •
DEVELOPMENT (TDD)  P . Are performance characteristics within
o Test-driven development (TDD) - is bounds?
a software development process
that relies on the repetition of a
very short development cycle: first Error - conditions
the developer writes an (initially  Running out of memory •
failing) automated test case that  Running out of disk space •
defines a desired improvement or  Issues with wall-clock time •
new function, then produces the  Network availability and errors •
minimum amount of code to pass  System load •
that test, and finally refactors the  Limited color palette •
new code to acceptable standards.  Very high or very low video resolution

Steps for TDD: Branch Testing/ Condition Coverage –

1. Understand the code you need to implement enough tests to assure that every
implement (read specifications) branch alternative has been executed at least
2. Define the method signature/header once under some test; for every branch
3. Write a unit test for correct conditions alternative you provide values that generate
4. Implement the method – dummy body true and false results
5. Test the method – it will fail
6. Write the method DON'T TEST EXTERNAL FUNCTIONS
7. Test the method – should pass Use mocks or stub methods to replace them
8. Add more unit tests for extreme
conditions MOCKS:
 A unit test assesses a method execution
HOW to implement UNIT testing? but this requires
1. Read the specs for a method or a class objects/methods/conditions external to
2. Understand the problem the method •
3. Define conditions to evaluate (rewrite the  It’s a testing pattern •
specs)  It a simple replacer for the real
4. Write tests that will fail if the object/method •
method/class is not implemented  It has the same interface as the real
correctly method/object
5. Implement the code for the method/class
Simple rules for good methods: • The assert message is used to document
 Write unit tests while implementing the tests and is useful for debugging failed
method tests
 Single responsibility
 Keep It Simple & Stupid Junit Concepts:
 Delegate • Fixture – Set of objects used in the test
 Use interfaces • Test Case – A class that defines the
fixture set to run multiple tests
Each test should check one condition - one • Setup – A method / step of defining the
assert rule. set of objects used (fixture) before
testing.
when an assertion fails, it prints the file name, • Teardown – A method / stage of
line number, and a message that you can destroying the fixture after completion of
customize the tests
• Test Suite – Collection of test cases
Test properties: • Test Runner – tool for running tests
 Automatic - can be run automatically • (test suite) and to display results
 Repeatable - they can be exceuted many
times with the same results • If a test fails, the others are still executed
 Independent - independent of One test method can have several assertions
performance-specific conditions and
independent of other tests •
 Complete - tests everything that can Test Case Structure in JUnit3
generate errors at a time •  setUp()
 Real - they are just as important as the o • Defines and builds the resources
test code; Are all programs and must be (fixture) needed to run the tests •
treated as such (NOT coded sequences for o Call before each test method •
a specific moment and then discarded) o In the case of test kits, the method
may be a generic, one-time
• JUnit is a class framework that allows writing execution if defined within a
and executing tests for different methods / TestSetup
classes in the code  tearDown()
o Releases / destroys the resources
Junit Architecture: allocated to the test •
• TestRunner executes tests and reports o Call for each test method •
TestResults o In the case of test kits, the method
• Test are implemented in classes that may be a generic, one-time
extend abstract TestCase execution if defined within a
• To write tests you need to use Assert TestSetup
• Each assert method has next
arguments: message, expected-value, Use annotations to mark framework specific
actualvalue methods in Junit4
• For floating point values assert has a  @Test – marks a method as a unit test -
supplementary argument – delta (margin  @Before – marks the setUp method (the
error) method name must be setUp) -
• Each assert method has an equivalent  @After – marks the tearDown method -
version without the message – not  @BeforeClass – marks the
recommended to use setUpBeforeClass method -
  @AfterClass – marks the • Composite – gestionează o ierarhie de
tearDownAfterClass method obiecte
 @Ignore / @Ignore(“Is disabled") – • Decorator – atribuie la run-time
ignores the unit test • funcționalitate nouă unui obiect existent
 @Test (expected = Exception.class) – • Façade – simplifica execuția (apelarea)
assesses if the tested method is throwing unui scenariu complex
an exepction • • Flyweight – gestionează eficient mai
 @Test(timeout=100) – assesses if the unit multe instanțe (clone) ale unui set redus
test finishes before the timeout (used for de modele
Performance
tests) • Comportamentale:
• Strategy – schimba la run-time funcția
executată
• Observer – execută o acțiune când are
DESIGNED PATTERN loc un eveniment sau un observabil își
schimba starea
A pattern is a reusable solution for a standard • Chain of Responsibility – gestionează o
problem in a given context secvență de acțiuni ce pot procesa un
eveniment sau un obiect
• Command – gestionează realizarea
Components of a design pattern: întârziată a unei acțiuni
 Name • Memento – gestionează stările
o • It is part of the vocabulary of a anterioare ale unui obiect
programmer / designer / software • State – stabilește tipul acțiunii în funcție
architect • de starea obiectului
o Identifies the pattern uniquely • Template – gestionează un șablon fix de
 Problem acțiuni
o • Describes the intended purpose •
o Defines the context •
o Determines when the pattern is
applicable
 Solution
o UML diagram
 Consequences
o Results
o Advantages and disadvantages

• Creaționale:
• Factory – creează obiecte dintr-o familie
• Builder – creează obiecte setând
anumite atribute
• Singleton – creează o unică instanță
• Prototype – creeaza clone ale unui
obiect fara a se baza pe constructor
• Structurale:
• Adapter – adaptează un API (o interfață)
la altul
Seminary Notes:
The destination is generally in a subfolder of your folder
project

 We'll receive handouts. When we inherit abstract classes, we inherit everything,

 Most of the examples will follow UML diagrams. including abstract methods
 Some classes have italic font => they are abstract You have to either make the class abstract or to
class implement all abstract methods
 <<interface>> --> will only have abstract methods
and static variable The size of variables.
 Abstract classes will only have abstract methods The size of the pointer depends on the processor
and also attributes. architecture.
 Exceptions are a way to communicate with the
others So double balance will be 8 bytes for double + 4 bytes for
 Normal text => public classes the pointer because we are working on a 32 architecture.
 -you need to structure the project
 Named the package! 0 is not null in Java
 If we make the class final, other classes won't be All references get null and all numbers get 0.
able to inherit it
+ means public 1questions: do we really need values in the constructors?
-means private to the rest of the world or PROTECTED if it Don t leave possible actions
has to be inherited by other Security!

//SHADOWING in a constructor when you initialize the

 MVC -> Model View Controller (e.g. objects, variable with itself (e.g. id=id)
buttons are based on the view) Do not forget about "this"
The view for us is a console application, we'll always name This.id=0;
it view and this is where we are going to test our
application, this is where method "public static void main"
The empty rectangular is there for us in order to
Check "generate comments" implement something
If you fill the need to put a comment, it means the code is
not good enough. Delete and write again. Pay attention on methods name.

@deprecated is something that you put when you provide Compiler is watching your back!
a better version of the existing class.
When you mark a method with @Override, you ask the
@see you put the name of the class that is a better version compiler to check if the method you want to override
of the last class -> it will be used together with a link for exists already.
the source code to be updated.
When it is written with caps it means it is static
In order to be flexible, use double
Java is very restrictive when it comes to types of variables. It is not recommended to have a lot of static attributes. To
not abuse of static memory
To tell to the compiler you use a float
(float)10.0; If we put final to a method it means that it can t be
10.0f; override. No one after can change it
LIMIT OPTION FOR OTHERS and CONTROL HOW THE CODE
IS IMPLEMENTED.
/** + enter it will complete the comment section

@param is specific to methods

We can put descriptions

@return nothing

Javadoc Generation
You have to specify the path: C -> Program Files -> Java ->
jdk… -> bin -> javadoc.ese