/**
* Copyright (C) 2022 by Martin Robillard. See https://codesample.info/about.html
*/
package e2.chapter2;
import java.util.ArrayList;
import java.util.Collections;
import java.util.List;
/**
* Represents a deck of playing cards. In this version, the cards in the
* deck are stored in a list and the list of cards in the deck can
* be obtained by client code using an immutable wrapper object.
*/
public class {
private List<Card> aCards = new ArrayList<>();
/**
* Creates a new deck of 52 cards, shuffled.
*/
public Deck() {
shuffle();
}
/**
* Reinitializes the deck with all 52 cards, and shuffles them.
*/
public void shuffle() {
aCards.clear();
for( Suit suit : Suit.values() ) {
for( Rank rank : Rank.values() ) {
aCards.add( new Card( rank, suit ));
}
}
Collections.shuffle(aCards);
}
/**
* Places pCard on top of the deck.
* @param pCard The card to place on top
* of the deck.
* @pre pCard !=null
*/
public void push() {
assert pCard != null;
aCards.add(pCard);
}
/**
* Draws a card from the deck: removes the card from the top
* of the deck and returns it.
* @return The card drawn.
* @pre !isEmpty()
*/
public Card draw() {
assert !isEmpty();
return aCards.remove(aCards.size() - 1);
}
/**
* @return True if and only if there are no cards in the deck.
*/
public boolean isEmpty() {
return aCards.isEmpty();
}
/**
* @return An unmodifiable list of all the cards in the deck.
*/
public List<Card> getCards() {
return Collections.(aCards);
}
}
A first step to have good in your software is to decide on the abstractions of your problem domain that will be represented as (Java) types.
A deck of cards is one such concept. It maps to a clear element from the problem domain, that we will want to manipulate in our program.
A first step to have good in your software is to decide on the abstractions of your problem domain that will be represented as (Java) types.
A deck of cards is one such concept. It maps to a clear element from the problem domain, that we will want to manipulate in our program.
The idea of encapsulation in software design is to enclose the implementation of concepts (e.g., the workings of a playing card) inside a "capsule", or boundary (or interface), with only a minimal amount of contact points. Good encapsulation has many benefits, such as:
The idea of encapsulation in software design is to enclose the implementation of concepts (e.g., the workings of a playing card) inside a "capsule", or boundary (or interface), with only a minimal amount of contact points. Good encapsulation has many benefits, such as:
One can think about the encapsulation concept, with its explicit behaviors (methods), in isolation.
One can think about the encapsulation concept, with its explicit behaviors (methods), in isolation.
If all public methods of a class never leave an object in a corrupted state, then you have a stronger guarantee that the object won't be misused.
Similarly, complex interactions with specific constraints can be encoded in simple methods, so that client code doesn't risk missing some of these constraints.
If all public methods of a class never leave an object in a corrupted state, then you have a stronger guarantee that the object won't be misused.
Similarly, complex interactions with specific constraints can be encoded in simple methods, so that client code doesn't risk missing some of these constraints.
As long as the public members of a class stay the same, their implementation can change, for example to optimize the memory footprint of an algorithm, without affecting the rest of the code.
As long as the public members of a class stay the same, their implementation can change, for example to optimize the memory footprint of an algorithm, without affecting the rest of the code.
See the Card.java
example for an explanation of Javadoc's @pre
tags, which are related to Design by Contract and help avoid
defensive programming.
See the Card.java
example for an explanation of Javadoc's @pre
tags, which are related to Design by Contract and help avoid
defensive programming.
Good encapsulation generally requires to allow clients to modify mutable fields only through methods of the class.
In this case, it shouldn't be possible to change the content of aCards
other than by using one of Deck
's methods. Otherwise, clients may do
any sorts of modifications, including some that would generate
decks.
The first step towards encapsulation is to make the field private
, so that it's
only visible from inside the class (i.e., not visible by client code).
However, this is not enough! References to privates fields can
leak in .
Good encapsulation generally requires to allow clients to modify mutable fields only through methods of the class.
In this case, it shouldn't be possible to change the content of aCards
other than by using one of Deck
's methods. Otherwise, clients may do
any sorts of modifications, including some that would generate
decks.
The first step towards encapsulation is to make the field private
, so that it's
only visible from inside the class (i.e., not visible by client code).
However, this is not enough! References to privates fields can
leak in .
For example, decks with null
cards.
For example, decks with null
cards.
Search for "leaking reference" on this document to see some ways.
Search for "leaking reference" on this document to see some ways.
Storing a reference to an argument to a method creates a leaking reference. Client code can still have access to the object they passed, and eventually (thus changing the internal state without using public methods).
Note that this is fine here, because Card
objects are immutable, so
even if client code has access to a reference of an internal object, it
can't modify it.
Storing a reference to an argument to a method creates a leaking reference. Client code can still have access to the object they passed, and eventually (thus changing the internal state without using public methods).
Note that this is fine here, because Card
objects are immutable, so
even if client code has access to a reference of an internal object, it
can't modify it.
Unless the object is immutable!
Unless the object is immutable!
See the Card.java
example for an explanation of Java's assert
statements, which are related to Design by Contract and help avoid
defensive programming.
See the Card.java
example for an explanation of Java's assert
statements, which are related to Design by Contract and help avoid
defensive programming.
List
interface. Implements all optional list operations, and permits all elements, including null
. In addition to implementing the List
interface, this class provides methods to manipulate the size of the array that is used internally to store the list. (This class is roughly equivalent to Vector
, except that it is unsynchronized.)
List
interface. Implements all optional list operations, and permits all elements, including null
. In addition to implementing the List
interface, this class provides methods to manipulate the size of the array that is used internally to store the list. (This class is roughly equivalent to Vector
, except that it is unsynchronized.)
The size
, isEmpty
, get
, set
, iterator
, and listIterator
operations run in constant time. The add
operation runs in amortized constant time, that is, adding n elements requires O(n) time. All of the other operations run in linear time (roughly speaking). The constant factor is low compared to that for the LinkedList
implementation.
Each ArrayList
instance has a capacity. The capacity is the size of the array used to store the elements in the list. It is always at least as large as the list size. As elements are added to an ArrayList, its capacity grows automatically. The details of the growth policy are not specified beyond the fact that adding an element has constant amortized time cost.
An application can increase the capacity of an ArrayList
instance before adding a large number of elements using the ensureCapacity
operation. This may reduce the amount of incremental reallocation.
Note that this implementation is not synchronized. If multiple threads access an ArrayList
instance concurrently, and at least one of the threads modifies the list structurally, it must be synchronized externally. (A structural modification is any operation that adds or deletes one or more elements, or explicitly resizes the backing array; merely setting the value of an element is not a structural modification.) This is typically accomplished by synchronizing on some object that naturally encapsulates the list. If no such object exists, the list should be "wrapped" using the Collections.synchronizedList
method. This is best done at creation time, to prevent accidental unsynchronized access to the list:
List list = Collections.synchronizedList(new ArrayList(...));
The iterators returned by this class's iterator
and listIterator
methods are fail-fast: if the list is structurally modified at any time after the iterator is created, in any way except through the iterator's own remove
or add
methods, the iterator will throw a ConcurrentModificationException
. Thus, in the face of concurrent modification, the iterator fails quickly and cleanly, rather than risking arbitrary, non-deterministic behavior at an undetermined time in the future.
Note that the fail-fast behavior of an iterator cannot be guaranteed as it is, generally speaking, impossible to make any hard guarantees in the presence of unsynchronized concurrent modification. Fail-fast iterators throw ConcurrentModificationException
on a best-effort basis. Therefore, it would be wrong to write a program that depended on this exception for its correctness: the fail-fast behavior of iterators should be used only to detect bugs.
This class is a member of the Java Collections Framework.
Returning a reference to a private field in a public method creates a leaking reference. Even if client code needs to use a public method to get the reference, it can then do any sort of modification to the field without additional calls to public methods.
To avoid leaking a reference, the method
Collections.unmodifiableList(List)
wraps the argument (in this
case, the private field) in another object (the wrapper) that
doesn't allow any modifications.
This doesn't create a new copy, or make the initial field immutable, it only ensures that code that only has access to the wrapper can't modify the original list.
Note, however, that even though the reference to aCards
isn't
leaked by this method, references to the Card
objects stored
inside the list are leaked. For example, client code could get
the first Card
from this list, and modify it directly. This isn't
a problem here, because Card
is immutable.
This is the most challenging example of a leaking reference, when it involves objects within shared data structured.
Chapter 2, insight #5
To provide information about the internal data in an object without violating encapsulation, strategies include extending the interface of the class, returning copies of internal objects, or using unmodifiable views
UnsupportedOperationException
.Returning a reference to a private field in a public method creates a leaking reference. Even if client code needs to use a public method to get the reference, it can then do any sort of modification to the field without additional calls to public methods.
To avoid leaking a reference, the method
Collections.unmodifiableList(List)
wraps the argument (in this
case, the private field) in another object (the wrapper) that
doesn't allow any modifications.
This doesn't create a new copy, or make the initial field immutable, it only ensures that code that only has access to the wrapper can't modify the original list.
Note, however, that even though the reference to aCards
isn't
leaked by this method, references to the Card
objects stored
inside the list are leaked. For example, client code could get
the first Card
from this list, and modify it directly. This isn't
a problem here, because Card
is immutable.
This is the most challenging example of a leaking reference, when it involves objects within shared data structured.
Chapter 2, insight #5
To provide information about the internal data in an object without violating encapsulation, strategies include extending the interface of the class, returning copies of internal objects, or using unmodifiable views
UnsupportedOperationException
.
The returned list will be serializable if the specified list
is serializable. Similarly, the returned list will implement
RandomAccess
if the specified list does.
T
- the class of the objects in the listlist
- the list for which an unmodifiable view is to be returned.Chapter 2, insight #3
Hide the internal implementation of an abstraction behind an interface that tightly controls how an abstraction can be used. Declare fields of a class private, unless you have a strong reason not to. Similarly, declare any method private if it should not be explicitly part of the type's interface
Chapter 2, insight #3
Hide the internal implementation of an abstraction behind an interface that tightly controls how an abstraction can be used. Declare fields of a class private, unless you have a strong reason not to. Similarly, declare any method private if it should not be explicitly part of the type's interface
Chapter 2, insight #4
Ensure that the design of your classes prevents any code from modifying the data stored in an object of the class without using a method of the class. In particular, be careful to avoid leaking references to private fields of the class that refer to mutable objects
Chapter 2, insight #4
Ensure that the design of your classes prevents any code from modifying the data stored in an object of the class without using a method of the class. In particular, be careful to avoid leaking references to private fields of the class that refer to mutable objects
Unlike sets, lists typically allow duplicate elements. More formally, lists typically allow pairs of elements e1
and e2
such that e1.equals(e2)
, and they typically allow multiple null elements if they allow null elements at all. It is not inconceivable that someone might wish to implement a list that prohibits duplicates, by throwing runtime exceptions when the user attempts to insert them, but we expect this usage to be rare.
The List
interface places additional stipulations, beyond those specified in the Collection
interface, on the contracts of the iterator
, add
, remove
, equals
, and hashCode
methods. Declarations for other inherited methods are also included here for convenience.
The List
interface provides four methods for positional (indexed) access to list elements. Lists (like Java arrays) are zero based. Note that these operations may execute in time proportional to the index value for some implementations (the LinkedList
class, for example). Thus, iterating over the elements in a list is typically preferable to indexing through it if the caller does not know the implementation.
The List
interface provides a special iterator, called a ListIterator
, that allows element insertion and replacement, and bidirectional access in addition to the normal operations that the Iterator
interface provides. A method is provided to obtain a list iterator that starts at a specified position in the list.
The List
interface provides two methods to search for a specified object. From a performance standpoint, these methods should be used with caution. In many implementations they will perform costly linear searches.
The List
interface provides two methods to efficiently insert and remove multiple elements at an arbitrary point in the list.
Note: While it is permissible for lists to contain themselves as elements, extreme caution is advised: the equals
and hashCode
methods are no longer well defined on such a list.
Some list implementations have restrictions on the elements that they may contain. For example, some implementations prohibit null elements, and some have restrictions on the types of their elements. Attempting to add an ineligible element throws an unchecked exception, typically NullPointerException
or ClassCastException
. Attempting to query the presence of an ineligible element may throw an exception, or it may simply return false; some implementations will exhibit the former behavior and some will exhibit the latter. More generally, attempting an operation on an ineligible element whose completion would not result in the insertion of an ineligible element into the list may throw an exception or it may succeed, at the option of the implementation. Such exceptions are marked as "optional" in the specification for this interface.
The List.of
and List.copyOf
static factory methods provide a convenient way to create unmodifiable lists. The List
instances created by these methods have the following characteristics:
UnsupportedOperationException
to be thrown. However, if the contained elements are themselves mutable, this may cause the List's contents to appear to change. null
elements. Attempts to create them with null
elements result in NullPointerException
. subList
views implement the RandomAccess
interface. This interface is a member of the Java Collections Framework.
clear
in interface Collection<E>
UnsupportedOperationException
- if the clear
operation is not supported by this list
Lists that support this operation may place limitations on what elements may be added to this list. In particular, some lists will refuse to add null elements, and others will impose restrictions on the type of elements that may be added. List classes should clearly specify in their documentation any restrictions on what elements may be added.
add
in interface Collection<E>
e
- element to be appended to this list
true
(as specified by Collection.add(E)
)
UnsupportedOperationException
- if the add
operation is not supported by this list
ClassCastException
- if the class of the specified element prevents it from being added to this list
NullPointerException
- if the specified element is null and this list does not permit null elements
IllegalArgumentException
- if some property of this element prevents it from being added to this list
The methods of this class all throw a NullPointerException
if the collections or class objects provided to them are null.
The documentation for the polymorphic algorithms contained in this class generally includes a brief description of the implementation. Such descriptions should be regarded as implementation notes, rather than parts of the specification. Implementors should feel free to substitute other algorithms, so long as the specification itself is adhered to. (For example, the algorithm used by sort
does not have to be a mergesort, but it does have to be stable.)
The "destructive" algorithms contained in this class, that is, the algorithms that modify the collection on which they operate, are specified to throw UnsupportedOperationException
if the collection does not support the appropriate mutation primitive(s), such as the set
method. These algorithms may, but are not required to, throw this exception if an invocation would have no effect on the collection. For example, invoking the sort
method on an unmodifiable list that is already sorted may or may not throw UnsupportedOperationException
.
This class is a member of the Java Collections Framework.
The hedge "approximately" is used in the foregoing description because default source of randomness is only approximately an unbiased source of independently chosen bits. If it were a perfect source of randomly chosen bits, then the algorithm would choose permutations with perfect uniformity.
This implementation traverses the list backwards, from the last element up to the second, repeatedly swapping a randomly selected element into the "current position". Elements are randomly selected from the portion of the list that runs from the first element to the current position, inclusive.
RandomAccess
interface and is large, this implementation dumps the specified list into an array before shuffling it, and dumps the shuffled array back into the list. This avoids the quadratic behavior that would result from shuffling a "sequential access" list in place.
list
- the list to be shuffled.
UnsupportedOperationException
- if the specified list or its list-iterator does not support the set
operation.
Integer.MAX_VALUE
elements, returns Integer.MAX_VALUE
.
Integer.MAX_VALUE
elements, returns Integer.MAX_VALUE
.
size
in interface Collection<E>
index
- the index of the element to be removed
UnsupportedOperationException
- if the remove
operation is not supported by this list
IndexOutOfBoundsException
- if the index is out of range (index < 0 || index >= size()
)
true
if this list contains no elements.
true
if this list contains no elements.
isEmpty
in interface Collection<E>
true
if this list contains no elements