It's a design pattern that reduces the memory footprint by sharing part of the data that one type of object instantiates. It also improves performances and it's recommended when a large number of objects need to be created.
Here's an example, where a high number of pen objects need to be created. Each pen contains a color object and in order to save space the color objects are shared between pens.
/** * This is a color and I don't want to instantiate * it every time I create a pen. */ public final class Color { private final String color;
The composite design pattern represents objects in tree structures, but treats leaves and branches with the same interface. This allows us to deal with hierarchical data structures in a less error-prone way, for example for the purpose of classification.
Here's an example to deal with songs, classified by genre:
/** * Allow to sing a song */ public interface Singable { void sing(); } import java.util.ArrayList; import java.util.List; /** * Represents a collection of songs or sub-genres, * using composite design pattern */
In a multithreading environment you have two solutions to deal with non-thread safe variables:
ThreadLocal creates a local copy of the variable in each thread. ThreadLocal variables are usually private static fields.
Here's an example:
public class CalendarFactory { private static CalendarFactory instance = new CalendarFactory(); private CalendarFactory() {} private ThreadLocalcalendar = new ThreadLocal () { @Override protected Calendar initialValue() {
When data can be represented in multiple forms, a canonical form is the standard representation that makes comparison possible.
In computer science, normalized form has the same meaning and normalization is the process of generating a canonical form. However, in other fields only a canonical form has the requirement of uniqueness, whereas a normalized form not.
Normalization applies to Unicode strings, paths, URLs etc.
For example, a relative path can be normalized to the absolute path, so that it can be compared without any mistakes.
Both are dummy components used for testing. The difference is that a stub is called by a non-dummy code, whereas a driver calls a non-dummy code.
In other words, a stub is a dummy dependency, whereas a driver is a dummy caller.
Suppose to have a Car class that depends on an Engine class to work.
You implemented the Car but not the Engine yet, so you test the Car by creating a dummy Engine.
Otherwise, you implemented the Engine but not the Car, so you test the Engine by creating a dummy Car.
Scaffolding is the simulation of non-existing code, through the use of stubs and drivers.
Free software is free to use and distribute, but not always free of charge.
Freeware is free of charge, but copyrighted.
Shareware is commercial software, that can be trialware (limited in time) or demo (limited in functionality).
Open source is source open and free to use and distribute. The main difference with free software is that it might be copyrighted.
However, note that the term "open" and "free" don't exclude each other. So you can have licenses like GNU that are for free software that is also open source.
Here's a comparison:
MongoDB is a popular noSQL database.
It is particularly indicated for big data, because:
It is schemaless and it stores data in collections and documents.
A collection is an analogous of a table and contains multiple documents.
A document is a record stored as a Json key-value object.
Here's an example of document:
{ "_id" : ObjectId("551bc7e7c7e7bc4fc36b7c4a"), "FirstName" : "George", "LastName" : "Lucas" }
A session keeps information across multiple requests and relate them. It makes up for the fact HTTP is stateless.
There are two ways a session is maintained:
A session is created when you call request.getSession(), the current session is returned if it already exist.
Manage sessions as follows:
Session existing Session not existing usage
Documentation helps to think and design better solutions, makes implementations simpler and reduce bugs. It allows us to think wrong and change our tack, without actually writing any code.
It should start with at high level, going deeper to more details.
The documentation process varies, here's the course roughly followed by large projects:
According to the Law of Demeter objects should only know about objects that are closely related. In other words, they should only talk to immediate friends.
The idea is to avoid to call a method on an object returned from another method:
firstObject.doSomethingOnThe2ndObj().doSomethingOnThe3rdObj().doSomethingOnThe4thObj();
The solution is to delegate calls to returned object to the first object:
firstObject.doSomethingAndTakeCareOfEverything();
Copyright © 2013 Welcome to the website of Davis Fiore. All Rights Reserved.