Core Concepts

Bhavit Chhatralia
Mind Map by Bhavit Chhatralia, updated more than 1 year ago
Bhavit Chhatralia
Created by Bhavit Chhatralia over 6 years ago
43
0

Description

Mind Map on Core Concepts, created by Bhavit Chhatralia on 22/05/2014.

Resource summary

Core Concepts
1 Code Styles
1.1 General Principles
1.1.1 Document any deviations
1.1.2 Adhere Principle of Least Astonishment
1.1.3 adhere to the style of the original
1.2 Least astonishment
1.2.1 Simplicity
1.2.1.1 Build simple classes and simple methods.
1.2.2 Clarity
1.2.2.1 Ensure each class, interface, method, variable, and object has a clear purpose.
1.2.3 Completeness
1.2.3.1 Provide the minimum functionality that any reasonable user would expect to find and use. Create complete documentation
1.2.4 Consistency
1.2.4.1 Similar entities look,behave the same; dissimilar entities look,behave differently. Create and apply standards
1.2.5 Robustness
1.2.5.1 Provide predictable documented behavior in response to errors and exceptions. Do not hide errors and do not force clients to detect errors.
1.3 Formatting Conventions
1.3.1 Indent nested code
1.3.1.1 Specify the amount of space and use of tabs
1.3.2 Break up long lines
1.3.2.1 Split long expressions
1.3.3 Include white space not just between lines
1.4 Naming conventions
1.4.1 Use meaningful names (Including constants instead of literals)
1.4.2 Question excessively long names
1.4.3 Join the vowel generation (don't shorten by taking vowels out)
1.4.4 Use familiar names (for the target domain)
1.4.5 Do not use names that differ only in case
1.4.6 Capitalize only the first letter in acronyms
1.4.7 package Names
1.4.7.1 Use the reversed, lowercase form of your organization's Internet domain name as the root qualifier for your package names
1.4.7.2 Use the same name for a new version of a package, but only if that new version is still binary compatible with the previous version, otherwise, use a new name
1.4.7.3 Use a single, lowercase word as the root name of each package
1.4.8 method Names
1.4.8.1 Use lowercase for the first word and capitalize only the first letter of each subsequent word that appears in a method name
1.4.8.2 Use verbs when naming methods
1.4.8.3 Follow the JavaBeans™ conventions for naming property accessor methods
1.4.9 type Names
1.4.9.1 Same name for a new version of a package, but only if that new version is still binary compatible with the previous version, otherwise, use a new name
1.4.9.2 Use nouns when naming classes
1.4.9.3 Use nouns or adjectives when naming interfaces
1.4.9.4 Pluralize the names of classes that group related attributes, static services, or constants
1.4.10 field Names
1.4.10.1 Use uppercase letters for each word and separate each pair of words with an underscore when naming constants
1.4.10.2 When a constructor or "set" method assigns a parameter to afield, give that parameter the same name as the field
1.4.11 variable Names
1.4.11.1 Use nouns to name variables
1.4.11.2 Pluralize the names of collection references
1.4.11.3 Use lowercase for the first word and capitalize only the first letter of each word in variable name
1.4.11.4 Establish and use a set of standard names for trivial "throwaway" variables
1.5 Other conventions
1.5.1 Documentation conventions
1.5.2 Programming conventions Do not repeat statements or expressions, replace with methods
1.5.3 Packaging conventions
2 Basic Tools
2.1 Integrated Development Environment
2.1.1 System that combines an editor with language specific support tools, including a debugger
2.1.2 Standard basic features are:
2.1.2.1 Debugger
2.1.2.2 Code Completion
2.1.2.3 Automatic Indentation
2.1.2.4 Syntax highlighting
2.1.2.5 Complication error highlighting
2.1.2.6 Automate common tasks
2.1.3 The master should always work:
2.1.3.1 Updates to working copies
2.1.3.2 Changes quickly updated to repository
2.1.3.3 Commit triggers build and test
2.1.3.4 System largely automated
2.1.3.5 Build results often promiently communicated to developers
2.2 Revision Control
2.2.1 Manga sharing of code between team etc.
2.2.2 Integration in IDE allows to see changes made even in the editor
2.2.3 Going back and forth between revisions
2.3 Build systems
2.3.1 Generally powerful scripting environments, that do other stuff to.
2.3.2 Automate various tasks related to building software
2.3.3 "Target"s allow a user to specify what needs to be done
2.3.4 Standard systems:
2.3.4.1 Ant - java
2.3.4.2 Maven - java project management
2.3.4.3 Make - For C/C++ (unix)
2.4 Static analyzers
2.4.1 Compilers are designed to translate software into executable code
2.4.2 Most languages don't enforce conventions neither do compilers.
2.4.3 Conventions can promote correctness
2.4.4 Complex analysis can find bugs in "valid" code
2.4.5 May score code on "correctness" dimensions
2.4.6 Can check for certain broken patterns
2.5 Code Formatters
2.5.1 Code readability helps understanding,correctness, maintenance
2.5.2 Formatters automatically format code
2.5.3 Help with conformance to code style + consistency
2.6 Refactoring
2.6.1 When code changes, the design may change along
2.6.2 Changing the organisation of code or design of the system is called refactoring
2.6.3 Refactoring involves aspects such as:
2.6.3.1 Renaming "things"
2.6.3.2 Reordering parameters
2.6.3.3 Introducing Classes or interfaces
2.6.3.4 Moving Methods
2.7 Debugging
2.7.1 Step over - go to next line
2.7.2 Step into - go into the function on this line
2.7.3 Step out - go to calling function
2.7.4 Breakpoint - stop execution here, on exception or value change
2.7.5 Watch - Expressions you want evaluated
2.7.6 Local variables - visible in program + value
3 Collections
3.1 What is a collection
3.1.1 Object that groups together various objects
3.1.2 used to hold similar data items - cards, msg in chatbox
3.1.3 Arrays are a sort of collections
3.2 What is Java Collections Framework
3.2.1 group of interfaces and classes for dealing with differing types of collections
3.2.1.1 Interfaces – abstract data types
3.2.1.2 Implementations – ready made classes
3.2.1.3 Methods – static methods that work on collections
3.2.2 encourages code reuse
3.2.3 facilitates interoperability
3.2.4 abstracts complex data structures between easy to understand (common) interfaces
3.3 Arrays
3.3.1 Size is fixed when the array is constructed
3.3.2 You must be able to predict array size
3.3.3 Items have a fixed index position
3.4 ArrayListS
3.4.1 Stores stuff in an array (and moves it to a new array if capacity is insufficient)
3.4.2 Maintains entry order
3.4.3 Changing a location is cheap [ O(1) ]
3.4.4 Finding an item is expensive [ O(n) ]
3.4.5 Getting an item at a specified random location is cheap [ O(1) ]
3.4.6 Adding stuff at the end is cheap (in most cases, except when copying is needed) [ O(1) ]
3.4.7 Putting things in the middle or removing things from the middle is expensive [ O(n) ]
3.5 HashMap (hashing)
3.5.1 Stores key -> value pairs
3.5.2 Key is hashed
3.5.3 Hash is used as index into an array, where the value is stored (often in a linked list)
3.5.4 Finding elements is cheap [ O(1) ]
3.5.5 Removing of elements is cheap [ O(1) ]
3.5.6 Memory need is bigger
3.5.7 Hash key calculation can be expensive
3.5.8 Collection does not maintain order
3.5.9 No random access
3.5.10 Iterating a bit more expensive than arraylists
3.5.11 HashSet
3.5.11.1 same as HashMap only value is stored in key as well
3.5.11.2 enforces uniqueness
3.6 TreeMap/Set
3.6.1 Stores in a tree
3.6.2 Maintains items in key order
3.6.3 Adding, removing and finding items has moderate complexity [ O(log n) ]
3.6.4 Reasonable memory usage
3.6.5 No random indexed access
3.6.6 Iterating a bit more expensive than arraylists
3.7 Linked List
3.7.1 Every element has a link to the next + or prev ele
3.7.2 Adding an element is cheap [ O(1) ]
3.7.3 Finding an element is expensive [ O(n) ] needs to look from beginning (on average 1/2 n steps)
3.7.4 Removing an element anywhere is cheap [ O(2) ]
3.7.5 Maintains entry order
3.7.6 LinkedHashMap/Set
3.7.6.1 Combine hashmap/set with linked lists
3.7.6.2 maintain entry order of adding items to from list
3.7.6.3 Computational properties of HashMaps
3.8 Deque - Double ended queue
3.8.1 New in jdk 1.6 / Java 6
3.8.2 Like array list, but instead of a window starting at index 0 of the array, maintains a sliding window over the array.
3.8.3 Cheap adding/removing entries at beginning of list
3.8.4 A little more expensive because of the index
3.8.5 In general a very efficient data type
4 Object Orientation
4.1 References and pointers
4.1.1 pointer is a data type that contains the address of some data in memory
4.1.2 To use the pointed to values, the language must provide indirection operators
4.1.3 A pointer must point to a valid location. Either allocated (new) or pre-existing
4.1.4 A reference is a language feature that makes abstracts pointer indirection and hides the pointer
4.1.5 In Java all Objects are used through references. Pointers are not available
4.2 What is OO?
4.2.1 A programming paradigm (approach to...)
4.2.2 combination of a number of programming concepts into 1
4.2.3 solution particularly well suited to certain problems
4.2.4 Not a silver bullet / panacea
4.2.5 What makes up OO?
4.2.5.1 Data structure
4.2.5.1.1 Create a new kind of "data" that is built out of constituent components
4.2.5.1.2 Members can be contained, or be references to structures
4.2.5.1.3 Membership can logically be
4.2.5.1.3.1 Containment - indistinguishable part, same lifetime
4.2.5.1.3.2 Ownership - the outer object is responsible for the lifetime of the object, and handling access to it
4.2.5.1.3.3 Reference - the outer object keeps a link to the object but has no responsibility in its lifetime
4.2.5.2 Modularisation
4.2.5.3 Code visibility
4.2.5.4 Code reuse
4.2.5.5 Abstraction (Abstract datatypes)
4.3 What is a Struct
4.3.1 Defines a "sequential" layout of values
4.3.2 Allows treating as parts
4.3.3 Element name is offset into memory
4.3.4 Data / machine oriented
4.3.5 Members are contained in the "in-memory" layout of the type
4.3.6 Containment implies ownership
4.3.7 By default members are public
4.3.8 Structs vs Classes
4.3.8.1 Java Objects are always used by reference (no containment).
4.3.8.2 Use of other objects can have the intent of reference, ownership or containment
4.4 Modularisation
4.4.1 Modularisation is breaking up code into parts
4.4.2 Plain use of methods/functions is not modularisation
4.4.3 module should have some sort of coherency
4.4.4 Makes it easier to find and edit parts of the system.
4.5 Code Reuse
4.5.1 Good prog reuses code
4.5.2 less code = less complex
4.5.3 reuse = code faster
4.5.4 reuse = effort into better code
4.5.5 reuse = changes in 1 place
4.5.6 Ways
4.5.6.1 Inheritance - allows a class to use the implementation in it's ancestor.
4.5.6.2 Generics, allow limited variation on type constraints only (mainly help correctness)
4.5.6.3 Temp, allow variations preventing copy,paste
4.5.6.4 ctrl c,v,+ edit = same (bad)
4.5.6.5 Function implementing an algorithm (Collections.sort)
4.6 Abstract Data Types
4.6.1 Abstract - "theoretical rather than physical or concrete"
4.6.2 in prog - the what from the how
4.6.3 Comp Science concept
4.6.4 Specifying a data (and its corresponding functions) type purely by its external properties
4.6.5 Allows to reason about something that holds (is true) for all possible implementations
4.6.6 Use in implementation ensures implementation independence
4.6.7 Uses
4.6.7.1 If your algorithm works on an ADT it works on all types implementing it (code reuse)
4.6.7.2 Allows for multiple implementations with different strengths (change has local impact on code)
4.6.7.3 Allow context-dependent use of specific implementation (don't return an empty ArrayList, but Collections.emptyList)
4.6.7.4 Separate function from implementation
4.7 Interface
4.7.1 Users should always read documentation for the "hidden" contract
4.7.2 Only specifies an abstract data type
4.7.3 Specifies a particular contract that classes can implement, and users can expect.
4.7.4 Non-visible parts should be documented
4.7.5 Parts of the contract are not visible in code
4.8 Inheritance
4.8.1 Java = public relationship
4.8.2 class = interface
4.8.3 In memory, an instance is like a structure where the first member is a contained, anonymous version of the parent
4.8.4 Private members allow hiding implementation from children.
4.8.5 Protected allows access by children, but not by users.
4.8.6 Final protects agains inheritance. Final classes can't be inherited. Final members can't be overridden
4.9 Abstract classes (and methods)
4.9.1 Fully abstract class is an interface (e.g. C++ has no interface concept)
4.9.2 Some implementations are provided either for convenience, or to enforce behaviour.
4.9.3 Abstract methods provide a contract, but no implementation
4.9.4 Abstract classes miss implementation for some methods, and are thus designed for extension
4.10 Polymorphism
4.10.1 Technique to run different code based on type of an object at run time
4.10.2 Each object maintains a reference to it's actual type (set at creation time).
4.10.3 When calling a method, instead of going to the address of that method, look the method address up in the class (in C++ vtable).
4.10.4 Different classes can point to different implementations for the same method name
4.10.5 Depends on exact method signature match.
4.10.6 Depends on exact method signature match.
4.10.7 @Override annotation conveys intention to compiler that verifies the intention
Show full summary Hide full summary

Similar

Society And Culture
Sophia Ergos
Mathematics Overview
PatrickNoonan
Ratios Quiz
rory.examtime
STEM AND LEAF DIAGRAMS
Elliot O'Leary
Study Tips to Improve your Learning
miminoma
mi mapa conceptual
Alondra Montes Vera
SISTEMAS NERVIOSO Y REPRODUCTIVO El sistema nervioso se relaciona con el sistema reproductivo, ya que se recibe la estimulación externa e interna y envía información para preparar al organismo para la reproducción, así las hormonas y los neurotransmisores
Diana Gonzales
REQUISITOS GENERALES CERTIFICACIONES A, AA Y AAA
Brenda Ruiz
1. DEFINICIÓN DEL QUIEBRE 2. ESCUCHA E INDAGACIÓN
Stefany De la cruz
resumen de los encuentros
milton gueledel
SISTEMA DIGESTIVO
lara sousa