Nella vita di oggi...

Strutture Dati - Tutto il Progetto

noreply@blogger.com (Unknown) — Tue, 28 Jun 2011 11:30:00 +0000

Quando ho iniziato a seguire il corso di Strutture Dati ho anche iniziato a postare periodicamente le soluzioni dei miei esercizi, e le implementazioni delle strutture dati studiate fino a quel momento. Purtroppo man mano che la mole di studio si appesantiva non sono più stato in grado di stare al passo col blog, infatti l'ultimo post risale alle code a priorità. Ho deciso quindi di postare direttamente tutto il progetto a fine corso in formato importabile direttamente in Eclipse. Quindi seguendo il link per il download alla fine di questo post potrete scaricare un progetto.zip comprendente tutte le Strutture Dati e le relative classi di Test che avevo già pubblicato in post precedenti più quelle studiate successivamente (Heap, BinarySearchTree, Graph, Map, Dictionary, Partition), più tutti gli esercizi, le 5 prove intercorso del 2011, e un Esame relativo al primo appello di Giugno.

Per chi non sapesse come importare il progetto in Eclipse, ecco la procedura:

Scarica il file zippato dal link alla fine di questo post.
Apri Eclipse
clicca su un progetto esistente (OPZIONALE: fai questo per non dover selezionare una root directory successivamente)
Dal Menu File in alto a sinistra seleziona la voce "Import"
Dalla finestra che si aprirà, scegli "Existing Project into Workspace"
Se non hai eseguito il punto 3, seleziona una root directory per il progetto
Seleziona il file zip nel campo Archive File, e clicca sul pulsante Finish

Scarica Il Progetto

Strutture Dati - Prova del 19 Aprile

noreply@blogger.com (Unknown) — Tue, 19 Apr 2011 21:21:00 +0000

Ecco le mie soluzioni ai due esercizi della prova di Strutture Dati del 19 Aprile con il prof. Salvatore La Torre.

E Il primo esercizio consisteva nell'implementare il metodo int maxValFoglie(BinaryTree<Integer> t) che restituisce il massimo tra i valori contenuti nelle foglie dell'albero t:

public static int maxValFoglie(BinaryTree<Integer> T)

{

int max = 0;

Iterable<Position<Integer>> posizioni = T.positions();

Iterator<Position<Integer>> it = posizioni.iterator();

while(it.hasNext())

{

Position<Integer> curr = it.next();

if (T.isExternal(curr))

max = Math.max(max, curr.element());

}

return max;

}

//versione ricorsiva

public static int maxValFoglie(BinaryTree<Integer> T)

{

return maxValFoglie(T, T.root(), 0);

}

public static int maxValFoglie(BinaryTree<Integer> T, Position<Integer> p, int max)

{

if(T.isExternal(p))

max = Math.max(max, p.element());

else

{

if (T.hasLeft(p))

max = maxValFoglie(T, T.left(p), max);

if (T.hasRight(p))

max = maxValFoglie(T, T.right(p), max);

}

return max;

}

mentre il secondo consisteva nell'implementare il metodo void forzaInorder(BinaryTree<E> t, PositionList<E> l) che a) testa se l'albero t e la lista l hanno lo stesso numero di elementi; b) in caso affermativo, gli elementi di l sono copiati in t in modo che la visita inorder di t produca l'ordine della lista l; c) in caso negativo viene lanciata una IrregularArgumentException:

public static <E> void forzaInorder(BinaryTree<E> t, PositionList<E> l)

{

if (t.size() != l.size())

throw new IllegalArgumentException("Tree and Sequence are different");

f(t,l,t.root());

}

public static <E> void f (BinaryTree<E>t, PositionList<E>s, Position<E> p)

{

if (t.hasLeft(p))

f(t, s, t.left(p));

t.replace(p, s.remove(s.first()));

if (t.hasRight(p))

f(t, s, t.right(p));

}

Strutture Dati - Priority Queue

noreply@blogger.com (Unknown) — Mon, 18 Apr 2011 17:42:00 +0000

Dato che il tempo scorre in fretta inizio subito a postare l'inizio degli esercizi che faremo domani in laboratorio sulle Code a Priorità, precisamente sono due implementazioni di PriorityQueue rispettivamente con lista ordinata, e non ordinata. Preciso che l'elemento c di entrambe le classi è di tipo java.util.Comparator e che l'implementazione di DefaultComparator la trovate sulle slides del prof (lez07). In bocca al lupo per la probabile prova su alberi e tour euleriani di domani a tutti i miei compagni di corso.

public class SortedListPriorityQueue<K,V> implements PriorityQueue<K,V>

{

protected PositionList<Entry<K,V>> entries;

protected Comparator<K> c;

protected static class MyEntry<K,V> implements Entry<K,V>

{

protected K k;

protected V v;

public MyEntry(K key, V value)

{

k = key;

v = value;

}

public K getKey() {return k;}

public V getValue() {return v;}

public String toString() { return "(k:"+k+" v:"+v+")"; }

}

public SortedListPriorityQueue()

{

entries = new NodePositionList<Entry<K,V>>();

c = new DefaultComparator<K>();

}

public SortedListPriorityQueue(Comparator<K> comp)

{

entries = new NodePositionList<Entry<K,V>>();

c = comp;

}

public int size()

{

return entries.size();

}

public boolean isEmpty()

{

return (entries.size() == 0);

}

public Entry<K, V> min() throws EmptyPriorityQueueException

{

Position<Entry<K,V>> min;

if (entries.isEmpty())

throw new EmptyPriorityQueueException();

else

{

min = entries.first();

Position<Entry<K,V>> prossimo = min;

for (int i=1; i<entries.size(); i++)

{

prossimo = entries.next(prossimo);

if (c.compare(min.element().getKey(), prossimo.element().getKey()) > 0)

min=prossimo;

}

return min.element();

}

public Entry<K, V> insert(K key, V value) throws InvalidKeyException

{

checkKey(key);

Entry<K,V> entry = new MyEntry<K,V>(key, value);

insertEntry(entry);

return entry;

}

public Entry<K, V> removeMin() throws EmptyPriorityQueueException

{

if (entries.isEmpty())

throw new EmptyPriorityQueueException();

else

return entries.remove(entries.first());

}

protected boolean checkKey(K key)

{

boolean result;

try

{

result = (c.compare(key,key)==0);

}

catch (ClassCastException e)

{

throw new InvalidKeyException("Not Comparable Key");

}

return result;

}

protected void insertEntry(Entry<K,V> e)

{

if (entries.isEmpty())

entries.addFirst(e);

else if (c.compare(e.getKey(), entries.last().element().getKey())> 0)

entries.addLast(e);

else

{

Position<Entry<K,V>> curr = entries.first();

while (c.compare(e.getKey(), curr.element().getKey())>0)

curr = entries.next(curr);

entries.addBefore(curr, e);

}

public String toString()

{

if (isEmpty())

return("Empty PQ");

String s="[ ";

Iterator<Entry<K,V>> it = entries.iterator();

while(it.hasNext())

s += it.next()+" ";

return s+"] size:"+size()+" min:"+min();

}

public class UnsortedListPriorityQueue<K,V> implements PriorityQueue<K,V>

{

protected PositionList<Entry<K,V>> entries;

protected Comparator<K> c;

protected static class MyEntry<K,V> implements Entry<K,V>

{

protected K k;

protected V v;

public MyEntry(K key, V value)

{

k = key;

v = value;

}

public K getKey() {return k;}

public V getValue() {return v;}

public String toString() { return "(k:"+k+" v:"+v+")"; }

}

public UnsortedListPriorityQueue()

{

entries = new NodePositionList<Entry<K,V>>();

c = new DefaultComparator<K>();

}

public UnsortedListPriorityQueue(Comparator<K> comp)

{

entries = new NodePositionList<Entry<K,V>>();

c = comp;

}

public int size()

{

return entries.size();

}

public boolean isEmpty()

{

return (entries.size() == 0);

}

public Entry<K, V> min() throws EmptyPriorityQueueException

{

Position<Entry<K,V>> min;

if (entries.isEmpty())

throw new EmptyPriorityQueueException();

else

{

min = entries.first();

Position<Entry<K,V>> prossimo = min;

for (int i=1; i<entries.size(); i++)

{

prossimo = entries.next(prossimo);

if (c.compare(min.element().getKey(), prossimo.element().getKey()) > 0)

min=prossimo;

}

return min.element();

}

public Entry<K, V> insert(K key, V value) throws InvalidKeyException

{

checkKey(key);

Entry<K,V> entry = new MyEntry<K,V>(key, value);

entries.addLast(entry);

return entry;

}

public Entry<K, V> removeMin() throws EmptyPriorityQueueException

{

Position<Entry<K,V>> min;

if (entries.isEmpty())

throw new EmptyPriorityQueueException();

else

{

min = entries.first();

Position<Entry<K,V>> prossimo = min;

for (int i=1; i<entries.size(); i++)

{

prossimo = entries.next(prossimo);

if (c.compare(min.element().getKey(), prossimo.element().getKey()) > 0)

min=prossimo;

}

return entries.remove(min);

}

protected boolean checkKey(K key)

{

boolean result;

try

{

result = (c.compare(key,key)==0);

}

catch (ClassCastException e)

{

throw new InvalidKeyException("UnComparable Key");

}

return result;

}

public String toString()

{

if (isEmpty())

return("Empty PQ");

String s="[ ";

Iterator<Entry<K,V>> it = entries.iterator();

while(it.hasNext())

s += it.next()+" ";

return s+"] size:"+size()+" min:"+min();

}

Strutture Dati - Tree and Binary Tree

noreply@blogger.com (Unknown) — Sat, 16 Apr 2011 15:35:00 +0000

Ecco un altro post sulle Strutture Dati, come da programma passiamo agli Alberi e gli Alberi Binari, non posto anche le implementazioni di EulerTour dato che si possono copiare dalle slides del prof, e inoltre ho dovuto rallentare il ritmo perché il tempo è sempre meno.

public class LinkedTree<E> implements Tree<E>

{

protected TreePosition<E> root;

protected int size;

public LinkedTree()

{

root = new TreeNode<E>();

size = 0;

}

public LinkedTree(E rootElement)

{

addRoot(rootElement);

}

public LinkedTree(TreePosition<E> r)

{

root = r;

if (root != null)

size = r.getChildren().size()+1;

else

size = 1;

}

public Iterator<E> iterator()

{

Iterable<Position<E>> positions = positions();

PositionList<E> elements = new NodePositionList<E>();

for(Position<E> pos: positions)

elements.addLast(pos.element());

return elements.iterator();

}

public int size()

{

return size;

}

public boolean isEmpty()

{

return (size == 0);

}

public Iterable<Position<E>> positions()

{

PositionList<Position<E>> lista = new NodePositionList<Position<E>>();

if (size != 0)

preorderPosition(root(), lista);

return lista;

}

public E replace(Position<E> p, E e) throws InvalidPositionException

{

TreeNode<E> nodo = (TreeNode<E>) checkPosition(p);

E tmp = nodo.element();

nodo.setElement(e);

return tmp;

}

public Position<E> root() throws EmptyTreeException

{

if (isEmpty())

throw new EmptyTreeException();

return root;

}

public Position<E> parent(Position<E> p) throws InvalidPositionException, BoundaryViolationException

{

TreeNode<E> tmp = (TreeNode<E>) checkPosition(p);

if (tmp == root)

throw new BoundaryViolationException("Root has no parent!");

return tmp.parent;

}

public Iterable<Position<E>> children(Position<E> p) throws InvalidPositionException

{

TreeNode<E> nodo = (TreeNode<E>) checkPosition(p);

if(isExternal(nodo))

throw new InvalidPositionException("External nodes do not have children!");

return nodo.getChildren();

}

public boolean isInternal(Position<E> p) throws InvalidPositionException

{

return (!isExternal(p));

}

public boolean isExternal(Position<E> p) throws InvalidPositionException

{

TreeNode<E> nodo = (TreeNode<E>) checkPosition(p);

return (nodo.getChildren() == null);

}

public boolean isRoot(Position<E> p) throws InvalidPositionException

{

TreeNode<E> nodo = (TreeNode<E>) checkPosition(p);

return (nodo.equals(root()));

}

public TreePosition<E> checkPosition(Position<E> p)throws InvalidPositionException

{

if (p == null || !(p instanceof TreePosition))

throw new InvalidPositionException();

return (TreePosition<E>) p;

}

protected void preorderPosition(Position<E> p, PositionList<Position<E>> pos) throws InvalidPositionException

{

pos.addLast(p);

if (isExternal(p))

return;

Iterator<Position<E>> it = children(p).iterator();

while(it.hasNext())

preorderPosition(it.next(),pos);

}

protected void postorderPosition(Position<E> p, PositionList<Position<E>> pos) throws InvalidPositionException

{

if (isInternal(p))

{

Iterator<Position<E>> it = children(p).iterator();

while(it.hasNext())

postorderPosition(it.next(),pos);

}

pos.addLast(p);

}

public String printPreOrder()

{

String s ="[ ";

NodePositionList<Position<E>> lista = new NodePositionList<Position<E>>();

preorderPosition(root, lista);

Iterator<Position<E>> it = lista.iterator();

while(it.hasNext())

s += it.next().element() + " ";

return s + "]";

}

public String printPostOrder()

{

String s ="[ ";

NodePositionList<Position<E>> lista = new NodePositionList<Position<E>>();

postorderPosition(root, lista);

Iterator<Position<E>> it = lista.iterator();

while(it.hasNext())

s += it.next().element() + " ";

return s + "]";

}

//metodo personale che stampa un nodo e il suo eventuale sottoalbero

private String stampaNodo(Position<E> p)

{

String s = "";

for(int i=0; i<depth(p); i++)

s += " ";

s += p.element().toString();

TreeNode<E> n = (TreeNode<E>) checkPosition (p);

if (isExternal(n))

return s +="\n";

else

s += "->\n";

Iterator<Position<E>> it = n.getChildren().iterator();

while (it.hasNext())

{

s += stampaNodo(it.next());

}

return s;

}

public String toString()

{

if (isEmpty())

return "EmptyTree";

return stampaNodo((TreeNode<E>) root())+" size:"+size;

}

public Position<E> addChild(E e, Position<E> p)

{

TreeNode<E> padre = (TreeNode<E>) checkPosition(p);

TreeNode<E> newNode = new TreeNode<E>(e,padre,null);

if (isExternal(padre))

{

PositionList<Position<E>> figli = new NodePositionList<Position<E>>();

figli.addLast(newNode);

padre.setChildren(figli);

}

else

{

padre.getChildren().addLast(newNode);

}

size++;

return newNode;

}

public Position<E> removeChild(Position<E> p) throws InvalidPositionException

{

TreeNode<E> nodo = (TreeNode<E>) checkPosition(p);

if (isExternal(nodo))

throw new InvalidPositionException("This Node has no children to remove");

TreeNode<E> childToRemove = (TreeNode<E>) nodo.getChildren().first().element();

int numFigli = childCounter(childToRemove);

nodo.getChildren().remove(nodo.getChildren().first());

size -= numFigli;

if (nodo.getChildren().size() == 0)

nodo.setChildren(null);

return childToRemove;

}

//conta il numero di figli +1 di un nodo

protected int childCounter(Position<E>p)

{

TreeNode<E> nodo = (TreeNode<E>) checkPosition(p);

if (isExternal(nodo))

return 1;

else

{

int numFigli = 0;

for(Position<E> figlio : children(nodo))

{

numFigli += childCounter(figlio);

}

return 1 + numFigli;

}

public Position<E> addRoot(E e) throws NonEmptyTreeException

{

if (!isEmpty())

throw new NonEmptyTreeException("Root exists already!");

TreeNode<E> newRoot = new TreeNode<E>(e,null,null);

size = 1;

root = newRoot;

return root;

}

public int depth(Position<E> p) throws InvalidPositionException

{

/*//ricorsivo

if (isRoot(p)) return 0;

return 1+depth(parent(p));

TreePosition<E> nodo = checkPosition(p);

if(isRoot(nodo))

return 0;

int depth=1;

TreePosition<E> par = nodo.getParent();

while(!isRoot(par))

{

par=par.getParent();

depth++;

}

return depth;

}

//metodo ricorsivo

public int height(Position<E> p)

if (isExternal(p) return 0;

else

{

int max = 0;

for(Position<E> child : children(p))

{

max = Math.max(max, height(child));

}

return max+1;

}

public int height()

{

return altezza(root());

}

protected int altezza(Position<E> p)

{

if (isExternal(p))

return 0;

else

{

int h = 0;

Iterator<Position<E>> children = children(p).iterator();

while(children.hasNext())

{

h = Math.max(h, altezza(children.next()));

}

return (1 + h);

}

//computa la somma degli elementi di un albero di interi

public static <E> int sum(LinkedTree<Integer> t)

{

if (t.isEmpty())

throw new EmptyTreeException();

return sum(t.root(),t);

}

* postSum mi calcola la somma del nodo p + tutti i suoi figli

* */

public static int sum(Position<Integer> p, LinkedTree<Integer> t)

{

TreeNode<Integer> nodo = (TreeNode<Integer>) t.checkPosition(p);

int sum = 0;

if (t.isInternal(p))

for(Position<Integer> pos : nodo.getChildren())

sum += sum( pos,t);

return (sum + p.element());

}

//restituisce la Position dell'elemento x se è presente nell'albero t

//null altrimenti

public static <E> Position<E> findElt(Tree<E> t, E x)

{

if (t.isEmpty())

throw new EmptyTreeException();

return find(t,t.root(),x);

}

public static <E> Position<E> find(Tree<E> t, Position<E> p, E x)

{

if (p.element().equals(x))

return p;

else

{

if (t.isExternal(p))

return null;

for(Position<E> pos : t.children(p))

{

Position<E> ris = find(t,pos,x);

if (ris != null)

{

return ris;

}

return null;

}

public class LinkedBinaryTree<E> implements BinaryTree<E>

{

private int size;

private BTNode<E> root;

public LinkedBinaryTree()

{

root = null;

size = 0;

}

public LinkedBinaryTree(E e)

{

addRoot(e);

}

public int size()

{

return size;

}

public boolean isEmpty()

{

return (size==0);

}

public Iterable<Position<E>> positions()

{

PositionList<Position<E>> lista = new NodePositionList<Position<E>>();

if (size != 0)

preorderPositions(root(), lista);

return lista;

}

public E replace(Position<E> p, E e) throws InvalidPositionException

{

BTNode<E> nodo = (BTNode<E>) checkPosition(p);

E tmp = nodo.element();

nodo.setElement(e);

return tmp;

}

public Position<E> root() throws EmptyTreeException

{

if (isEmpty())

throw new EmptyTreeException();

return root;

}

public Position<E> parent(Position<E> p) throws InvalidPositionException, BoundaryViolationException

{

BTNode<E> tmp = (BTNode<E>) checkPosition(p);

if (tmp.equals(root))

throw new BoundaryViolationException("Root has no parent!");

return tmp.getParent();

}

public Iterable<Position<E>> children(Position<E> p) throws InvalidPositionException

{

BTNode<E> nodo = (BTNode<E>) checkPosition(p);

if(isExternal(nodo))

throw new InvalidPositionException("External nodes do not have children!");

PositionList<Position<E>> figli = new NodePositionList<Position<E>>();

figli.addFirst(nodo.getLeft());

figli.addLast(nodo.getRight());

return figli;

}

public boolean isInternal(Position<E> p) throws InvalidPositionException

{

return (!isExternal(p));

}

public boolean isExternal(Position<E> p) throws InvalidPositionException

{

BTNode<E> nodo = (BTNode<E>) checkPosition(p);

return (nodo.getLeft()==null && nodo.getRight()==null);

}

public boolean isRoot(Position<E> p) throws InvalidPositionException

{

BTNode<E> nodo = (BTNode<E>) checkPosition(p);

return (nodo.equals(root));

}

public Iterator<E> iterator()

{

Iterable<Position<E>> positions = positions();

PositionList<E> elements = new NodePositionList<E>();

Iterator<Position<E>> it = positions.iterator();

while(it.hasNext())

elements.addLast(it.next().element());

return elements.iterator();

}

public Position<E> left(Position<E> v) throws InvalidPositionException, BoundaryViolationException

{

BTPosition<E> nodo = checkPosition(v);

if(isExternal(v))

throw new InvalidPositionException("External nodes have no children");

if(!hasLeft(v))

throw new BoundaryViolationException("This node has not a left chlid");

return nodo.getLeft();

}

public Position<E> right(Position<E> v) throws InvalidPositionException, BoundaryViolationException

{

BTPosition<E> nodo = checkPosition(v);

if(isExternal(v))

throw new InvalidPositionException("External nodes have no children");

if(!hasRight(v))

throw new BoundaryViolationException("This node has not a right chlid");

return nodo.getRight();

}

public boolean hasLeft(Position<E> v) throws InvalidPositionException

{

BTPosition<E> nodo = checkPosition(v);

if(nodo.getLeft()==null)

return false;

else

return true;

}

public boolean hasRight(Position<E> v) throws InvalidPositionException

{

BTPosition<E> nodo = checkPosition(v);

if(nodo.getRight()==null)

return false;

else

return true;

}

protected void preorderPositions(Position<E> v, PositionList<Position<E>> pos) throws InvalidPositionException

{

pos.addLast(v);

if (hasLeft(v))

preorderPositions(left(v), pos);

if (hasRight(v))

preorderPositions(right(v), pos);

}

public BTPosition<E> checkPosition(Position<E> p)throws InvalidPositionException

{

if (p == null || !(p instanceof BTPosition))

throw new InvalidPositionException();

return (BTPosition<E>) p;

}

public BTPosition<E> addRoot(E e) throws NonEmptyTreeException

{

if(!isEmpty())

throw new NonEmptyTreeException("Root exists already");

BTNode<E>nodo = new BTNode<E>(e,null,null,null);

root = nodo;

size = 1;

return root;

}

//metodo personale che stampa un nodo e il suo eventuale sottoalbero

private String stampaNodo(Position<E> p)

{

String s = "";

for(int i=0; i<depth(p); i++)

s += " ";

s += p.element().toString();

BTNode<E> n = (BTNode<E>) checkPosition (p);

if (isExternal(n))

return s +="\n";

else

s += "->\n";

NodePositionList<Position<E>> figli = new NodePositionList<Position<E>>();

if (hasLeft(n))

figli.addFirst(n.getLeft());

if(hasRight(n))

figli.addLast(n.getRight());

Iterator<Position<E>> it = figli.iterator();

while (it.hasNext())

{

s += stampaNodo(it.next());

}

return s;

}

public String toString()

{

if (isEmpty())

return "EmptyTree";

return stampaNodo((BTNode<E>) root())+" size: "+size;

}

public int depth(Position<E> p) throws InvalidPositionException

{

BTPosition<E> nodo = checkPosition(p);

if(isRoot(nodo))

return 0;

int prof=1;

BTPosition<E> par = nodo.getParent();

while(!isRoot(par))

{

par=par.getParent();

prof++;

}

return prof;

}

* Scrivere un metodo InsertLeft che prende in input

* un elemento e e una position p,

* inserisce il figlio sinistro di p con elemento

* e restituisce il riferimento alla nuova position inserita

* (se figlio sx esiste, lancia eccezione)*/

public Position<E> insertLeft(E e, Position<E> p)

{

BTNode<E> nodo = (BTNode<E>) checkPosition(p);

if (hasLeft(nodo))

throw new InvalidPositionException("The node already has a left child.");

BTNode<E> newNode = new BTNode<E>(e,nodo,null,null);

nodo.setLeft(newNode);

size++;

return newNode;

}

public Position<E> insertRight(E e, Position<E> p)

{

BTNode<E> nodo = (BTNode<E>) checkPosition(p);

if (hasRight(nodo))

throw new InvalidPositionException("The node already has a right child.");

BTNode<E> newNode = new BTNode<E>(e,nodo,null,null);

nodo.setRight(newNode);

size++;

return newNode;

}

public int height()

{

return altezza(root());

}

protected int altezza(Position<E> p)

{

if (isExternal(p))

{

return 0;

}

else

{

int h = 0;

BTNode<E> nodo = (BTNode<E>) checkPosition(p);

h = Math.max(altezza(nodo.getLeft()), altezza(nodo.getRight()));

return (1 + h);

}

//rimuove il figlio sinistro di p

public Position<E> removeLeft(Position<E> p) throws InvalidPositionException

{

BTNode<E> nodo = (BTNode<E>)checkPosition(p);

if (!hasLeft(nodo))

throw new InvalidPositionException("The node has not a left child.");

BTNode<E> childToRemove = (BTNode<E>) nodo.getLeft();

size -= childCounter(childToRemove);

nodo.setLeft(null);

return childToRemove;

}

//rimuove il figlio destro di p

public Position<E> removeRight(Position<E> p) throws InvalidPositionException

{

BTNode<E> nodo = (BTNode<E>)checkPosition(p);

if (!hasRight(nodo))

throw new InvalidPositionException("The node has not a right child.");

BTNode<E> childToRemove = (BTNode<E>) nodo.getRight();

size -= childCounter(childToRemove);

nodo.setLeft(null);

return childToRemove;

}

//conta il numero di figli +1 di un nodo

protected int childCounter(Position<E>p)

{

BTNode<E> nodo = (BTNode<E>) checkPosition(p);

if (isExternal(nodo))

return 1;

else

{

int numFigli = 0;

for(Position<E> figlio : children(nodo))

{

numFigli += childCounter(figlio);

}

return 1 + numFigli;

}

public static int sum(LinkedBinaryTree<Integer> t)

{

return sum(t.root(),t);

}

public static int sum(Position<Integer> p, LinkedBinaryTree<Integer> t)

{

int sum = p.element();

if (t.isInternal(p))

{

if (t.hasLeft(p))

sum += sum(t.left(p), t);

if (t.hasRight(p))

sum += sum(t.right(p), t);

}

return sum;

}

//verifica che l'ordine degli elementi dell'albero visitati inorder

//rispecchia l'ordine degli elementi della sequence

public static <E> boolean checkOrder(BinaryTree<E>t, Sequence<E> s)

{

if (t.isEmpty())

throw new EmptyTreeException();

if(s.isEmpty())

throw new EmptySequenceException();

if (t.size() != s.size())

throw new NotEnoughElements("Tree and Sequence are different");

return f(t,s,t.root());

}

public static <E> boolean f (BinaryTree<E>t, Sequence<E>s, Position<E> p)

{

if (t.hasLeft(p))

if (!f(t, s, t.left(p)))

return false;

if (!p.element().equals(s.first().element()))

return false;

s.removeFirst();

if (t.hasRight(p))

if (!f(t, s, t.right(p)))

return false;

return true;

}

Caricare il cellulare con un caricabatterie solare usb fai da te

noreply@blogger.com (Unknown) — Thu, 07 Apr 2011 23:31:00 +0000

Salve ragazzi questo post è dedicato all'ambiente, navigando ho trovato questi due links utilissimi che mi permetteranno presto di creare un caricabatterie solare usb con pochi spiccioli, e un cavo per caricare il mio cellulare Nokia tramite porta Usb, e volevo condividere queste informazioni preziose con voi.

Questo è il link per creare un cavo per caricare il proprio cellulare Nokia tramite porta usb

e questo è il link del Video che dice come assemblare delle mini celle fotovoltaiche per comporre un caricabatterie solare portatile.

Su Ebay ho trovato delle celle fotovoltaiche identiche a quelle del video, 5 celle a meno di 20 € spedizione inclusa!

W IL SOLE, ABBASSO IL PETROLIO!!!

E per i più arditi.... ecco un video su come autocostruirsi una cella fotovoltaica all'ossido di rame

Strutture Dati - Iterator e positions()

noreply@blogger.com (Unknown) — Thu, 07 Apr 2011 14:03:00 +0000

Quinto post dedicato alle Strutture Dati, oggi di preciso implementeremo l'interfaccia java.lang.Iterable nelle strutture dati dei post precedenti (vedere il metodo iterator() ). Un Iteratore è un'oggetto che permette di scandire gli elementi di un contenitore a prescindere dalla sua implementazione.

Ci sono due modi di implementare un iteratore:

uno è quello di usare una qualsiasi struttura dati che fornisca un accesso sequenziale ai suoi elementi, in questo caso il costruttore dell'iteratore impiegherà tempo O(n) per copiare tutti gli elementi della struttura nell'iteratore; ma l'iteratore creato in questo modo andrà bene per qualunque struttura dati
un altro è quello di utilizzare un cursore, cioè una variabile che tenga traccia dell'elemento corrente, in questo modo il costruttore dell'iteratore non dovrà copiare tutti gli elementi della struttura, ma utilizzerà un riferimento ad essa impiegando tempo O(1); lo svantaggio nell'uso di un cursore è quello di dover fornire un'implementazione specifica di Iterator per ogni tipo di Struttura Dati.

Una volta introdotto il concetto di iteratori e iterabilità possiamo aggiungere a tutti i Tipi di Dato Astratto che implementano il concetto di Position, il metodo Iterable<Position<E>> positions()
che restituisce una collezione iterabile contenente le posizioni del TDA come elementi. Per fare ciò, aggiungiamo la firma di questo metodo all'interfaccia PositionList vista nel 3°post di questa serie, e lo implementiamo in tutte le classi che implementano quest'interfaccia.

public class LinkedIterator<E> implements Iterator<E>

{

private Node<E> nodo;

private int size;

//il costruttore richiede tempo O(n) per copiare gli elementi

public LinkedIterator(E[] a)

{

nodo = null;

size = a.length;

for(int i=size-1; i>=0; i--)

{

Node<E> tmp = new Node<E>(a[i],nodo);

nodo = tmp;

}

public boolean hasNext()

{

return (size>0);

}

public E next()

{

E tmp = nodo.getElement();

remove();

return tmp;

}

public void remove()

{

if (!hasNext())

throw new NoSuchElementException();

nodo = nodo.getNext();

size--;

}

public class ElementIterator<E> implements Iterator<E>

{

private PositionList<E> lista;

private Position<E> cur;

//il costruttore di questa classe impiega tempo O(1)

//a differenza di quello di LinkedIterator che ne impiegava O(n)

public ElementIterator(PositionList<E> L)

{

lista = L;

if (!L.isEmpty())

cur = L.first();

}

public boolean hasNext()

{

return (cur!=null);

}

public E next() throws NoSuchElementException

{

if (lista.isEmpty())

throw new NoSuchElementException("Lista vuota! next() non possibile");

E tmp = cur.element();

if (cur == lista.last())

cur = null;

else

cur = lista.next(cur);

return tmp;

}

public void remove() {}

}

public class IndexListIterator<E> implements Iterator<E>

{

private IndexList<E> a;

private int i;

public IndexListIterator(IndexList<E> A)

{

a = A;

if (!a.isEmpty())

i = 0;

}

public boolean hasNext()

{

return (i < a.size());

}

public E next() throws NoSuchElementException

{

if (a.isEmpty())

throw new NoSuchElementException("Array vuoto! next() non possibile");

return a.get(i++);

}

public void remove() { }

}

public class TestIteratorAndPositions {

public static void main(String[] args) {

ArrayIndexList<Integer> l = new ArrayIndexList<Integer>();

ArrayIndexSequence<Integer> s = new ArrayIndexSequence<Integer>();

NodeSequence<Integer> s2 = new NodeSequence<Integer>();

NodePositionList<Integer> l2 = new NodePositionList<Integer>();

for(int i=1; i<=10; i++)

l2.addLast(i*4);

System.out.println(l2);

Iterator<Integer> iter = l2.iterator();

System.out.println("Stampa NodePositionList con iterator()");

while(iter.hasNext())

System.out.print(iter.next()+" ");

Iterable<Position<Integer>> posIt = l2.positions();

Iterator<Position<Integer>> posIterator = posIt.iterator();

System.out.println("\nStampa NodePositionList con positions()");

while(posIterator.hasNext())

System.out.print(posIterator.next() + " ");

for(int i=0; i<10; i++)

s.add(i, (i+1)*2);

System.out.println("\n\n"+s);

Iterator<Integer> it = (IndexListIterator<Integer>) s.iterator();

System.out.println("Stampa sequenza con iterator()");

while(it.hasNext())

System.out.print(it.next() + " ");

posIt = s.positions();

posIterator = posIt.iterator();

System.out.println("\nStampa sequenza con positions()");

while(posIterator.hasNext())

System.out.print(posIterator.next() + " ");

for(int i=0; i<10; i++)

s2.add(i, (i+1)*5);

System.out.println("\n\n"+s2);

it = (Iterator<Integer>) s2.iterator();

System.out.println("Stampa sequenza con iterator()");

while(it.hasNext())

System.out.print(it.next() + " ");

posIt = s2.positions();

posIterator = posIt.iterator();

System.out.println("\nStampa sequenza con positions()");

while(posIterator.hasNext())

System.out.print(posIterator.next() + " ");

for(int i=0; i<10; i++)

l.add(i, (i+1)*3);

System.out.println("\n\n"+l);

it = (IndexListIterator<Integer>) l.iterator();

System.out.println("Stampa lista con iterator()");

while(it.hasNext())

System.out.print(it.next() + " ");

}

Prova del 5 Aprile 2011

noreply@blogger.com (Unknown) — Wed, 06 Apr 2011 23:38:00 +0000

Questa è l'implementazione della mini-prova di Strutture Dati fatta dal prof La Torre il 5 Aprile 2011. Nella prima parte dell'esercizio veniva fornita un'interfaccia SequenzaIncompleta, e veniva chiesto di implementarne i metodi nella classe MiaSequenzaIncompleta usando a scelta una delle classi sviluppate durante il corso che implementano l'interfaccia Sequence (completa). Nella seconda parte veniva fornita una classe di Test per MiaSequenzaIncompleta dove veniva chiesto di scrivere una funzione che prende in input una Sequenza e la inverte.

public interface SequenzaIncompleta<E>

{

public void addFirst(E e);

public E removeLast();

public E get(int i);

public Position<E> first();

public int size();

}

public class MiaSequenzaIncompleta<E> implements SequenzaIncompleta<E>

{

private ArrayIndexSequence<E> sequenza;

//private NodeSequence<E> sequenza;

public MiaSequenzaIncompleta()

{

sequenza = new ArrayIndexSequence<E>();

//sequenza = new NodeSequence<E>();

}

public void addFirst(E e)

{

sequenza.addFirst(e);

}

public Position<E> first()

{

return sequenza.first();

}

public E get(int i)

{

return sequenza.get(i);

}

public E removeLast() {

return sequenza.removeLast();

}

public int size() {

return sequenza.size();

}

public class TestSequenzaIncompleta

{

public static void main(String[] args)

{

SequenzaIncompleta<Integer> s = new MiaSequenzaIncompleta<Integer>();

for (int i=10; i>0 ; i--)

s.addFirst(i);

System.out.println("Sequenza iniziale");

stampa(s);

System.out.println("Sequenza invertita");

inverti(s);

stampa(s);

System.out.println("Rimuovi ultimo");

stampa(s);

System.out.println("Elemento rimosso ="+ s.removeLast());

System.out.println("Primo elemento ="+ s.first().element());

System.out.println("Inverti di nuovo");

inverti(s);

stampa(s);

}

private static <E> void stampa(SequenzaIncompleta<E> S){

for (int i=0; i<S.size() ; i++)

System.out.print(S.get(i)+ " ");

System.out.println("\n");

}

private static <E> void inverti(SequenzaIncompleta<E> S)

{

int n = S.size();

int count = 0;

for(int i=1; i<n; i++)

{

S.addFirst(S.get(i+count));

count++;

}

for(int i=1; i<n; i++)

S.removeLast();

}

//soluzione del prof.

/* private static <E> void inverti(SequenzaIncompleta<E> S)

{

int size = S.size();

for(int i=1; i<size; i++) S.addFirst(S.get(2*i-1));

for(int i=1; i<size; i++) S.removeLast();

}

Strutture Dati - Sequence

noreply@blogger.com (Unknown) — Wed, 06 Apr 2011 23:00:00 +0000

Questo è il quarto post sulle Strutture Dati, vedremo le Interfacce e le Implementazioni del TDA Sequence mediante NodePositionList (NodeSequence), e ArrayIndexList (ArrayIndexSequence), entrambe viste nell'articolo precedente. Raccomando la lettura di questo post agli studenti dell'Università degli studi di Salerno che studiano Informatica o Informatica Applicata e devono sostenere l'esame di Strutture Dati (SD) o di Laboratorio di Algoritmi e Strutture Dati (LASD) con il professor Salvatore La Torre. Invito i miei colleghi studenti a desistere dalla tentazione di presentarvi all'esame con i miei esercizi, (che per quanto io possa essere sicuro che siano corretti potrebbero comunque contenere errori) ma al massimo di usarli per confrontarli con i vostri.

public interface Sequence<E> extends PositionList<E>, IndexList<E>

{

public Position<E> atIndex(int i) throws BoundaryViolationException;

public int indexOf(Position<E> p) throws InvalidPositionException;

public E getFirst() throws EmptySequenceException;

public E getLast() throws EmptySequenceException;

public E removeFirst() throws EmptySequenceException;

public E removeLast() throws EmptySequenceException;

}

public class NodeSequence<E> extends NodePositionList<E> implements Sequence<E>

{

public NodeSequence()

{

super();

}

protected void checkIndex(int index,int n) throws BoundaryViolationException

{

if (index < 0 || index >= n)

throw new BoundaryViolationException ("Indice " + index + " non valido");

}

public E get(int i) throws IndexOutOfBoundsException

{

checkIndex(i, size());

return (atIndex(i).element());

}

public E set(int i, E e) throws IndexOutOfBoundsException

{

checkIndex(i, size());

return set(atIndex(i), e);

}

public void add(int i, E e) throws IndexOutOfBoundsException

{

if (i==size())

{

addLast(e);

}

else

{

addBefore(atIndex(i), e);

}

public E remove(int i) throws IndexOutOfBoundsException

{

checkIndex(i, size());

return remove(atIndex(i));

}

public E getFirst() throws EmptySequenceException

{

return get(indexOf(first()));

}

public E getLast() throws EmptySequenceException

{

return get(indexOf(last()));

}

public E removeFirst() throws EmptySequenceException

{

if (isEmpty())

throw new EmptySequenceException();

return remove(indexOf(first())); }

public E removeLast() throws EmptySequenceException

{

if (isEmpty())

throw new EmptySequenceException();

return remove(indexOf(last()));

}

public Position<E> atIndex(int i) throws BoundaryViolationException

{

checkIndex(i,size());

DNode<E> node;

if (i <= size()/2)

{

node = (DNode<E>) first();

for (int j=0; j < i; j++)

node = node.getNext();

}

else

{

node = (DNode<E>) last();

for (int j=1; j < size()-i; j++)

node = node.getPrev();

}

return node;

}

public int indexOf(Position<E> p) throws InvalidPositionException

{

DNode<E> nodo = checkPosition(p);

DNode<E> aNode = (DNode<E>) first();

int index = 0;

while(aNode != nodo)

{

index++;

aNode = aNode.getNext();

}

return index;

}

public String toString()

{

String stringa = super.toString();

stringa = (String) stringa.subSequence(stringa.indexOf(" "), stringa.length());

stringa = "NodeSequence"+ stringa;

return stringa;

}

public void makeFirst(Position<E> p)

{

DNode<E> node = checkPosition(p);

node.getPrev().setNext(node.getNext());

node.getNext().setPrev(node.getPrev());

node.setNext(header.getNext());

node.setPrev(header);

node.getNext().setPrev(node);

header.setNext(node);

}

public class ArraySequence<E> implements Sequence<E>, Iterable<E>

{

private final static int CAPACITY = 1024;

private ArrayPosition<E> array[];

private int size, capacity, f;

//costruttori

public ArraySequence()

{

this(CAPACITY);

}

@SuppressWarnings("unchecked")

public ArraySequence(int cap)

{

capacity = cap;

array = new ArrayPosition[capacity];

size = f = 0;

}

public int size()

{

return size;

}

public boolean isEmpty()

{

return (size==0);

}

public Position<E> first() throws EmptySequenceException

{

if (isEmpty())

throw new EmptySequenceException();

return array[map(0)];

}

public E getFirst() throws EmptySequenceException

{

if (isEmpty())

throw new EmptySequenceException();

return first().element();

}

public Position<E> last() throws EmptySequenceException

{

if (isEmpty())

throw new EmptySequenceException();

return array[map(size-1)];

}

public E getLast() throws EmptySequenceException

{

if (isEmpty())

throw new EmptySequenceException();

return last().element();

}

public E get(int i) throws IndexOutOfBoundsException

{

checkIndex(i, size);

return array[map(i)].element();

}

private void checkIndex(int i, int n) throws IndexOutOfBoundsException

{

if (i<0 || i>n)

throw new IndexOutOfBoundsException();

}

private ArrayPosition<E> checkPosition (Position<E> p) throws InvalidPositionException

{

if (p == null) throw new InvalidPositionException("null position");

try

{

ArrayPosition<E> temp = (ArrayPosition<E>) p;

boolean flag = false;

for(int i=0; i<size; i++)

{

if (array[map(i)].equals(temp))

flag = true;

}

if (flag)

return temp;

else

throw new InvalidPositionException("This element does not belog to this sequence");

}

catch (ClassCastException e)

{

throw new InvalidPositionException("not an ArrayPosition");

}

public Position<E> prev(Position<E> p) throws InvalidPositionException, BoundaryViolationException

{

ArrayPosition<E> tmp = checkPosition(p);
if(tmp.equals(first()))

throw new InvalidPositionException("No Positions before the first");

int index = tmp.getIndex()-1;

return array[map(index)];

}

public Position<E> next(Position<E> p) throws InvalidPositionException, BoundaryViolationException

{

ArrayPosition<E> tmp = checkPosition(p);

if(tmp.equals(last()))

throw new InvalidPositionException("No Positions after the last");

int index = tmp.getIndex()+1;

return array[map(index)];

}

public void add(int i, E e) throws IndexOutOfBoundsException

{

checkIndex(i,size);

if (size() == capacity)

{

@SuppressWarnings("unchecked")

ArrayPosition<E> tmp[] = new ArrayPosition[capacity*2];

for(int j=0; j<capacity;j++)

tmp[j] = array[map(j)];

array = tmp;

capacity *=2;

f=capacity-1;

}

ArrayPosition<E> newElem = new ArrayPosition<E>(i,e);

if(i==0)

{

array[f]=newElem;

f=(f-1+capacity)%capacity;

}

if(i>0)

{

for(int j= size-1; j>= i; j--)

{

array[map(j+1)] = array[map(j)];

array[map(j+1)].setIndex(j+1);

}

array[map(i)] = newElem;

}

size++;

//aggiorno gli indici

for(int j=size()-1; j >= i; j--)

{

ArrayPosition<E> tmp = array[map(j)];

tmp.setIndex(j);

}

public Position<E> addBefore(Position<E> p, E e) throws InvalidPositionException

{

ArrayPosition<E> tmp = checkPosition(p);

int i = indexOf(tmp);

add(i,e);

return prev(tmp);

}

public Position<E> addAfter (Position<E> p, E e) throws InvalidPositionException

{

ArrayPosition<E> tmp = checkPosition(p);

int i = indexOf(tmp)+1;

add(i, e);

return next(tmp);

}

public void addFirst(E e)

{

add(0,e);

}

public void addLast(E e)

{

add(size,e);

}

public E remove(Position<E> p) throws InvalidPositionException

{

checkPosition(p);

return remove(indexOf(p));

}

public E remove(int i) throws IndexOutOfBoundsException

{

checkIndex(i,size);

E e = array[map(i)].element();

if(i==0)

f=(f+1)%capacity;

else

for(int j = i; j<size-1; j++)

array[map(j)] = array[map(j+1)];

size--;

for(int j=size()-1; j >= i; j--)

{

ArrayPosition<E> tmp = array[map(j)];

tmp.setIndex(j);

}

if (size<capacity/3)

{

@SuppressWarnings("unchecked")

ArrayPosition<E> nuovoArray[] = new ArrayPosition[capacity/2];

for(int j=0; j<size; j++)

nuovoArray[j] = array[map(j)];

array = nuovoArray;

capacity /= 2;

f = capacity-1;

}

return e;

}

public E removeFirst() throws EmptySequenceException

{

return remove(0);

}

public E removeLast() throws EmptySequenceException

{

return remove(size-1);

}

public E set(Position<E> p, E e) throws InvalidPositionException

{

ArrayPosition<E> tmp = checkPosition(p);

return set(indexOf(tmp),e);

}

public E set(int i, E e) throws IndexOutOfBoundsException

{

checkIndex(i,size);

ArrayPosition<E> newEl = new ArrayPosition<E>(i,e);

array[map(i)] = newEl;

return e;

}

public Position<E> atIndex(int i) throws BoundaryViolationException

{

try

{

checkIndex(i, size());

}

catch(IndexOutOfBoundsException e)

{

throw new BoundaryViolationException("atIndex non possibile.");

}

return array[map(i)];

}

public int indexOf(Position<E> p) throws InvalidPositionException

{

ArrayPosition<E> tmp = checkPosition(p);

return tmp.getIndex();

}

public int map(int i)

{

return(i+f+1)%capacity;

}

public Iterator<E> iterator()

{

return new ElementIterator<E>(this);

}

public Iterable<Position<E>> positions()

{

PositionList<Position<E>> tmp = new ArraySequence<Position<E>>();

for(int i=0; i<size; i++)

tmp.addLast(array[map(i)]);

return tmp;

}

public String toString()

{

String retVal = "[ ";

for(int i=0; i<size(); i++)

{

retVal += array[map(i)] +" ";

}

retVal += "] size:"+size+" capacity:"+capacity;

return retVal;

}

public class ArrayIndexSequence<E> implements Sequence<E>

{

private ArrayIndexList<ArrayPosition<E>> array;

public void makeFirst(Position<E> p)

{

checkPosition(p);

E tmp = remove(p);

addFirst(tmp);

}

public ArrayIndexSequence()

{

array = new ArrayIndexList<ArrayPosition<E>>();

}

public ArrayIndexSequence(int cap)

{

array = new ArrayIndexList<ArrayPosition<E>>(cap);

}

public int size()

{

return array.size();

}

public boolean isEmpty()

{

return array.isEmpty();

}

public Position<E> first() throws EmptySequenceException

{

if (isEmpty())

throw new EmptySequenceException();

return array.get(0);

}

public Position<E> last() throws EmptySequenceException

{

if (isEmpty())

throw new EmptySequenceException();

return array.get(array.size()-1);

}

public E getFirst() throws EmptySequenceException

{

return first().element();

}

public E getLast() throws EmptySequenceException

{

return last().element();

}

public Position<E> prev(Position<E> p) throws InvalidPositionException, BoundaryViolationException

{

ArrayPosition<E> tmp = checkPosition(p);

return array.get(indexOf(tmp)-1);

}

public Position<E> next(Position<E> p) throws InvalidPositionException,BoundaryViolationException

{

ArrayPosition<E> tmp = checkPosition(p);

return array.get(indexOf(tmp)+1);

}

public void add(int i, E e) throws IndexOutOfBoundsException

{

checkIndex(i, array.size());

ArrayPosition<E> newElement = new ArrayPosition<E>(i,e);

array.add(i,newElement);

//aggiorno gli indici

for(int j=array.size()-1; j >= i; j--)

array.get(j).setIndex(j);

}

public Position<E> addBefore(Position<E> p, E e) throws InvalidPositionException

{

ArrayPosition<E> tmp = checkPosition(p);

int i = indexOf(tmp);

add(i,e);

return array.get(i);

}

public Position<E> addAfter(Position<E> p, E e) throws InvalidPositionException

{

ArrayPosition<E> tmp = checkPosition(p);

int i = indexOf(tmp)+1;

add(i, e);

return array.get(i);

}

public void addFirst(E e)

{

add(0, e);

}

public void addLast(E e)

{

add(array.size(), e);

}

public E set(int i, E e) throws IndexOutOfBoundsException

{

checkIndex(i, array.size());

ArrayPosition<E> newElement = new ArrayPosition<E>(i,e);

array.set(i,newElement).element();

return e;

}

public E set(Position<E> p, E e) throws InvalidPositionException

{

ArrayPosition<E> newElement = checkPosition(p);

newElement.setElement(e);

return array.set(indexOf(p), newElement).element();

}

public E get(int i) throws IndexOutOfBoundsException

{

checkIndex(i, array.size());

return array.get(i).element();

}

public E remove(int i) throws IndexOutOfBoundsException

{

if (isEmpty())

throw new EmptySequenceException();

checkIndex(i, array.size());

E tmp = array.remove(i).element();

//aggiorno gli indici

for(int j=array.size()-1; j >= i; j--)

array.get(j).setIndex(j);

return tmp;

}

public E remove(Position<E> p) throws InvalidPositionException

{

E tmp =remove(indexOf(p));

return tmp;

}

public E removeFirst() throws EmptySequenceException

{

E tmp = remove(0);

return tmp;

}

public E removeLast() throws EmptySequenceException

{

E tmp = remove(array.size()-1);

return tmp;

}

public Position<E> atIndex(int i) throws BoundaryViolationException

{

checkIndex(i,array.size());

return array.get(i);

}

public int indexOf(Position<E> p) throws InvalidPositionException

{

try

{

ArrayPosition<E> tmp = (ArrayPosition<E>)p;

return tmp.getIndex();

}

catch(InvalidPositionException e)

{

return -1;

}

private ArrayPosition<E> checkPosition(Position<E> p) throws InvalidPositionException

{

if (p == null) throw new InvalidPositionException("null position");

try

{

ArrayPosition<E> temp = (ArrayPosition<E>) p;

if (indexOf(temp)<0)

throw new InvalidPositionException();

return temp;

}

catch (ClassCastException e)

{

throw new InvalidPositionException("Cast Error: it's not an ArrayPosition");

}

private void checkIndex(int i, int n) throws BoundaryViolationException

{

if(i<0 || i>n)

throw new BoundaryViolationException("Indice "+i+" non valido");

}

public String toString()

{

return "ArrayIndexSequence ["+ array.toString().subSequence(array.toString().indexOf(" "), array.toString().length());

}

public Iterator<E> iterator()

{

return new IndexListIterator<E>((IndexList<E>) array);

}

public Iterable<Position<E>> positions()

{

IndexList<Position<E>> tmp = new ArrayIndexList<Position<E>>();

for(int i=0; i<array.size(); i++)

tmp.add(i, array.get(i));

return tmp;

}

Scrivere la funzione ricorsiva

boolean search(Sequence<E>S, E x)

che restituisce true se la sequenza S contiene l’elemento x.

Definizione ricorsiva: search(<s1,...,sn>, x) restituisce

false, se n=0

true, se s1=x

Il valore restituito da search(<s2,...,sn>, x), altrimenti

public static <E> boolean search(Sequence<E> S, E x)

{

if (S.size()==0)

return false;

if (S.get(0).equals(x))

return true;

E tmp = S.removeFirst();

boolean ris = search(S, x);

S.addFirst(tmp);

return ris;

}

Questa è l'implementazione di ArraySequence di Valerio, che ringrazio per le correzioni al mio codice.

/**

* Implementazione dell'interfaccia Sequence mediante

* un array circolare ed estendibile di ArrayPosition.

* @see EmptyListException

* @see EmptySequenceException

* @see IndexOutOfBoundsException

* @see InvalidPositionException

public class ArraySequence<E> implements Sequence<E> {

// Array circolare contenente la sequenza.

private ArrayPosition<E> S[];

// Indice della prima posizione.

private int first = 0;

// Indice della prima posizione libera dopo l'ultimo elemento.

private int last = 0;

// Capacit‡ dell'array.

private int capacity;

// Capacit‡ di default dell'array.

public static final int CAPACITY = 1024;

/**

* Costruttore di default.

public ArraySequence() {

this(CAPACITY);

}

/**

* Inizializza l'array con una grandezza specificata.

* @param cap la lunghezza dell'array

@SuppressWarnings("unchecked")

public ArraySequence(int cap) {

capacity = cap;

S = new ArrayPosition[capacity];

}

/**

* Restituisce il numero di posizioni della sequenza.

* @return il numero di posizioni

public int size() {

return (capacity-first+last) % capacity;

}

/**

* Verifica se la sequenza Ë vuota.

* @return true se la sequenza Ë vuota, false altrimenti

public boolean isEmpty() {

return (first == last);

}

/**

* Restituisce l'elemento della prima posizione.

* @return il primo elemento

* @throws EmptySequenceException se la sequenza Ë vuota

public E getFirst() throws EmptySequenceException {

return first().element();

}

/**

* Restituisce l'elemento dell'ultima posizione.

* @return l'ultimo elemento

* @throws EmptySequenceException se la sequenza Ë vuota

public E getLast() throws EmptySequenceException {

return last().element();

}

/**

* Inserisce una nuova posizione con elemento dato

* all'inizio della sequenza.

* @param element l'elemento da memorizzare nella nuova posizione

public void addFirst(E elem) {

add(0, elem);

}

/**

* Inserisce una nuova posizione con elemento dato

* alla fine della sequenza.

* @param element l'elemento da memorizzare nella nuova posizione

public void addLast(E elem) {

add(size(), elem);

}

/**

* Rimuove la prima posizione della sequenza e

* restituisce l'elemento memorizzato in essa.

* @return l'elemento memorizzato

* @throws EmptySequenceException se la sequenza Ë vuota

public E removeFirst() throws EmptySequenceException {

return remove(0);

}

/**

* Rimuove l'ultima posizione della sequenza e

* restituisce l'elemento memorizzato in essa.

* @return l'elemento memorizzato

* @throws EmptySequenceException se la sequenza Ë vuota

public E removeLast() throws EmptySequenceException {

return remove(size() - 1);

}

/**

* Restituisce la prima posizione della sequenza.

* @return la prima posizione

* @throws EmptySequenceException se la sequenza Ë vuota

public Position<E> first() throws EmptySequenceException {

if (isEmpty())

throw new EmptySequenceException();

return S[first];

}

/**

* Restituisce l'ultima posizione della sequenza.

* @return l'ultima posizione

* @throws EmptySequenceException se la sequenza Ë vuota

public Position<E> last() throws EmptySequenceException {

if (isEmpty())

throw new EmptySequenceException();

return S[map(size()-1)];

}

/**

* Restituisce la posizione precedente a quella data.

* @param p la posizione di partenza

* @return la posizione precedente

* @throws InvalidPositionException se la posizione non Ë valida

* @throws BoundaryViolationException se fuori range

public Position<E> prev(Position<E> p)

throws InvalidPositionException, BoundaryViolationException {

ArrayPosition<E> pos = checkPosition(p);

checkIndex(indexOf(pos), size());

if (pos.equals(first()))

throw new BoundaryViolationException("Nessuna posizione prima del primo.");

return atIndex(indexOf(pos) - 1);

}

/**

* Restituisce la posizione successiva a quella data.

* @param p la posizione di partenza

* @return la posizione successiva

* @throws InvalidPositionException se la posizione non Ë valida

* @throws BoundaryViolationException se fuori range

public Position<E> next(Position<E> p)

throws InvalidPositionException, BoundaryViolationException {

ArrayPosition<E> pos = checkPosition(p);

checkIndex(indexOf(pos), size());

if (pos.equals(last()))

throw new BoundaryViolationException("Nessuna posizione dopo l'ultimo.");

return atIndex(indexOf(pos) + 1);

}

/**

* Inserisce una nuova posizione con elemento dato

* prima la posizione specificata.

* @param p la posizione che deve succedere

* @param elem l'elemento da memorizzare

* @return la nuova posizione

* @throws InvalidPositionException se la posizione non Ë valida

public Position<E> addBefore(Position<E> p, E elem) throws InvalidPositionException {

ArrayPosition<E> pos = checkPosition(p);

int i = indexOf(pos);

add(i, elem);

return prev(pos);

}

/**

* Inserisce una nuova posizione con elemento dato

* dopo la posizione specificata.

* @param p la posizione che deve precedere

* @param elem l'elemento da memorizzare

* @return la nuova posizione

* @throws InvalidPositionException se la posizione non Ë valida

public Position<E> addAfter(Position<E> p, E elem) throws InvalidPositionException {

ArrayPosition<E> pos = checkPosition(p);

int i = indexOf(pos) + 1;

add(i, elem);

return next(pos);

}

/**

* Rimuove la posizione data e restituisce l'elemento

* in essa memorizzato.

* @param p la posizione da rimuovere

* @return l'elemento memorizzato

* @throws InvalidPositionException se la posizione non Ë valida

public E remove(Position<E> p) throws InvalidPositionException {

ArrayPosition<E> pos = checkPosition(p);

return remove(indexOf(pos));

}

/**

* Rimpiazza l'elemento memorizzato nella posizione data

* con un nuovo elemento e lo restituisce.

* @param p la posizione in cui rimpiazzare l'elemento

* @param elem il nuovo elemento da settare

* @return il vecchio elemento

* @throws InvalidPositionException se la posizione non Ë valida

public E set(Position<E> p, E elem) throws InvalidPositionException {

ArrayPosition<E> pos = checkPosition(p);

E oldElem = pos.element();

pos.setElement(elem);

return oldElem;

}

/**

* Restituisce l'elemento della posizione di indice dato.

* @param index l'indice della posizione

* @return l'elemento della posizione

* @throws IndexOutOfBoundsException se fuori range

public E get(int index) throws IndexOutOfBoundsException {

checkIndex(index, size());

return atIndex(index).element();

}

/**

* Rimpiazza l'elemento della posizione di indice dato

* con un nuovo elemento e restituisce il vecchio elemento.

* @param index l'indice della posizione

* @param elem il nuovo elemento

* @return il vecchio elemento

* @throws IndexOutOfBoundsException se fuori range

public E set(int index, E elem) throws IndexOutOfBoundsException {

checkIndex(index, size());

ArrayPosition<E> pos = (ArrayPosition<E>) atIndex(index);

return set(pos, elem);

}

/**

* Inserisce una nuova posizione di indice specificato.

* @param index l'indice della posizione

* @param elem l'elemento da memorizzare

* @throws IndexOutOfBoundsException se fuori range

public void add(int index, E elem) throws IndexOutOfBoundsException {

checkIndex(index, size());

if (size() == capacity-1)

raddoppia();

ArrayPosition<E> newPos = new ArrayPosition<E>(index, elem);

if (index == 0) {

first = (first-1+capacity) % capacity;

S[first] = newPos;

// Aggiorno gli indici

for (int j=1; j<size(); j++)

S[map(j)].setIndex(j);

}

else {

for (int j=size()-1; j>=index; j--) {

S[map(j+1)] = S[map(j)];

S[map(j+1)].setIndex(j+1);

}

S[map(index)] = newPos;

last = (last + 1) % capacity;

}

/**

* Rimuove la posizione di indice dato e ne restituisce l'elemento.

* @param index l'indice della posizione

* @return l'elemento memorizzato

* @throws IndexOutOfBoundsException se fuori range

public E remove(int index) throws IndexOutOfBoundsException {

checkIndex(index, size());

E elem = atIndex(index).element();

if (index == 0) {

S[first] = null;

first = (first+1) % capacity;

// Vengono aggiornati gli indici.

for (int j=0; j<size(); j++)

S[map(j)].setIndex(j);

}

else {

last = (last-1+capacity) % capacity;

// Gli elementi vengono shiftati a sinistra

// e vengono aggiornati gli indici.

for (int h=index; h<size(); h++) {

S[map(h)] = S[map(h+1)];

S[map(h)].setIndex(h);

}

return elem;

}

/**

* Restituisce una rappresentazione testuale di un ArraySequence

* come una lista di elementi: [primo, secondo, ... , ultimo].

* @return una rappresentazione testuale della lista

public String toString() {

String s = "[";

int i = 0;

if (size() > 0)

s += get(i);

if (size() > 1)

for (i=1; i<size(); i++)

s += ", " + get(i);

s += "]";

return s;

}

/**

* Metodo di servizio che controlla che l'indice sia nel range [0, n-1].

* @param index l'indice da controllare

* @param n il valore del range

* @throws IndexOutOfBoundsException se indice < 0 oppure indice > n

protected void checkIndex(int index, int n) throws IndexOutOfBoundsException {

if (index < 0 || index > n)

throw new IndexOutOfBoundsException ("Líindice " +index+

" non Ë valido per questa sequenza.");

}

/**

* Metodo di servizio che controlla se la posizione Ë valida

* per questa sequenza e la converte in ArrayPosition in caso positivo.

* @param p la posizione da controllare

* @return la posizione convertita nel tipo ArrayPosition

* @throws InvalidPositionException se la posizione non Ë valida

protected ArrayPosition<E> checkPosition(Position<E> p)

throws InvalidPositionException {

if (p == null)

throw new InvalidPositionException("Posizione nulla.");

try {

ArrayPosition<E> pos = (ArrayPosition<E>) p;

return pos;

}

catch (ClassCastException e) {

throw new InvalidPositionException();

}

/**

* Restituisce la posizione dell'elemento con indice dato.

* @param index l'indice dell'elemento

* @return la posizione dell'elemento

* @throws BoundaryViolationException se fuori range

public Position<E> atIndex(int index) throws BoundaryViolationException {

checkIndex(index, size());

return S[map(index)];

}

/**

* Restituisce l'indice della posizione data.

* @param p la posizione dell'elemento

* @return l'indice dell'elemento

* @throws InvalidPositionException se la posizione non Ë valida

public int indexOf(Position<E> p) throws InvalidPositionException {

ArrayPosition<E> pos = checkPosition(p);

return pos.getIndex();

}

/**

* Metodo di servizio che raddoppia la capacit‡

* dell'array in caso non vi siano pi˘ posti liberi.

@SuppressWarnings("unchecked")

protected void raddoppia() {

// Numero di elementi nell'array prima di

// modificare il valore di capacity

int numElem = size();

int oldCap = capacity;

capacity *= 2;

ArrayPosition<E> S2[] = new ArrayPosition[capacity];

// Gli elementi vengono copiati nel nuovo array

// ponendo il first a partire da 0 e scorrendo il

// vecchio array dal first in poi

int i,j;

for (i=0,j=first; i<numElem; i++,j=(j+1)%oldCap)

S2[i] = S[j];

// Nuovo valore del first

first = 0;

// Nuovo valore del last

last = numElem;

S = S2;

}

/**

* Metodo di servizio che restituisce l'indice della posizione

* all'interno dell'array.

* @param index l'indice della posizione

* @return l'indice all'interno dell'array

protected int map(int index) {

return (first + index) % capacity;

}

/**

* Sposta l'elemento di posizione data all'inizio della sequenza

* lasciando inalterato l'ordine dei rimanenti elementi.

* @param p la posizione da spostare

public void makeFirst(Position<E> p) throws InvalidPositionException {

ArrayPosition<E> pos = checkPosition(p);

addFirst(remove(pos));

}

Strutture Dati - ArrayList e NodeList

noreply@blogger.com (Unknown) — Fri, 25 Mar 2011 10:43:00 +0000

Questo è il terzo post sulle Strutture Dati, in particolare oggi vedremo le Interfacce e le Implementazioni di TDA di tipo sequenza come ArrayList (si accede agli elementi attraverso il loro indice) e NodeList (dove il concetto principale e la Position). Raccomando la lettura di questo post agli studenti dell'Università degli studi di Salerno che studiano Informatica o Informatica Applicata e devono sostenere l'esame di Strutture Dati (SD) o di Laboratorio di Algoritmi e Strutture Dati (LASD) con il professor Salvatore La Torre. Invito i miei colleghi studenti a desistere dalla tentazione di presentarvi all'esame con i miei esercizi, (che per quanto io possa essere sicuro che siano corretti potrebbero comunque contenere errori) ma al massimo di usarli per confrontarli con i vostri.

Esercizi aggiornati al 8/04/2011

Codice per gli ArrayList

public interface IndexList <E>
extends Iterable<E>
{

public E get(int i) throws IndexOutOfBoundsException;

public E set(int i, E e) throws IndexOutOfBoundsException;

public void add(int i, E e) throws IndexOutOfBoundsException;

public E remove(int i) throws IndexOutOfBoundsException;

public int size();

public boolean isEmpty();
}

Implementare l’interfaccia IndexList utilizzando un array (classe ArrayIndexList)
􏰀􏰀 Scrivere un programma di test della classe ArrayIndexList
􏰀 Implementare l’interfaccia Queue mediante i metodi di IndexList (implementato dalla classe ArrayIndexList)

//ArrayIndexList implementato con array circolare estendibile
public class ArrayIndexList<E> implements IndexList<E>
{
private static final int CAPACITY = 1024;
private int size, capacity, f;
private E array[];

public ArrayIndexList()
{
this(CAPACITY);
}

public ArrayIndexList(int cap)
{
capacity = cap;
array = (E[])new Object[capacity];
size = 0;
}

public E get(int i) throws IndexOutOfBoundsException
{
checkIndex(i,size-1);
return array[map(i)];
}

public E set(int i, E e) throws IndexOutOfBoundsException
{
checkIndex(i,size-1);
E tmp = array[map(i)];
array[map(i)] = e;
return tmp;
}

public void add(int i, E e) throws IndexOutOfBoundsException
{
checkIndex(i,size);

if (size == capacity)
{
E nuovoArray[] = (E[]) new Object[capacity*2];
for(int j=0; j<size; j++)
nuovoArray[j] = array[map(j)];
array = nuovoArray;
capacity *= 2;
f = capacity-1;
}
if(i==0)
{
array[f] = e;
f = (f-1+capacity)%capacity;
}
if(i>0)
{
for(int j=size-1; j>= i; j--)
array[map(j+1)] = array[map(j)];
array[map(i)] = e;
}
size++;
}

public E remove(int i) throws IndexOutOfBoundsException
{
checkIndex(i,size-1);
E tmp = array[map(i)];
if(i == 0)
{
f = (f+1)%capacity;
}
else
{
for(int j=i; j<size-1; j++)
array[map(j)] = array[map(j+1)];
}
size--;

if (size<capacity/3)
{
E nuovoArray[] = (E[]) new Object[capacity/2];
for(int j=0; j<size; j++)
nuovoArray[j] = array[map(j)];
array = nuovoArray;
capacity /= 2;
f = capacity-1;
}

return tmp;
}

public int size()
{
return size;
}

public boolean isEmpty()
{
return (size == 0);
}

public String toString()
{
String stringa ="[ ";
for(int i=0;i<size;i++)
{
stringa += array[map(i)] + " ";
}
stringa += "] size:"+ size + " capacity:"+capacity+" f:"+f;
return stringa;
}
public int map(int i)
{
return (f+i+1)%capacity;
}

private void checkIndex(int i,int n)
{
if (i<0 || i>n)
throw new IndexOutOfBoundsException("errore indice "+i);
}
}

public class IndexListQueue<E> implements Queue<E>
{
private ArrayIndexList<E> coda;

public IndexListQueue()
{
coda = new ArrayIndexList<E>();
}

public int size()
{
return coda.size();
}

public boolean isEmpty()
{
return coda.isEmpty();
}

public E front() throws EmptyQueueException
{
if (isEmpty())
throw new EmptyQueueException();

return coda.get(0);
}

public void enqueue(E element)
{
coda.add(size(), element);
}

public E dequeue() throws EmptyQueueException
{
if (isEmpty())
throw new EmptyQueueException();

return coda.remove(0);
}

public String toString()
{
return "Queue with "+coda.toString();
}
}

Implementare l’interfaccia Deque mediante i metodi di IndexList (implementato dalla classe ArrayIndexList)
􏰀􏰀 Analizzare la complessità dei metodi di Deque con questa implementazione
􏰀 Modificare la classe ArrayIndexList in modo che i metodi addFirst e removeFirst di Deque abbiano tempo di esecuzione O(1)

public class IndexListDeque<E> implements Deque<E>
{
ArrayIndexList<E> dek;

public IndexListDeque()
{
dek = new ArrayIndexList<E>();
}

public int size()
{
return dek.size();
}

public boolean isEmpty()
{
return dek.isEmpty();
}

public E getFirst() throws EmptyDequeException
{
if(isEmpty())
throw new EmptyDequeException();

return dek.get(0);
}

public E getLast() throws EmptyDequeException
{
if(isEmpty())
throw new EmptyDequeException();

return dek.get(dek.size()-1);
}

public void addFirst(E element)
{
dek.add(0, element);
}

public void addLast(E element)
{
dek.add(dek.size()-1, element);
}

public E removeFirst() throws EmptyDequeException
{
if(isEmpty())
throw new EmptyDequeException();

return dek.remove(0);
}

public E removeLast() throws EmptyDequeException
{
if(isEmpty())
throw new EmptyDequeException();

return dek.remove(dek.size()-1);
}

public String toString()
{
return "Deque with " + dek.toString();
}

}

Codice su NodeList

public interface Position <E>
{
public E element();
}

public class DNode<E> implements Position<E>, Comparable<E>
{
private E element;
private DNode<E> prev, next;
private int idLista; //id Univoco della Lista

public DNode()
{
this(null,null,null);
}
public DNode(E e, DNode<E> p, DNode<E> n)
{
element = e;
prev = p;
next = n;
idLista = 0;
}
public DNode(E e, DNode<E> p, DNode<E> n, int idlist)
{
element = e;
prev = p;
next = n;
idLista = idlist;
}

public int getIdLista()
{
return idLista;
}
public void setIdLista(int id)
{
idLista = id;
}

public DNode<E> getPrev()
{
return prev;
}
public DNode<E> getNext()
{
return next;
}

//metodi modificatori
public void setElement(E e)
{
element = e;
}
public void setPrev(DNode<E> p)
{
prev = p;
}
public void setNext(DNode<E> n)
{
next = n;
}

public E element() {
return element;
}

public String toString()
{
return element.toString();
}

public int compareTo(E arg0)
{
Comparable<E> el = (Comparable<E>) element;
return el.compareTo(arg0);
}

}

public interface PositionList<E>
extends Iterable<E>
{

public Iterable <Position <E>> positions();

public int size();
public boolean isEmpty();

public Position <E> first() throws EmptyListException;

public Position <E> last() throws EmptyListException;

public Position <E> prev(Position <E> p) throws InvalidPositionException,
BoundaryViolationException;

public Position <E> next(Position <E> p) throws InvalidPositionException,
BoundaryViolationException;

public Position<E> addBefore(Position<E> p, E e) throws InvalidPositionException;

public Position<E> addAfter(Position<E> p, E e) throws InvalidPositionException;

public void addFirst(E e);

public void addLast(E e);

public E remove(Position<E> p) throws InvalidPositionException;

public E set (Position<E> p, E e) throws InvalidPositionException;
}

public class NodePositionList<E> implements PositionList<E>
{
private static int listsCounter = 0;
private int size;
protected DNode<E> header, trailer;

public NodePositionList()
{
listsCounter++;
size = 0;
header = new DNode<E>();
trailer = new DNode<E>(null,header,null);
header.setIdLista(listsCounter);
trailer.setIdLista(listsCounter);
}

public int size() {
return size;
}

public boolean isEmpty() {
return (size == 0);
}

public Position<E> first() throws EmptyListException
{
if (isEmpty())
throw new EmptyListException();

return header.getNext();
}

public Position<E> last() throws EmptyListException
{
if (isEmpty())
throw new EmptyListException();

return trailer.getPrev();
}

public Position<E> prev(Position<E> p) throws InvalidPositionException,
BoundaryViolationException
{
DNode<E> tmp = checkPosition(p);

if (tmp.getPrev() == header)
throw new BoundaryViolationException();

return tmp.getPrev();
}

public Position<E> next(Position<E> p) throws InvalidPositionException,
BoundaryViolationException
{
DNode<E> tmp = checkPosition(p);

if (tmp.getNext() == trailer)
throw new BoundaryViolationException();

return tmp.getNext();
}

public Position<E> addBefore(Position<E> p, E e) throws InvalidPositionException
{
DNode<E> tmp = checkPosition(p);
DNode<E> nuovoNodo = new DNode<E>(e,tmp.getPrev(),tmp,header.getIdLista());
tmp.getPrev().setNext(nuovoNodo);
tmp.setPrev(nuovoNodo);
size++;
return nuovoNodo;
}

public Position<E> addAfter(Position<E> p, E e) throws InvalidPositionException
{
DNode<E> tmp = checkPosition(p);
DNode<E> nuovoNodo = new DNode<E>(e,tmp,tmp.getNext(),header.getIdLista());
tmp.getNext().setPrev(nuovoNodo);
tmp.setNext(nuovoNodo);
size++;
return nuovoNodo;
}

public void addFirst(E e)
{
if (isEmpty())
{
DNode<E> nuovoNodo = new DNode<E>(e,header,trailer,header.getIdLista());
header.setNext(nuovoNodo);
trailer.setPrev(nuovoNodo);
size++;
}
else
{
DNode<E> tmp = header.getNext();
DNode<E> nuovoNodo = new DNode<E>(e,header,tmp,header.getIdLista());
tmp.setPrev(nuovoNodo);
header.setNext(nuovoNodo);
size++;
}

}

public void addLast(E e)
{
DNode<E> tmp = trailer.getPrev();
DNode<E> nuovoNodo = new DNode<E>(e,tmp,trailer,header.getIdLista());
tmp.setNext(nuovoNodo);
trailer.setPrev(nuovoNodo);
size++;
}

public E remove(Position<E> p) throws InvalidPositionException
{
DNode<E> tmp = checkPosition(p);
tmp.getPrev().setNext(tmp.getNext());
tmp.getNext().setPrev(tmp.getPrev());
size--;
return tmp.element();
}

public E set(Position<E> p, E e) throws InvalidPositionException
{
DNode<E> tmpnode = checkPosition(p);
E tmpEl = tmpnode.element();
tmpnode.setElement(e);
return tmpEl;
}

public DNode<E> checkPosition(Position<E> p) throws InvalidPositionException
{
if (p == null) throw new InvalidPositionException("null position");
if (p == header) throw new InvalidPositionException("header");
if (p == trailer) throw new InvalidPositionException("trailer");
try
{
DNode<E> temp = (DNode<E>) p;
// casting
if ((temp.getPrev() == null) || (temp.getNext() == null))
throw new InvalidPositionException("not in a NodeList");
if (temp.getIdLista() != header.getIdLista() || temp.getIdLista()==0)
throw new InvalidPositionException("Given position does not belong to NodeList "+header.getIdLista());
return temp;
}
catch (ClassCastException e)
{
throw new InvalidPositionException("not a DNode");
}
}

public String toString()
{
String stringa = "NodePositionlist id:"+ header.getIdLista() +" [ ";
DNode<E> aNode = header.getNext();
for(int i=0; i<size; i++)
{
stringa += aNode.element() + " ";
aNode = aNode.getNext();
}
stringa += "] size:"+size;
return stringa;
}

public PositionList<E> creaCopia()
{
NodePositionList<E> copia = new NodePositionList<E>();
DNode<E> oldNode = header.getNext();
for(int i=0; i<size(); i++)
{
copia.addLast(oldNode.element());
oldNode = oldNode.getNext();
}
return copia;
}

public Iterator<E> iterator()
{
/*
E[] tmp = (E[]) new Object[size];

DNode<E> aNode = header.getNext();
for(int i=0; i<size; i++)
{
tmp[i] = aNode.element();
aNode = aNode.getNext();
}
return new LinkedIterator<E>(tmp);*/

return new ElementIterator<E>(this);
}

public Iterable<Position<E>> positions()
{
PositionList<Position<E>> tmp = new NodePositionList<Position<E>>();

DNode<E> aNode = header.getNext();
for(int i=0; i<size-1; i++)
{
tmp.addLast(aNode);
aNode = aNode.getNext();
}
tmp.addLast(aNode);
return tmp;

}

/*Scrivere la funzione ricorsiva void reverse(PositionList<E> L)
che inverte la lista L.
Definizione ricorsiva di lista inversa di L=<e1,e2,...,en >
inversa(L)=L se n≤1
Inversa(L)= <en>+ inversa(<e1,...,en-1 >) se n>1
*/
//funzione ricorsiva versione 2
public void reverse(PositionList<E> L)
{
NodePositionList<E> lista = (NodePositionList<E>) L;
if (lista.size() > 1)
{
E tmp = lista.remove(lista.last());
lista.reverse(lista);
lista.addFirst(tmp);
}
}
/*
//funzione ricorsiva versione 1
public PositionList<E> reverse(PositionList<E> L)
{
NodePositionList<E> lista = (NodePositionList<E>) L;
if (lista.size() <= 1)
{
return lista;
}
else
{
E tmp = lista.remove(lista.last());
lista.reverse(lista).addFirst(tmp);
return lista;
}
}
*/
/*
//funzione non ricorsiva
public void reverse(PositionList<E> L)
{
ArrayStack<E> stack = new ArrayStack<E>();

while(!L.isEmpty())
stack.push(L.remove(L.first()));

while(!stack.isEmpty())
L.addLast(stack.pop());
}
*/
}

Esercizi Strutture Dati - Stack

noreply@blogger.com (Unknown) — Wed, 16 Mar 2011 14:41:00 +0000

Questo è il primo di una serie di posts utili agli studenti dell'Università degli studi di Salerno che studiano Informatica o Informatica Applicata e devono sostenere l'esame di Strutture Dati (SD) o di Laboratorio di Algoritmi e Strutture Dati (LASD) con il professor Salvatore La Torre.
Nel seguito di questo articolo, e in quelli successivi, ci saranno i miei esercizi svolti durante il corso; esercizi che rappresentano un requisito essenziale per superare l'esame. Ho deciso di postare il mio lavoro per mantenerne una copia online, e in modo che chiunque possa consultarlo a piacimento; Invito i miei colleghi studenti a desistere dalla tentazione di presentarvi all'esame con i miei esercizi, (che per quanto io possa essere sicuro che siano corretti potrebbero comunque contenere errori) ma al massimo di usarli per confrontarli con i vostri.

Di seguito elenco gli esercizi sulla prima parte del corso, aggiornati al 16/03/2011

Le Eccezioni

Le eccezioni sono tutte uguali quindi ne scrivo una soltanto:

public class EmptyStackException extends RuntimeException

{

private static final String DEFAULTMSG= "Stack Vuoto!";

public EmptyStackException()

{

this(DEFAULTMSG);

}

public EmptyStackException(String err)

{

super(err);

}

Esercizi sullo Stack

public interface Stack <E>

{

/**

* Controlla se lo stack è vuoto.

* @return true se lo stack è vuoto, false altrimenti

public boolean isEmpty();

/**

* Ottiene il valore in cima allo stack.

* @return l'elemento al top dello stack

* @throws EmptyStackException se invocato su uno stack vuoto

public E top() throws EmptyStackException;

/**

* Elimina un elemento dalla cima dello stack.

* @return l'elemento cancellato

* @throws EmptyStackException se invocato su uno stack vuoto

public E pop() throws EmptyStackException;

/**

* Inserisce un elemento in cima allo stack.

* @param e l'elemento da inserire

public void push(E o) throws FullStackException;

/**

* Da la dimensione dello stack.

* @return un int da 0 alla dimensione massima dello stack

public int size();

}

􏰀 Completare l’implementazione della classe generica ArrayStack

public class ArrayStack<E> implements Stack<E>

{

private E stack[];

private int size;

private int capacity;

public static final int CAPACITY = 1024;

public ArrayStack()

{

this(CAPACITY);

}

public ArrayStack(int cap)

{

capacity = cap;

stack = (E[])new Object[capacity];

size = 0;

}

public boolean isEmpty()

{

return (size == 0);

}

public E top() throws EmptyStackException

{

if (isEmpty())

throw new EmptyStackException("Stack Vuoto!");

else

return stack[size-1];

}

public E pop() throws EmptyStackException

{

if (isEmpty())

throw new EmptyStackException("Stack Vuoto!");

else

{

E o = stack[size-1];

stack[size-1] = null;

size--;

return o;

}

public void push(E o) throws FullStackException

{

if (size == capacity)

//throw new FullStackException("Stack Pieno!");

{

capacity = capacity*2;

E nuovoStack[] = (E[])new Object[capacity];

for(int i=0; i<size; i++)

{

nuovoStack[i]=stack[i];

}

stack = null;

stack = nuovoStack;

nuovoStack = null;

}

stack[size] = o;

size++;

}

public int size() {

return size;

}

public String toString()

{

String response = "ArrayStack Elements:[ ";

for (int i = 0; i<size; i++)

{

response += (stack[i]+" ");

}

response+= "] size:"+size()+" capacity: "+capacity;

return response;

}

Scrivere un metodo Java che usa uno stack per calcolare il reverse di una stringa

􏰁 Es. Il reverse di “laboratorio” è “oirotarobal”

import java.util.*;

public class StringReverse

{

/**

* uso uno stack per invertire una stringa

public static void main(String[] args)

{

ArrayStack<String> s = new ArrayStack<String>(5);

Scanner in = new Scanner(System.in);

System.out.print("Inserisci una riga: ");

String riga = in.nextLine();

String rigaInvertita ="";

for (int i=0; i< riga.length(); i++)

{

s.push(riga.charAt(i)+"");

}

while(!s.isEmpty())

{

rigaInvertita += s.pop();

}

System.out.println("La riga invertita è: "+rigaInvertita);

}

Scrivere un metodo che riceve in input una stringa contenente parentesi tonde e restituisce true se le parentesi sono ben accoppiate e false altrimenti.

􏰁 Esempio: 􏰀 x((abc)()) è un’espressione ben parentesizzata 􏰀􏰀(as(df)))( nonèun’espressionebenparentesizzata

􏰀 Modificare la funzione in modo che funzioni con stringhe contenenti sia parentesi tonde che parentesi quadre

􏰁 Esempio: 􏰀 x[(abc)()]([]) è un’espressione ben parentesizzata 􏰀 (as(df)]( non è un’espressione ben parentesizzata

import java.util.*;

public class ControlloParentesiTonde

{

public static void main(String[] args)

{

ArrayStack<String> s = new ArrayStack<String>(5);

Scanner in = new Scanner(System.in);

System.out.println("Verifica Annidamento Parentesi Tonde, Quadre e Graffe\n" +

"-----------------------------------------------------");

System.out.print("Scrivi l'espressione: ");

String riga = in.nextLine();

boolean correct = true;

for (int i=0; i< riga.length(); i++)

{

try

{

if (riga.charAt(i)=='(' || riga.charAt(i)=='[' || riga.charAt(i)=='{')

s.push(riga.charAt(i)+"");

if (riga.charAt(i)==')')

{

if (s.top().equals("("))

s.pop();

}

if (riga.charAt(i)==']')

{

if (s.top().equals("["))

s.pop();

}

if (riga.charAt(i)=='}')

{

if (s.top().equals("{"))

s.pop();

}

catch(EmptyStackException e)

{

correct = false;

break;

}

if (correct && s.isEmpty())

System.out.println("Allineamento parentesi corretto");

else

System.out.println("Allineamento parentesi ERRATO");

}

Parte 2: Esercizi di Strutture Dati su Code e Deque

Le Meduse del Mediterraneo

noreply@blogger.com (Unknown) — Mon, 19 Jul 2010 10:47:00 +0000

Ecco le immagini e le caratteristiche peculiari di ogni specie di medusa presente nel nostro mar Mediterraneo.

Purtroppo negli ultimi 10 anni il mar Mediterraneo ha subito un progressivo riscaldamento tuttora in corso. Questo aumento della temperatura ha reso le nostre acque molto simili a quelle Tropicali, rendendole sempre più adatte ad ospitare nuove specie che prima non riuscivano a viverci. Vediamo quindi di anno in anno un prolificarsi sempre maggiore di specie nuove per i nostri mari, tra cui anche le "antipatiche" meduse, che nonostante vivano bene anche in acque fredde, non disprezzano assolutamente le acque calde, che amplificano le condizioni ideali per la prolificazione e favoriranno anche l'inserimento di specie che preferiscono temperature più alte. Quindi per il futuro ci si aspetta di veder crescere sempre più il numero e la diversità biologica di queste bombe gelatinose urticanti. Questo è il motivo per cui ho deciso di fare un piccolo riassunto con caratteristiche e foto di ogni specie che potremmo incontrare durante le nostre vacanze estive.

La Pelagia

Questa è una delle tipologie più comuni di medusa da sempre presente nel Mediterraneo, ha un ombrello di colore marrone-rosato o rosa-violetto di circa 10 cm. di diametro, traslucido, composto da 16 lobi da cui partono 8 tentacoli retrattili semi-trasparenti e urticanti, che partono dai bordi e possono arrivare a lunghezze anche di 10 metri. I tentacoli orali, dello stesso colore dell'ombrello, sono lunghi invece 30 cm. Si nutre di plancton e piccoli pesci che cattura con i tentacoli urticanti.

La Aurelia

Questo tipo di medusa è diffusa notevolmente in tutto il pianeta, anche se non massicciamente nel Mediterraneo, e nonostante sia considerata innocua possiede dei sottili e corti tentacoli urticanti che scendono dal bordo dell'ombrello e negli esemplari adulti si possono notare anche 4 tentacoli più spessi che partono dal centro dell'ombrello. Viene facilmente riconosciuta dal suo ombrello di forma sferica color bianco/trasparente, e dalle caratteristiche 4 gonadi tonde sulla sua sommità, che sembrano disegnare la forma di un quadrifoglio. Probabilmente è considerata poco pericolosa proprio per la scarsa lunghezza dei suoi tentacoli che consentono di limitare i rischi semplicemente standone alla larga.

La Physalia Physalis

Questa è quella che vi auguro di non incontrare, La Physalia Physalis detta Caravella Portoghese, è spesso confusa per una medusa, ma in realtà si tratta di una colonia di 4 tipi diversi di polipi, che dipendono l'un l'altro per la sopravvivenza. La Physalia Physalis è composta da una sacca galleggiante di circa 15 cm. a cui sono attaccati dei tentacoli lunghi fino a 30 metri fortemente urticanti. La parte emersa è di colore azzurro violacea e a volte tende al fucsia. Galleggia sospinta dal vento ad un'angolazione che dipende dalla parte emersa e dalla resistenza della parte sommersa. Ha più di 10 tipi di veleni diversi sui suoi tentacoli, ognuno caratterizzato da un suo proprio colore, non sono conosciuti ancora rimedi per alcuni tipi dei suoi veleni. I tentacoli di questo pericoloso animale possono provocare la paralisi e persino la morte per arresto cardiaco, e una semplice puntura può essere molto dolorosa.

La Mnemiopsis leidyi

Finalmente vi presento una medusa che non è pericolosa per l'uomo in quanto non punge. Il suo corpo è composto al 97% di acqua, ha forma ovale, colore trasparente, e lungo il corpo, verticalmente ha quattro file di pettini cigliati che emettono colori luminescenti blu-verdi se disturbati. Possono raggiungere dai 7 ai 12 cm. di lunghezza e 2,5 cm. di diametro. Si nutrono principalmente di plankton e uova o larve di pesci.

Cosa fare se venite punti da una medusa?

Ecco una serie di rimedi al fastidioso bruciore:

I più previdenti potranno uscire dall'acqua e spalmare immediatamente sulla zona urticata una pomata a base di ammoniaca, funzionano egregiamente anche le pomate after-bite per punture di insetti;
Strofinare la zona urticata con della sabbia bollente;
In casi estremi in cui siete sprovvisti di una pomata e non c'è sabbia intorno a voi, potrete ricorrere al più vecchio rimedio che è l'urina.

Tunatic, lo Shazam gratuito per Mac e Pc

noreply@blogger.com (Unknown) — Sun, 18 Jul 2010 22:57:00 +0000

Finalmente ho trovato una versione del famoso software Shazam gratuita per Windows e Mac. Per chi non avesse mai sentito parlare di questo programma, è un utilissimo software spuntato originariamente su iPhone che permette di reperire il Titolo e l'Autore di una canzone da un database online, semplicemente ascoltandola.

Hai Mai pensato, "Che canzone è questa?" Lasciala ascoltare a Tunatic e avrai in pochi secondi il titolo e il nome dell'artista. Tunatic è come un motore di ricerca basato su suoni. Tutto ciò di cui avrai bisogno per farlo funzionare è un microfono e un accesso ad internet. Il suo funzionameno è semplicissimo, cliccando sul pulsante di ricerca di Tunatic, il programma si collegherà ad un server, al quale invierà le caratteristiche della canzone ascoltata, il server cercherà nel suo database, restituendo le informazioni della canzone. Niente di più semplice in un programmino che pesa meno di 1Mb.

Scarica Tunatic per Windows
Tunatic 1.0.1b per Mac

Guida Objective-C in Italiano - C++ e Objective-C - Parte 15

noreply@blogger.com (Unknown) — Sun, 16 May 2010 21:19:00 +0000

Eccoci finalmente all'ultima parte della Guida all'Objective-C. L'argomento trattato oggi è l'uso di C++ e Objective-C.

Questo post è una traduzione in italiano della Guida all'Objective C, presente sul sito developer.apple.com a questo link. L'Objective C è il linguaggio di programmazione per creare applicazioni per iPhone. Questa guida potrebbe interessare a tutti gli sviluppatori che vogliono imparare le basi di questo linguaggio che è il fondamento per programmare nuove applicazioni per Mac Os X, iPhone ed iPad.

Usare C++ Con Objective-C

Il compilatore Objective-C di Apple ti permette di mixare liberamente C++ e Objective-C nello stesso file sorgente. Questo linguaggio ibrido Objective-C/C++ è chiamato Objective-C++. Con esso puoi fare uso di librerie C++ esistenti dalle tue applicazioni Objective-C.

Mixare Caratteristiche di Linguaggio Objective-C e C++

In Objective-C++, puoi chiamare metodi da l'uno o l'altro linguaggio, nel codice C++ e nei metodi Objective-C. I puntatori ad oggetti in uno o l'altro linguaggio sono solo puntatori, e come tali possono essere usati ovunque. Ad esempio, puoi includere puntatori a oggetti Objective-C come membri dati di classi C++, e puoi includere puntatori ad oggetti C++ come variabili di istanza di classi Objective-C.
Il listato 14-1 illustra questo.

Nota: Xcode richiede che i nomi dei files abbiano un'estensione ".mm" per le estensioni Objective-C++ per poter essere abilitate dal compilatore.

Listato 14-1 Usare C++ ed istanze Objective-C come variabili di istanza

/* Hello.mm

* Compila con: g++ -x objective-c++ -framework Foundation Hello.mm -o hello

*/

#import

class Hello {

private:

id greeting_text; // Contiene una NSString

public:

Hello() {

greeting_text = @"Hello, world!";

}

Hello(const char* initial_greeting_text) {

greeting_text = [[NSString alloc] initWithUTF8String:initial_greeting_text];

}

void say_hello() {

printf("%s\n", [greeting_text UTF8String]);

}

};

@interface Greeting : NSObject {

@private

Hello *hello;

}

- (id)init;

- (void)dealloc;

- (void)sayGreeting;

- (void)sayGreeting:(Hello*)greeting;

@end

@implementation Greeting

- (id)init {

if (self = [super init]) {

hello = new Hello();

}

return self;

}

- (void)dealloc {

delete hello;

[super dealloc];

}

- (void)sayGreeting {

hello->say_hello();

}

- (void)sayGreeting:(Hello*)greeting {

greeting->say_hello();

}

@end

int main() {

NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

Greeting *greeting = [[Greeting alloc] init];

[greeting sayGreeting]; // > Hello, world!

Hello *hello = new Hello("Bonjour, monde!");

[greeting sayGreeting:hello]; // > Bonjour, monde!

delete hello;

[greeting release];

[pool release];

return 0;

}

Come puoi dichiarare strutture C in interfacce Objective-C, puoi anche dichiarare classi C++ in interfacce Objective-C. Come con le strutture C, le classi C++ definite dentro un'interfaccia Objective-C hanno uno scope globale, non annidato entro la classe Objective-C. (ciò è coerente con il modo in cui standard C (sebbene non C++) promuova le definizioni di strutture nidificate allo scope del file).

Per permettervi di condizionare il vostro codice basato su una variante del linguaggio, il compilatore Objective-C++ definisce entrambe le costanti di preprocessore __clusplus e __OBJC__, come specificato dagli standards dei linguaggi C++ e Objective-C rispettivamente.

Come detto precedentemente, Objective-C++ non permette di ereditare classi C++ dagli oggetti Objective-C, nè permette di ereditare classi Objective-C da oggetti C++.

class Base { /* ... */ };

@interface ObjCClass: Base ... @end // ERROR!

class Derived: public ObjCClass ... // ERROR!

Diversamente dall'Objective-C, gli oggetti in C++ sono tipati staticamente, con polimorfismo a runtime disponibile come caso eccezionale. I modelli oggetto dei due linguaggi sono quindi non direttamente compatibili. Più fondamentalmente, il layout degli oggetti Obj-C e C++ in memoria è mutuamente incompatibile, ciò significa che generalmente è impossibile creare un'istanza di un oggetto che sarebbe valida dalla prospettiva di entrambi i linguaggi. Quindi, i due tipi di gerarchia non possono essere intercambiati.

Puoi dichiarare una classe C++ dentro una dichiarazione di calsse Objective-C. Il compilatore tratta queste classi come se fossero state dichiarate nel namespace globale, come segue:

@interface Foo {

class Bar { ... } // OK

}

@end

Bar *barPtr; // OK

Objective-C permette di usare strutture C (sia se dichiarate dentro una dichiarazione Objective-C sia se non dichiarate) come variabili di istanza.

@interface Foo {

struct CStruct { ... };

struct CStruct bigIvar; // OK

} ... @end

Su Mac OS X 10.4 e successivi, se imposti il flag del compilatore fobjc-call-cxx-cdtors, puoi usare istanze di classi C++ che contengono funzioni virtuali e costruttori non banali e decostruttori come variabili di istanza.( il flag fobjc-call-cxx-cdtors è impostato di default in gcc-4.2.) I Costruttori sono invocati nel metodo alloc (specificamente, dentro class_createInstance), in ordine di dichiarazione immediatamente dopo che l'oggetto di cui sono membri è allocato. Il costruttore usato è il "costruttore pubblico senza argomenti". I distruttori sono invocati nl metodo dealloc (specificamente, dentro object_dispose), in ordine inverso della dichiarazione immediatamente prima che l'oggetto di cui sono membri è deallocato.

Mac OS X v10.3 e precedenti: Le seguenti precauzioni si applicano solo a Mac OS X v10.3 e precedenti.

Objective-C++ in modo simile si sforza di permettere a istanze di classi C++ di servire come variabili di istanza. Questo è possibile fintanto che la classe C+ in questione non ha funzioni membro virtuali definite. Se qualunque funzione membro virtuale fosse presente, la classe C++ potrebbe non servire come una variabile d'istanza Objective-C.

#import

struct Class0 { void foo(); };

struct Class1 { virtual void foo(); };

struct Class2 { Class2(int i, int j); };

@interface Foo : NSObject {

Class0 class0; // OK

Class1 class1; // ERROR!

Class1 *ptr; // OK—call 'ptr = new Class1()' from Foo's init,

// 'delete ptr' from Foo's dealloc

Class2 class2; // WARNING - constructor not called!

...

@end

C++ richiede che ogni istanza di una classe che contiene funzioni virtuali contenga un puntatore adatto nella tavola delle funzioni virtuali. Comunque, il runtime dell'Objective-C non può inizializzare il puntatore della tavola delle funzioni virtuali, perchè non è familiare con il modello degli oggetti C++. In modo analogo, il runtime di Objective-C non può spedire chiamate a costruttori C++ o decostruttori per quegli oggetti. Se una classe C++ ha qualsiasi costruttore definito da utente o distruttore, essi non sono chiamati. Il compilatore emette un warning in tali casi.

Objective-C non ha una nozione di nasmespaces annidati. Non puoi dichiarare classi Objective-C dentro namespaces C++, nè puoi dichiarare namespaces dentro classi Objective-C.

Classi Objective-C, protocolli, e categorie non possono essere dichiarati dentro un template C++, nè un template C++ può essere dichiarato nello scope di un'interfaccia, protocollo o categoria Objective-C.

Comunque, classi Objective-C potrebbero servire come parametri di template C++. Parametri dei template di C++ possono anche essere usati come riceventi o parametri (comunque non come selettori) in espressioni di messaggi Objective-C.

C++ Ambiguità Lessicali e Conflitti

Ci sono pochi identificatori che sono definiti nei files header Objective-C che ogni programma Objective-C deve includere. Questi identificatori sono id, Class, SEL, IMP, e BOOL.
In un metodo Objective-C, Il compilatore pre-dichiara gli identificatori self e super, in modo simile alla parola chiave this in C++. Comunque, diversamente dalla parola chiave this in C++, self e super sono context-sensitive (sensibili al contesto); potrebbero essere usati come identificatori ordinari fuori ai metodi Objective-C.

Nella lista dei parametri dei metodi dentro un protocollo, ci sono altre cinque parole chiave context-sensitive (oneway, in, out, inout, and bycopy). Queste non sono parole chiavi in altri contesti.

Dal punto di vista di un programmatore Objective-C, C++ aggiunge parecchie nuove parole chiavi. Puoi usare ancora le parole chiavi C++ come parte di un selettore Objective-C, così l'impatto non è troppo severo, ma non puoi usarle per nominare classi Objective-C o variabili di istanza. Ad esempio, anche se class è una parola chiave C++, puoi ancora usare il metodo class: di NSObject.

[foo class]; // OK

Comunque, dato che è una parola chiave, non puoi usare class come il nome di una variabile:

NSObject *class; // Error

In Objective-C, i nomi per le classi e le categorie vivono in namespaces diversi. Che è, entrambi @interface foo e @interface(foo) possono esistere nello stesso codice sorgente. In Objective-C++, puoi anche avere una categoria i cui nomi combaciano con una classe o struttura C++.
Gli specificatori di protocollo e template usano la stessa sintassi per scopi diversi:

id foo;

TemplateType bar;

Per evitare quest'ambiguità, il compilatore non permette che id venga usato come nome di template.

Infine, c'è un'ambiguità lessicale in C++ quando un'etichetta è seguita da un'espressione che menziona un nome globale, come in:

label: ::global_name = 3;

Lo spazio dopo i primi due punti è richiesto. Objective-C++ aggiunge un caso simile, il quale richiede anch'esso uno spazio:

receiver selector: ::global_c++_name;

Limitazioni

Objective-C++ non aggiunge caratteristiche di C++ alle classi Objective-C, né aggiunge caratteristiche Objective-C a classi C++. Ad esempio, non puoi usare la sintassi Objective-C per chiamare un oggetto C++, non puoi aggiungere costruttori o distruttori per un oggetto Objective-C, e non puoi usare le parole chiave this e self intercambiabilmente. Le gerarchie di classi sono separate; una classe C++ non può ereditare da una classe Objective-C, e una classe Objective-C non può ereditare da una classe C++. Inoltre la gestione delle eccezioni multi-language non è supportata. Cioè, un'eccezione lanciata in codice Objective-C non può essere catturata nel codice C++, e un'eccezione lanciata nel codice C++ non può essere catturata nel codice Objective-C. Per più informazioni sulle eccezioni in Objective-C, consultate "Gestione delle Eccezioni".

Guida Objective-C in Italiano - Messaggi Remoti - Parte 14

noreply@blogger.com (Unknown) — Thu, 06 May 2010 14:44:00 +0000

Eccoci alla penultima parte della Guida in Italiano alla programmazione in Objective-C, la quattordicesima per l'esattezza, nella quale parleremo di un'importante argomento che è il Remote Messaging.

Questo post è una traduzione in italiano della Guida all'Objective C, presente sul sito developer.apple.com a questo link. L'Objective C è il linguaggio di programmazione per creare applicazioni per iPhone. Questo articolo può interessare a tutti gli sviluppatori che vogliono imparare le basi di questo linguaggio che è il fondamento per programmare nuove applicazioni per Mac Os X, iPhone ed iPad.

Remote Messaging

Come la maggior parte degli altri linguaggi di programmazione, l'Objective-C è stato inizialmente progettato per programmi che sono eseguiti come un singolo processo in un singolo spazio di indirizzi.

Tuttavia, il modello OO, dove la comunicazione prende posto tra unità relativamente auto-convenute attraverso messaggi che sono risolti a runtime, sembrerebbe ben adatto anche per la comunicazione tra processi. Non è difficile immaginare messaggi Objective-C tra oggetti che risiedono in diversi spazi di indirizzi (differenti compiti) o in diversi threads di esecuzione dello stesso compito.

Per esempio, in una tipica interazione server-client, il compito del client potrebbe inviare le sue richieste ad un oggetto designato nel server, ed il server potrebbe mirare a specifici oggetti del client per le notifiche ed altre informazioni che invia. O immaginate un'applicazione interattiva che ha bisogno di fare molti calcoli per effettuare un comando dell'utente. Potrebbe semplicemente mostrare un dialogo che dice che l'utente deve aspettare mentre è occupata, o potrebbe isolare il lavoro di processo in compiti subordinati, lasciando la parte principale dell'applicazione libera di accettare input dall'utente. Gli oggetti nei due compiti, comunicherebbero attraverso messaggi Objective-C.

Oggetti Distribuiti

I messaggi remoti in Objective-C richiedono un sistema di runtime che possa stabilire connessioni tra oggetti in diversi spazi di indirizzi, riconoscere quando un messaggio è inteso per un oggetto in uno spazio di indirizzi remoto, e trasferire i dati da uno spazio di indirizzi ad un altro. Deve anche mediare tra i programmi (schedules) separati dei due compiti; deve mantenere i messaggi finché i loro riceventi remoti siano liberi di rispondergli.

Cocoa include un'architettura ad oggetti distribuiti che è essenziale per questo tipo di estensioni del sistema di runtime. Usando gli oggetti distribuiti, puoi inviare messaggi Objective-C ad oggetti in altre attività o avere messaggi eseguiti in altri threads della stessa attività. (Quando i messaggi remoti sono inviati tra due threads della stessa attività, i threads sono trattati esattamente come threads di attività diverse). Nota che il sistema di oggetti distribuiti di Cocoa è costruito in cima al sistema di runtime; non altera il comportamento fondamentale dei tuoi oggetti Cocoa.

Per inviare un messaggio remoto, un'applicazione deve prima stabilire una connessione con il ricevente remoto. Stabilire la connessione da all'applicazione un proxy per l'oggetto remoto nel suo proprio spazio di indirizzi. Esso allora comunica con l'oggetto remoto attraverso il proxy. Il proxy assume l'identità dell'oggetto remoto; non ha identità di suo. L'applicazione è in grado di riguardare il proxy come se fosse l'oggetto remoto; Per la maggior parte degli scopi, è l'oggetto remoto.

Inviare messaggi remoti è illustrato in figura 13-1, dove l'oggetto A comunica con l'oggetto B attraverso un proxy, e i messaggi per B aspettano in una coda finché B è pronto a rispondergli.

Figura 13-1 Messaggi Remoti

Il mittente e il ricevente sono in attività differenti e sono programmate (scheduled) indipendentemente l'una dall'altra. Quindi non c'è garanzia che il ricevente sia libero di accettare un messaggio quando il mittente è pronto ad inviarlo. Quindi, i messaggi che arrivano sono posti in una coda e recuperati alla convenienza dell'applicazione ricevente.

Un proxy non agisce per conto dell'oggetto remoto o deve accedere alla sua classe. Non è una copia dell'oggetto ma un leggero sostituto per esso. In un certo senso, è trasparente; semplicemente passa i messaggi che riceve al ricevente remoto e gestisce la comunicazione tra i processi. La sua funzione principale è fornire un indirizzo locale per un oggetto che altrimenti non ne avrebbe uno. Un proxy non è totalmente trasparente. Per istanza, un proxy non ti permette di impostare e ottenere direttamente le variabili di istanza di un oggetto.

Un ricevente remoto è tipicamente anonimo. La sua classe è nascosta dentro l'applicazione remota. L'applicazione mittente non ha bisogno di conoscere come è progettata l'applicazione o che classi usa. Non ha bisogno di usare le stesse classi. Tutto ciò che gli serve sapere è a quali messaggi l'oggetto remoto risponde.

A causa di ciò, un oggetto che è designato per ricevere messaggi remoti, annuncia la sua interfaccia in un protocollo formale. Entrambe le applicazioni mittente e ricevente, dichiarano il protocollo - entrambe importano la stessa dichiarazione di protocollo. L'applicazione ricevente lo dichiara perché l'oggetto remoto deve aderire al protocollo. L'applicazione mittente lo dichiara per informare il compilatore dei messaggi che invia e per questo, potrebbe usare il metodo conformsToProtocol: e la direttiva @protocol() per testare il ricevente remoto. L'applicazione mittente non deve implementare alcuno dei metodi del protocollo; essa dichiara il protocollo solo perché il protocollo inizia i messaggi al ricevente remoto.

Language Support

I messaggi remoti emettono non solo molte intriganti possibilità per la progettazione di programmi, emettono anche alcuni interessanti problemi per il linguaggio. La maggior parte dei problemi sono collegati all'efficienza dei messaggi remoti e al grado di separazione che due attività dovrebbero mantenere mentre comunicano l'un l'altra.

Quindi quei programmatori possono dare istruzioni esplicite a riguardo l'intento di usare messaggi remoti, l'Objective-C definisce sei qualificatori di tipo che possono essere usati dichiarando metodi in un protocollo formale:

oneway
in
out
inout
bycopy
byref

Questi modificatori sono ristretti a protocolli formali; non possono essere usati in una dichiarazione di classe o di categoria. Comunque se una classe o una categoria adottano un protocollo, la sua implementazione dei metodi del protocollo può usare gli stessi modificatori che sono usati per dichiarare i metodi. La sezione seguente spiegherà come sono usati questi modificatori.

Messaggi Sincroni e Asincroni

Considerate prima un metodo con solo un semplice valore di ritorno:

- (BOOL)canDance;

Quando un messaggio canDance è inviato ad un ricevente nella stessa applicazione, il metodo è invocato ed il valore di ritorno fornito direttamente al mittente. Ma quando il ricevente è in un'applicazione remota, sono richiesti due messaggi di fondo - uno per ottenere l'oggetto remoto per invocare il metodo, e l'altro messaggio per inviare indietro il risultato del calcolo remoto. Questo è illustrato nella figura sotto:

Figura 13-2 Messaggio Round-Trip

La maggior parte dei messaggi remoti, sono alla base, chiamate a procedure remote bi direzionali (o round-trip) come questo. L'applicazione mittente aspetta l'applicazione ricevente per invocare il metodo, completa la sua elaborazione, e invia indietro un'indicazione che ha finito, insieme con qualunque informazione di ritorno richiesta. Aspettando che il ricevente finisca, anche se non è restituita alcuna informazione, ha il vantaggio di coordinare le due applicazioni comunicanti, di tenerle entrambe "in sync". Per questo motivo, i messaggi round-trip sono spesso chiamati sincroni. I messaggi sono sincroni di default.

Comunque, non è sempre necessario o non è sempre una buona idea aspettare una risposta. A volte è sufficiente spedire i messaggi remoti e ritornare, permettendo al ricevente di ottenere la sua attività quando può. Nel frattempo, il mittente può andare avanti su altre cose. L'Objective-C fornisce un modificatore di tipo di ritorno, oneway, per indicare che un metodo è usato solo per messaggi asincroni:

- (oneway void)waltzAtWill;

Anche se oneway è un qualificatore di tipo (come const) e può essere usato in combinazione con un nome di tipo specifico, come oneway float o oneway id, l'unica combinazione che ha senso è oneway void. Un messaggio asincrono non può avere un valore di ritorno valido.

Argomenti Puntatore

Consideriamo metodi che prendono argomenti puntatore. Un puntatore può essere usato per passare informazioni al ricevente tramite riferimento. Quando invocato, il metodo guarda a cosa è memorizzato nell'indirizzo passato.

- setTune:(struct tune *)aSong

{

tune = *aSong;
...

}

Lo stesso tipo di argomento può essere usato anche per restituire informazioni tramite riferimento. Il metodo usa il puntatore per trovare dove potrebbe mettere le informazioni richieste nel messaggio.

- getTune:(struct tune *)theSong
{
...
*theSong = tune;
}

Il modo in cui è usato il puntatore crea una differenza in come il messaggio remoto è effettuato. In nessun caso il puntatore può semplicemente essere passato senza cambi all'oggetto remoto; esso punta a una locazione di memoria nello spazio di indirizzi del mittente e non sarebbe significativa nello spazio di indirizzi del ricevente remoto. Il sistema di runtime per i messaggi remoti deve fare alcune regolazioni dietro le scene.

Se l'argomento è usato per passare informazioni per riferimento, il sistema di runtime deve dereferenziare il puntatore, spedire il valore a cui esso punta all'applicazione remota, memorizzare il valore in un indirizzo locale di quell'applicazione e passare l'indirizzo al ricevente remoto.

Se d'altra parte, il puntatore è usato per restituire informazioni per riferimento, il valore a cui punta non deve essere inviato all'altra applicazione. Invece, un valore dall'altra applicazione deve essere rispedito indietro e scritto nella locazione indicata dal puntatore.

Nel primo caso, l'informazione è passata sulla prima "gamba" del round trip. Nel secondo caso, l'informazione è restituita sulla seconda "gamba" del round trip. Poiché questi casi risultano in molte azioni diverse sulla parte del sistema di runtime per i messaggi remoti, l'Objective-C fornisce modificatori di tipo che chiarificano le intenzioni del programmatore:

Il modificatore di tipo "in" indica che l'informazione è stata passata in un messaggio:

- setTune:(in struct tune *)aSong;
Il modificatore "out" indica che un argomento è stato usato per restituire informazione per riferimento:

- getTune:(out struct tune *)theSong;
Un terzo modificatore, "inout", indica che un argomento è usato sia per fornire informazioni sia per ri-ottenerle:

- adjustTune:(inout struct tune *)aSong;

Il Sistema di oggetti distribuiti di Cocoa prende "inout" come modificatore di default per tutti gli argomenti puntatori tranne quelli dichiarati const, per i quali il default è "in". "inout" è l'assunzione più sicura ma anche quella che consuma più tempo dato che richiede il passaggio di informazioni in entrambe le direzioni. Il solo modificatore che ha senso per gli argomenti passati per valore (non puntatori) è "in". Mentre "in" può essere usato con qualunque tipo di argomento, "out" e "inout" hanno senso solo per i puntatori.

In C, i puntatori sono a volte usati per rappresentare valori compisiti. Per esempio, una stringa è rappresentata come un puntatore a carattere (char *). Sebbene nella notazione e implementazione c'è un livello di indirezione qui, nel concetto non c'è. Concettualmente, una stringa è un'entità di per se, non un puntatore a qualcos'altro. In casi come questi, il sistema di oggetti distribuiti dereferenzia automaticamente il puntatore e passa qualsiasi cosa puntata, per valore. Quindi, i modificatori "out" ed "inout" non hanno senso con semplici puntatori a carattere. Ci vuole un livello aggiuntivo di indirezione in un messaggio remoto per passare o restituire una stringa per riferimento:

- getTuneTitle:(out char **)theTitle;

è vero lo stesso per gli oggetti:

- adjustRectangle:(inout Rectangle **)theRect;

Queste convinzioni sono applicate a runtime, non dal compilatore.

Proxies e Copie

Finalmente, consideriamo un metodo che prende un oggetto come argomento:

- danceWith:(id)aPartner;

Un messaggio danceWith: passa un id di un oggetto al ricevente. Se il mittente ed il ricevente sono nella stessa applicazione, entrambi sarebbero in grado di riferirsi allo stesso oggetto aPartner.

Questo è vero anche se il ricevente è in un'applicazione remota, tranne se il ricevente ha bisogno di riferirsi all'oggetto attraverso un proxy (dato che l'oggetto non è nel suo spazio di indirizzi). Il puntatore che danceWith: consegna ad un ricevente remoto è di fatto un puntatore al proxy. I messaggi inviati al proxy sarebbero passati attraverso la connessione all'oggetto reale e qualsiasi informazione di ritorno sarebbe passata indietro all'applicazione remota.

Ci sono volte, quando i proxies potrebbero essere inutilmente inefficienti, quando è meglio inviare una copia dell'oggetto ad un processo remoto così che esso possa interagirvi direttamente nel suo proprio spazio di indirizzi. Per dare ai programmatori un modo per indicare che questo è inteso, l'Objective-C fornisce un modificatore di tipo bycopy:

- danceWith:(bycopy id)aClone;

bycopy può essere usato anche per i valori di ritorno:

- (bycopy)dancer;

Può essere usato in modo simile con "out" per indicare che un oggetto restituito per riferimento dovrebbe essere copiato piuttosto che consegnato nella forma di un proxy:

- getDancer:(bycopy out id *)theDancer;

<b>Nota:</b> Quando una copia di un oggetto è passata ad un'altra applicazione, non può essere anonimo. L'applicazione che riceve l'oggetto deve avere la classe dell'oggetto caricata nel suo spazio di indirizzi.

bycopy ha molto più senso per certe classi - classi che contengono una collezione di altri oggetti - spesso queste classi sono scritte in modo che una copia è inviata ad un ricevente remoto, invece del solito riferimento. Puoi sovrascrivere questo comportamento tramite byref, comunque, quindi specificando che gli oggetti passati ad un metodo o gli oggetti restituiti da un metodo dovrebbero essere passati o restituiti per riferimento. Dato che passare per riferimento è il comportamento di default per la grande maggioranza degli oggetti Objective-C, farete raramente uso della parola chiave byref.

L'unico tipo che ha senso modificare per bycopy o byrefè un oggetto, se tipato dinamicamente id o tipato staticamente da un nome di classe.

Sebbene bycopy e byref non possono essere usati in una dichiarazione di classe o categoria, possono essere usati in un protocollo formale. Ad esempio, potresti scrivere un protocollo formale foo come segue:

@Protocol foo

- (bycopy)array;

@end

Una classe o categoria può allora adottare il tuo protocollo foo. Questo ti permette di costruire protocolli in modo che forniscano suggerimenti su come gli oggetti dovrebbero essere passati e restituiti dai metodi descritti dal protocollo.

Fine Parte 14

Finisce qui il quattordicesimo articolo di questa Guida dedicato al Threading. Il prossimo, sarà l'ultimo, e parlerà dell'uso di codice C++ con Objective-C; quindi come utilizzare librerie C++ nelle vostre applicazioni Objective-C.

Segnalatemi eventuali errori, o commentate l'articolo se l'avete trovato utile. Iscrivetevi ai feed del blog per essere sempre aggiornati automaticamente ogni volta che saranno disponibili nuovi contenuti. Nella barra laterale del blog potete trovare l'elenco di tutti gli articoli di questa guida.

Guida Objective-C in Italiano - I Threads - Parte 13

noreply@blogger.com (Unknown) — Wed, 05 May 2010 12:06:00 +0000

Siamo giunti alla tredicesima parte della Guida in Italiano alla programmazione in Objective-C, oggi parleremo brevemente dei Threads.

Questo post è una traduzione in italiano della Guida all'Objective C, presente sul sito developer.apple.com a questo link. L'Objective C è il linguaggio di programmazione per creare applicazioni per iPhone. Questo articolo può interessare a tutti gli sviluppatori che vogliono imparare le basi di questo linguaggio che è il fondamento per programmare nuove applicazioni per Mac Os X, iPhone ed iPad.

Threading

L'Objective-C fornisce supporto per la sincronizzazione dei thread e la gestione delle eccezioni. Per attivare il supporto per queste caratteristiche, usate l'interruttore -fobjc-exceptions di GNU Compiler Collection (GCC) versione 3.3 e successive.

Nota: Usando l'una o l'altra di queste caratteristiche in un programma, rende l'applicazione eseguibile solo in Mac OS X v10.3 e successivi poichè il supporto di runtime per la gestione delle eccezioni e la sincronizzazione non sono presenti in versioni precedenti del software.

Sincronizzare l'esecuzione dei Thread

L'Objective-C supportail multithreading nelle applicazioni. Questo vuol dire che i threads possono provare a modificare lo stesso oggetto allo stesso tempo, una situazione che può causare seri problemi in un programma. Per proteggere sezioni di codice dall'essere eseguite da più di un thread alla volta, l'Objective-C fornisce la direttiva @synchronized().

La direttiva @synchronized()chiude una sezione di codice per l'uso da un singolo thread. Gli altri threads sono bloccati finchè il thread esce dal codice protetto; che è, quando l'esecuzione continua dopo l'ultimo statement del blocco @synchronized().

La direttiva @sinchronized prende come suoi soli argomenti qualunque oggetto Objective-C incluso self. Quest'oggetto è conosciuto come semaforo di esclusione reciproca o mutex. Esso permette ad un thread di bloccare una sezione di codice per prevenirne l'uso da altri threads. Dovresti separare i semafori per proteggere diverse sezioni critiche di un programma. è più sicuro creare tutti oggetti mutuamente esclusivi prima che l'applicazione diventi multithreaded per evitare condizioni di competizione.

Il listato 12-1 mostra un esempio di codice che usa self come il mutex per sincronizzare l'accesso a metodi di istanza dell'oggetto corrente. Puoi prendere un approccio simile per sincronizzare i metodi di classe della classe associata, usando l'oggetto Class al posto di self. Nell'ultimo caso, ovviamente, solo un thread alla volta può eseguire un metodo di classe perchè c'è solo un oggetto di classe che è condiviso da tutti i chiamanti.

Listato 12-1 Bloccare un metodo usando self

- (void)criticalMethod

{

@synchronized(self) {

// Critical code.

...

}

}

Il listato 12-2 mostra un approccio generale. Prima di eseguire un processo critico, il codice ottiene un semaforo dalla classe Account e lo usa per chiudere sezioni critiche. La classe Account potrebbe creare il semaforo nel suo metodo initialize.

Listato 12-2 Bloccare un metodo usando un semaforo personalizzato

Account *account = [Account accountFromString:[accountField stringValue]];

// Get the semaphore.

id accountSemaphore = [Account semaphore];

@synchronized(accountSemaphore) {

// Critical code.

...

}

La caratteristica di sincronizzazione dell'Objective-C supporta codice ricorsivo e rientrante. Un thread può usare un singolo semaforo molte volte, in una maniera ricorsiva; altri threads sono bloccati dall'uso del semaforo finché il thread rilascia tutte le parti di codice bloccate ottenute da lui; che sarebbe, quando ogni blocco @synchronized() termina normalmente o tramite un'eccezione.

Quando il codice in un blocco @synchronized() lancia un'eccezione, il runtime cattura l'eccezione, rilascia il semaforo (così che il codice protetto possa essere eseguito da altri threads), e ri-lancia l'eccezione al prossimo gestore di eventi.

Fine Parte 13

Finisce qui il tredicesimo articolo di questa Guida dedicato al Threading. Siamo ormai quasi alla fine, e il prossimo post tratterà i messaggi remoti.

Segnalatemi eventuali errori, o commentate l'articolo se l'avete trovato utile, anche per incentivarmi a continuare a pubblicare le mie traduzioni. Iscrivetevi ai feed del blog per essere sempre aggiornati automaticamente ogni volta che sono disponibili nuovi contenuti.
Nella barra laterale del blog potete trovare l'elenco di tutti gli articoli di questa guida.

Esercizi Strutture Dati - Queue e Deque

noreply@blogger.com (Unknown) — Tue, 04 May 2010 08:49:00 +0000

Ecco la seconda parte degli esercizi di Strutture Dati (SD) di Laboratorio di Algoritmi e Strutture Dati (LASD) con il professor Salvatore La Torre. Nel seguito di questo articolo ci saranno le strutture dati Queue (Coda) e Deque (Double ended Queue).

Esercizi su Queue

public interface Queue<E>

{

/**

* Restituisce il numero di elementi presenti nella coda.

* @return un int da 0 alla lunghezza max della coda.

public int size();

/**

* Controlla se la coda è vuota.

* @return true, se la coda è vuota, false altrimenti.

public boolean isEmpty();

/**

* Accede all'elemento sul front della coda.

* @return l'elemento al front della coda.

* @throws EmptyQueueException se invocato su una coda vuota.

public E front() throws EmptyQueueException;

/**

* Inserisce un elemento nel rear della coda.

* @param element l'elemento da inserire.

public void enqueue (E element);

/**

* Rimuove l'elemento sul front della coda.

* @return l'elemento rimosso.

* @throws EmptyQueueException se invocato su una coda vuota.

public E dequeue()throws EmptyQueueException;

}

Implementare l’interfaccia Queue (scrivere la classe ArrayQueue) usando un array di lunghezza fissata 􏰁􏰁 public static final int CAPACITY = 1024;

􏰀 Implementare Queue in modo che la coda piena invece della FullQueueException causa un aumento della taglia della coda

public class ArrayQueue<E> implements Queue<E>

{

public static final int CAPACITY = 1024;

private int f,r,capacity,size;

private E coda[];

public ArrayQueue()

{

this(CAPACITY);

}

public ArrayQueue(int cap)

{

capacity = cap;

f=r=size=0;

coda = (E[])new Object[capacity];

}

@Override

public int size() {

return size;

}

@Override

public boolean isEmpty() {

return (f==r);

}

@Override

public E front() throws EmptyQueueException

{

if (isEmpty())

throw new EmptyQueueException("Coda Vuota!");

return coda[f];

}

@Override

public void enqueue(E element)

{

if (size == capacity-1)

{

E nuovaCoda[] = (E[])new Object[capacity*2];

for(int i=0; i<size; i++)

{

nuovaCoda[i]=coda[(f+i)%capacity];

}

f=0;

r=size;

capacity *=2;

coda = null;

coda = nuovaCoda;

nuovaCoda = null;

}

coda[r] = element;

r = (r+1)%capacity;

size++;

}

@Override

public E dequeue() throws EmptyQueueException

{

if (isEmpty())

throw new EmptyQueueException("Coda Vuota!");

E tmp = coda[f];

coda[f] = null;

f = (f+1)%capacity;

size--;

return tmp;

}

public String toString()

{

String response = "ArrayQueue Elements:[ ";

for (int i = 0; i<size; i++)

{

response += ((i+1)+"°"+coda[(f+i)% capacity]+" ");

}

response+= "] size:"+size()+" capacity: "+capacity;

return response;

}

public E extract(int k) throws NotEnoughElements

{

if (size() < k+1)

throw new NotEnoughElements("La Coda non contiene abbastanza elementi!");

return coda[(f+k)%capacity];

}

Scrivere un programma che testi la vostra implementazione di Queue invocandone tutti i metodi

public class ArrayQueueTest

{

public static void main(String[] args)

{

ArrayQueue<String> coda = new ArrayQueue<String>(2);

//QueueWithDeque<String> coda = new QueueWithDeque<String>();

//LinkedQueue<String> coda = new LinkedQueue<String>();

coda.enqueue("Marco");

System.out.println(coda);

coda.enqueue("Rosaria");

System.out.println(coda);

coda.enqueue("Francesco");

System.out.println(coda);

coda.enqueue("Pippo");

System.out.println(coda);

coda.dequeue();

System.out.println(coda);

coda.enqueue("Giuseppe");

System.out.println(coda);

System.out.println("Front: "+coda.front());

//System.out.println("3° elem dal front: "+coda.extract(3));

coda.dequeue();

System.out.println(coda);

coda.dequeue();

System.out.println(coda);

coda.dequeue();

System.out.println(coda);

coda.dequeue();

System.out.println(coda);

}

Esercizi su Deque

public interface Deque<E>

{

/**

* Restituisce il numero di elementi contenuti.

* @return un valore intero >= 0

public int size();

/**

* Verifica se il deque è vuoto.

* @return true se è vuoto, false altrimenti.

public boolean isEmpty();

/**

* Restituisce il primo elemento del Deque.

* @throws EmptyDequeException se invocato su Deque vuoto.

public E getFirst() throws EmptyDequeException;

/**

* Restituisce l'ultimo elemento del Deque.

* @throws EmptyDequeException se invocato su Deque vuoto.

public E getLast() throws EmptyDequeException;

/**

* Aggiunge un nuovo elemento all'inizio del Deque.

* @param element il nuovo elemento da inserire.

public void addFirst (E element);

/**

* Aggiunge un nuovo elemento alla fine del Deque.

* @param element il nuovo elemento da inserire.

public void addLast (E element);

/**

* Rimuove e restituisce il primo elemento del Deque.

* @throws EmptyDequeException se invocato su Deque vuoto.

public E removeFirst() throws EmptyDequeException;

/**

* Rimuove e restituisce l'ultimo elemento del Deque.

* @throws EmptyDequeException se invocato su Deque vuoto.

public E removeLast() throws EmptyDequeException;

}

Per implementare il TDA Deque usiamo una lista doppiamente concatenata

public class DLNode<E>

{

private E element;

private DLNode<E> prev, next;

public DLNode()

{

this(null,null,null);

}

public DLNode(E e, DLNode<E> p, DLNode<E> n)

{

element = e;

prev = p;

next = n;

}

//metodi accessori

public E getElement()

{

return element;

}

public DLNode<E> getPrev()

{

return prev;

}

public DLNode<E> getNext()

{

return next;

}

//metodi modificatori

public void setElement(E e)

{

element = e;

}

public void setPrev(DLNode<E> p)

{

prev = p;

}

public void setNext(DLNode<E> n)

{

next = n;

}

Implementare il TDA Deque (class MyDeque) con lista doppiamente concatenata

public class MyDeque<E> implements Deque<E>

{

private int size;

private DLNode<E> header, trailer;

public MyDeque()

{

header = new DLNode<E>();

trailer = new DLNode<E>();

header.setNext(trailer);

trailer.setPrev(header);

size = 0;

}

@Override

public int size()

{

return size;

}

@Override

public boolean isEmpty()

{

return (size == 0);

}

@Override

public E getFirst() throws EmptyDequeException

{

if (isEmpty())

throw new EmptyDequeException("Deck Vuoto!");

return header.getNext().getElement();

}

@Override

public E getLast() throws EmptyDequeException

{

if (isEmpty())

throw new EmptyDequeException("Deck Vuoto!");

return trailer.getPrev().getElement();

}

@Override

public void addFirst(E element)

{

DLNode<E> newNode = new DLNode<E>(element,header,header.getNext());

header.getNext().setPrev(newNode);

header.setNext(newNode);

size++;

}

@Override

public void addLast(E element)

{

DLNode<E> newNode = new DLNode<E>(element,trailer.getPrev(),trailer);

trailer.getPrev().setNext(newNode);

trailer.setPrev(newNode);

size++;

}

@Override

public E removeFirst() throws EmptyDequeException

{

if (isEmpty())

throw new EmptyDequeException("Deck Vuoto! - Rimozione primo elem Impossibile");

E tmp = header.getNext().getElement();

header.setNext(header.getNext().getNext());

header.getNext().setPrev(header);

size--;

return tmp;

}

@Override

public E removeLast() throws EmptyDequeException

{

if (isEmpty())

throw new EmptyDequeException("Deck Vuoto! - Rimozione ultimo elem Impossibile");

E tmp = trailer.getPrev().getElement();

trailer.setPrev(trailer.getPrev().getPrev());

trailer.getPrev().setNext(trailer);

size--;

return tmp;

}

public String toString()

{

String risp = "Deque Elements: [ ";

DLNode<E> nodo = header.getNext();

for (int i=0; i<size; i++ )

{

risp+= (i+1)+"°"+nodo.getElement() + " ";

nodo = nodo.getNext();

}

risp+= "] size: "+size;

return risp;

}

Usare Deque per implementare Stack e Queue

public class StackWithDeque<E> implements Stack<E>

{

private MyDeque<E> contenitore;

public StackWithDeque()

{

contenitore = new MyDeque<E>();

}

@Override

public boolean isEmpty()

{

return contenitore.isEmpty();

}

@Override

public E top() throws EmptyStackException

{

E tmp = null;

try

{

tmp = contenitore.getLast();

}

catch (EmptyDequeException e)

{

throw new EmptyStackException();

}

return tmp;

}

@Override

public E pop() throws EmptyStackException

{

E tmp = null;

try

{

tmp = contenitore.removeLast();

}

catch (EmptyDequeException e)

{

throw new EmptyStackException();

}

return tmp;

}

@Override

public void push(E o) throws FullStackException

{

contenitore.addLast(o);

}

@Override

public int size()

{

return contenitore.size();

}

public String toString()

{

return(contenitore.toString());

}

public class QueueWithDeque<E> implements Queue<E>

{

private MyDeque<E> contenitore;

public QueueWithDeque()

{

contenitore = new MyDeque<E>();

}

@Override

public int size()

{

return contenitore.size();

}

@Override

public boolean isEmpty()

{

return contenitore.isEmpty();

}

@Override

public E front() throws EmptyQueueException

{

E tmp = null;

try

{

tmp = contenitore.getFirst();

}

catch(EmptyDequeException e)

{

throw new EmptyQueueException();

}

return tmp;

}

@Override

public void enqueue(E element)

{

contenitore.addLast(element);

}

@Override

public E dequeue() throws EmptyQueueException

{

E tmp = null;

try

{

tmp = contenitore.removeFirst();

}

catch(EmptyDequeException e)

{

throw new EmptyQueueException();

}

return tmp;

}

public String toString()

{

return "Queue with "+contenitore.toString();

}

Implementareilconcettodilistaconcatenatacome classe Java LinkedList

public class Node<E>

{

private E element;

private Node<E> next;

public Node()

{

this(null,null);

}

public Node(E e, Node<E> n)

{

element = e;

next = n;

}

public E getElement()

{

return element;

}

public Node<E> getNext()

{

return next;

}

public void setElement(E e)

{

element = e;

}

public void setNext(Node<E> n)

{

next = n;

}

public class LinkedList<E>

{

private Node<E> head, tail;

private int size;

public LinkedList()

{

tail = new Node<E>();

head = tail;

size = 0;

}

/**

* Restituisce il numero di elementi contenuti nella lista.

* @return un valore intero >= 0

public int size()

{

return size;

}

/**

* Verifica se la lista è vuota.

* @return true se è vuota, false altrimenti.

public boolean isEmpty()

{

return (size == 0);

}

/**

* Aggiunge un nuovo elemento all'inizio della lista.

* @param e il nuovo elemento da inserire.

public void addFirst(E e)

{

if (size == 0)

head.setElement(e);

else

{

Node<E> newNode = new Node<E>(e,head);

head = newNode;

}

size++;

}

/**

* Aggiunge un nuovo elemento alla fine della lista.

* @param e il nuovo elemento da inserire.

public void addLast(E e)

{

if (size == 0)

tail.setElement(e);

else

{

Node<E> newNode = new Node<E>(e,null);

tail.setNext(newNode);

tail = newNode;

}

size++;

}

/**

* Rimuove e restituisce il primo elemento dalla lista.

* @throws EmptyLinkedListException se invocato sulla lista vuota.

public E removeFirst() throws EmptyLinkedListException

{

if (isEmpty())

throw new EmptyLinkedListException("Lista Vuota!");

E tmp = null;

if (size == 1)

{

tmp = head.getElement();

head.setElement(null);

}

else

{

tmp = head.getElement();

head = head.getNext();

}

size--;

return tmp;

}

/**

* Rimuove e restituisce l'ultimo elemento della lista.

* @throws EmptyLinkedListException se invocato su lista vuota.

public E removeLast() throws EmptyLinkedListException

{

if (isEmpty())

throw new EmptyLinkedListException();

E tmp = null;

if(size == 1)

{

tmp = tail.getElement();

tail.setElement(null);

size--;

}

else

{

Node<E> nodo = head;

for(int i=0; i<size-1; i++)

{

if (nodo.getNext().getNext() == null)

{

tmp = nodo.getNext().getElement();

nodo.setNext(null);

tail = nodo;

size--;

}

else

{

nodo = nodo.getNext();

}

return tmp;

}

/**

* Restituisce il primo elemento della lista.

* @throws EmptyLinkedListException se invocato su lista vuota.

public E getFirst() throws EmptyLinkedListException

{

if (isEmpty())

throw new EmptyLinkedListException();

return head.getElement();

}

/**

* Restituisce l'ultimo elemento della lista.

* @throws EmptyLinkedListException se invocato su lista vuota.

public E getLast() throws EmptyLinkedListException

{

if (isEmpty())

throw new EmptyLinkedListException("Lista Vuota!");

return tail.getElement();

}

public String toString()

{

String stringa = "LinkedList Elements: [ ";

Node<E> nodo = head;

for(int i=0; i<size; i++)

{

stringa += nodo.getElement()+" ";

nodo = nodo.getNext();

}

stringa += "] size: "+size;

return stringa;

}

ImplementareilTDAStackconlistaconcatenata

􏰁 Definire classe LinkedStack

public class LinkedStack<E> implements Stack<E>

{

private LinkedList<E> contenitore;

public LinkedStack()

{

contenitore = new LinkedList<E>();

}

@Override

public boolean isEmpty()

{

return contenitore.isEmpty();

}

@Override

public E top() throws EmptyStackException

{

E tmp = null;

try

{

tmp = contenitore.getLast();

}

catch (EmptyLinkedListException e)

{

throw new EmptyStackException();

}

return tmp;

}

@Override

public E pop() throws EmptyStackException

{

E tmp = null;

try

{

tmp = contenitore.removeLast();

}

catch (EmptyLinkedListException e)

{

throw new EmptyStackException();

}

return tmp;

}

@Override

public void push(E o) throws FullStackException

{

contenitore.addLast(o);

}

@Override

public int size()

{

return contenitore.size();

}

public String toString()

{

return contenitore.toString();

}

ImplementareilTDAQueueconlistaconcatenata

􏰁 Definire classe LinkedQueue

public class LinkedQueue<E> implements Queue<E>

{

private LinkedList<E> contenitore;

public LinkedQueue()

{

contenitore = new LinkedList<E>();

}

@Override

public int size() {

return contenitore.size();

}

@Override

public boolean isEmpty() {

return contenitore.isEmpty();

}

@Override

public E front() throws EmptyQueueException

{

E tmp = null;

try

{

tmp = contenitore.getFirst();

}

catch(EmptyLinkedListException e)

{

throw new EmptyQueueException();

}

return tmp;

}

@Override

public void enqueue(E element) {

contenitore.addLast(element);

}

@Override

public E dequeue() throws EmptyQueueException

{

E tmp = null;

try

{

tmp = contenitore.removeFirst();

}

catch(EmptyLinkedListException e)

{

throw new EmptyQueueException();

}

return tmp;

}

public String toString()

{

return "QUEUE with "+contenitore.toString();

}

􏰀 ImplementareilTDADequeconlisteconcatenate

public class LinkedDeque<E> implements Deque<E>

{

private LinkedList<E> lista;

@Override

public int size() {

return lista.size();

}

@Override

public boolean isEmpty() {

return lista.isEmpty();

}

@Override

public E getFirst() throws EmptyDequeException {

E tmp = null;

try

{

tmp = lista.getFirst();

}

catch (EmptyLinkedListException e)

{

throw new EmptyDequeException();

}

return tmp;

}

@Override

public E getLast() throws EmptyDequeException {

E tmp = null;

try

{

tmp = lista.getLast();

}

catch (EmptyLinkedListException e)

{

throw new EmptyDequeException();

}

return tmp; }

@Override

public void addFirst(E element) {

lista.addFirst(element);

}

@Override

public void addLast(E element) {

lista.addLast(element);

}

@Override

public E removeFirst() throws EmptyDequeException {

E tmp = null;

try

{

tmp = lista.removeFirst();

}

catch (EmptyLinkedListException e)

{

throw new EmptyDequeException();

}

return tmp;

}

@Override

public E removeLast() throws EmptyDequeException

{

E tmp = null;

try

{

tmp = lista.removeLast();

}

catch (EmptyLinkedListException e)

{

throw new EmptyDequeException();

}

return tmp;

}

Guida Objective-C in Italiano - Le Eccezioni - Parte 12

noreply@blogger.com (Unknown) — Tue, 04 May 2010 00:35:00 +0000

Siamo giunti alla dodicesima parte della Guida in Italiano alla programmazione in Objective-C, oggi parleremo della Gestione delle Eccezioni. Vi ricordo che potrete trovare tutti i links agli articoli di questa guida nella barra laterale del sito.

Questo post è una traduzione in italiano della Guida all'Objective C, presente sul sito developer.apple.com a questo link. L'Objective C è il linguaggio di programmazione per creare applicazioni per iPhone. Questo articolo può interessare a tutti gli sviluppatori che vogliono imparare le basi di questo linguaggio che è il fondamento per programmare nuove applicazioni per Mac Os X, iPhone ed iPad.

Gestione delle Eccezioni

Il linguaggio Objective-C ha una sintassi per la gestione delle eccezioni simile a quella dei linguaggi Java and C++. Accoppiata con l'uso di NSException, NSError, o classi personalizzate, puoi aggiungere una robusta gestione degli errori per i tuoi programmi. Questo articolo fornisce un sommario della sintassi delle eccezioni e la loro gestione.

Abilitare la gestione delle Eccezioni

Usando gcc versione 3.3 e successive, Objective-C fornisce un supporto per la gestione delle eccezioni. Per attivare il supporto per queste caratteristiche usa l'interruttore -fobjc-exceptions del GNU Compiler Collection (GCC) versione 3.3 e successivo. (Nota che questo rende l'applicazione eseguibile solo su Mac OS X v10.3 e successivi poiché il supporto di runtime per la gestione delle eccezioni e la sincronizzazione non è presente in versioni precedenti del software).

Gestione Eccezioni

Un'eccezione è una condizione speciale che interrompe il normale flusso d'esecuzione del programma. Ci sono una varietà di motivi per cui un'eccezione potrebbe essere generata dall'hardware così come dal software. Esempi includono errori aritmetici come divisioni per zero, uderflow o overflow, chiamate a istruzioni indefinite, e tentare di accedere ad una collezione di elementi fuori dai suoi limiti.

Il supporto delle eccezioni Objective-C gira attorno a quattro direttive di compilazione: @try, @catch, @throw, e @finally:

Il codice che può lanciare potenzialmente un'eccezione è racchiuso in un blocco @try.
Un blocco @catch() contiene la gestione logica delle eccezioni per le eccezioni lanciate in un blocco @try. Puoi avere blocchi @catch() multipli per catturare diversi tipi di eccezioni.
Un blocco @finally contiene codice che deve essere eseguito se un'eccezione è o non è lanciata.
Usi la direttiva @throw per lanciare un'eccezione, che è essenzialmente un'oggetto Objective-C. Tipicamente usi un'oggetto NSException, ma non è richiesto.

L'esempio sotto descrive un semplice algoritmo di gestione delle eccezioni:

Cup *cup = [[Cup alloc] init];

@try {
   [cup fill];
}

@catch (NSException *exception) {
   NSLog(@"main: Caught %@: %@", [exception name], [exception reason]);
}

@finally {
   [cup release];
}

Catturare Tipi Diversi di Eccezioni

Per catturare un'eccezione lanciata in un blocco @try, usa uno o più blocchi @catch() subito dopo il blocco @try. I blocchi @catch() dovrebbero essere ordinati dal più specifico al meno specifico. In questo modo potete adattare il processo di eccezioni come gruppi, come mostrato nel listato 11-1.

Listato 11-1 Un gestore di eccezioni

@try {
   ...
}

@catch (CustomException *ce) { // 1
   ...
}

@catch (NSException *ne) { // 2
   // si eseguono le elaborazioni necessarie a questo livello.
   ...
}

@catch (id ue) {
   ...
}

@finally { // 3
   // si eseguono le elaborazini necessarie se è occorsa o meno un'eccezione
   ...
}

La lista seguente descrive le linee di codice numerate:

Cattura il tipo di eccezione più specifica.
Cattura un tipo di eccezione più generico.
Esegue ogni elaborazione che deve essere eseguita se un'eccezione è lanciata o meno.

Lanciare Eccezioni

Per lanciare un'eccezione devi istanziare un oggetto con l'informazione appropriata, come il nome dell'eccezione e il motivo per cui è stata lanciata.

NSException *exception = [NSException exceptionWithName:@"HotTeaException"
reason:@"The tea is too hot" userInfo:nil];

@throw exception;

Importante: In molti ambienti, usare eccezioni è ragionevolmente ordinario. Ad esempio, potresti lanciare un'eccezione per segnalare che una routine potrebbe non eseguirsi normalmente - come quando un file manca o i dati non possono essere analizzati correttamente. Le eccezioni consumano intensivamente risorse in Objective-C. Non dovresti usare eccezioni per controlli generali del flusso, o semplicemente per significare errori. Invece dovresti usare i valori di ritorno di un metodo o di una funzione per indicare che è occorso un errore, e fornire informazioni riguardo il problema in un oggetto errore.

In un blocco @catch(), puoi re-lanciare l'eccezione catturata usando la direttiva @throw senza un argomento. Questo può aiutare a rendere il codice più leggibile.

Non sei limitato a lanciare oggetti NSException. Puoi lanciare qualsiasi oggetto Objective-C come un oggetto eccezione. La classe NSException fornisce i metodi che aiutano l'elaborazione dell'eccezione, ma puoi implementare la tua propria classe se vuoi. Puoi anche creare una sottoclasse di NSEdception per implementare tipi di eccezioni, come le eccezioni di file system o eccezioni di comunicazione.

Fine Parte 12

Finisce qui il dodicesimo articolo di questa Guida dedicato alla gestione delle eccezioni nel linguaggio di programmazione Objective-C. Il prossimo post di questa guida, parlerà brevemente del Threading.

Segnalatemi eventuali errori, e commentate l'articolo se l'avete trovato utile, anche per incentivarmi a continuare a pubblicare le mie traduzioni. Iscrivetevi ai feed del blog per essere sempre aggiornati automaticamente ogni volta che sono disponibili nuovi contenuti. Nella barra laterale del blog potete trovare l'elenco di tutti gli articoli di questa guida.

Guida Objective-C in Italiano - Selettori - Parte 11

noreply@blogger.com (Unknown) — Mon, 03 May 2010 10:20:00 +0000

Oggi parleremo dei Selettori del linguaggio Objective-C; vi ricordo che questa è l'undicesima parte della Guida in Italiano alla programmazione in Objective-C, e che nella barra laterale del sito potrete trovare tutti i links agli articoli di questa guida.

Questo post è una traduzione in italiano della Guida all'Objective C, presente sul sito developer.apple.com a questo link. L'Objective C è il linguaggio di programmazione per creare applicazioni per iPhone. Questo articolo può interessare a tutti gli sviluppatori che vogliono imparare le basi di questo linguaggio che è il fondamento per programmare nuove applicazioni per Mac Os X, iPhone ed iPad.

Selettori

In Objective-C, la parola selettore ha due significati. Può essere usata per riferirsi semplicemente al nome di un metodo quando è usato in un messaggio ad un oggetto nel codice sorgente. Si può anche riferire all'identificatore univoco che rimpiazza il nome quando il codice sorgente è compilato. i selettori compilati sono di tipo SEL. Tutti i metodi con lo stesso nome hanno lo stesso selettore. Puoi usare un selettore per invocare un metodo su un oggetto - questo fornisce le basi per l'implementazione del pattern di progettazione target-azione in Cocoa.

Metodi e Selettori

Per efficienza, i nomi full ASCII non sono usati come selettori di metodo nel codice compilato. Invece, il compilatore scrive ogni nome di metodo in una tabella e poi accoppia il nome con un identificatore univoco che rappresenta il metodo a runtime. Il sistema di runtime si assicura che ogni identificatore sia univoco: non ci sono due selettori che sono uguali, e tutti i metodi con lo stesso nome hanno lo stesso selettore.

SEL e @selector

I selettori compilati sono assegnati a un tipo speciale, SEL, per distinguerli dagli altri dati. I selettori validi non sono mai 0. Devi permettere al sistema di assegnare identificatori SEL ai metodi; è futile assegnarli arbitrariamente.

La direttiva @selector() ti permette di riferirti ai selettori compilati, piuttosto che al completo nome del metodo. Qui, il selettore per setWidth:height: è assegnato alla variabile setWidthHeight:

SEL setWidthHeight;

setWidthHeight = @selector(setWidth:height:);

è più efficiente assegnare valori a variabili SEL a tempo di compilazione con la direttiva @selector(). Comunque, in alcuni casi, potresti aver bisogno di convertire una stringa di caratteri ad un selettore a runtime. Puoi farlo con la funzione NSSelectorFromString:

setWidthHeight = NSSelectorFromString(aBuffer);

Le conversioni sono possibili anche nella direzione opposta. La funzione NSStringFromSelector restituisce un nome di metodo per un selettore:

NSString *method;

method = NSStringFromSelector(setWidthHeight);

Metodi e Selettori

Selettori compilati identificano nomi di metodi, non implementazioni di metodi. Il metodo display per una classe, ad esempio, ha lo stesso selettore di un metodo display definito nelle altre classi. Questo è essenziale per il polimorfismo e il collegamento dinamico; permette di inviare lo stesso messaggio a riceventi appartenenti a classi diverse. Se ci fosse un selettore per ogni implementazione di metodo, un messaggio non sarebbe differente da una chiamata di funzione.

Un metodo di classe e un metodo di istanza con lo stesso nome sono assegnati allo stesso selettore. Comunque, a causa dei loro domini separati, non c'è confusione tra i due. Una classe potrebbe definire un metodo di classe display in aggiunta al metodo d'istanza display.

Valori di Ritorno e Tipi di Argomenti dei Metodi

La routine di messaggistica ha accesso alle implementazioni dei metodi solo attraverso i selettori, quindi li tratta allo stesso modo tutti i metodi con lo stesso selettore. Scopre i tipi restituiti di un metodo, e i tipi di dati dei suoi argomenti, dal selettore. Quindi, eccetto per messaggi inviati a riceventi tipati staticamente, il collegamento dinamico richiede che tutte le implementazioni dei metodi con lo stesso nome debbano avere lo stesso valore di ritorno e tipi di argomenti. (riceventi staticamente tipati sono un eccezione a questa regola, dato che il compilatore può imparare l'implementazione del metodo dal tipo della classe).

Sebbene i metodi di classe con lo stesso nome e i metodi di istanze siano rappresentati dallo stesso selettore, possono avere argomenti diversi e tipi di ritorno diversi.

Variare il Messaggio a Runtime

I metodi performSelector:, performSelector:withObject:, e performSelector:withObject:withObject:, definiti nel protocollo NSObject, prendono gli identificatori SEL come loro argomenti iniziali. Tutti e tre i metodi mappano direttamente nella funzione di messaggistica. Per esempio:

[friend performSelector:@selector(gossipAbout:)

withObject:aNeighbor];

è equivalente a:

[friend gossipAbout:aNeighbor];

Questi metodi rendono possibile variare un messaggio a runtime, come è possibile variare l'oggetto che riceve il messaggio. I nomi di variabili possono essere usati in entrambe le metà di un'espressione di un messaggio:

id helper = getTheReceiver();

SEL request = getTheSelector();

[helper performSelector:request];

In questo esempio, il ricevente (helper) è scelto a runtime ( dalla funzione fittizia getTheReceiver), e il metodo che il ricevente è chiesto di eseguire (request) è anch'esso determinato a runtime (dalla funzione ugualmente fittizia getTheSelector).

Nota: performSelector: e i suoi metodi compagni restituiscono un id. Se il metodo che è eseguito restituisce un tipo diverso, dovrebbe essere fatto un cast al tipo appropriato. (comunque, fare il cast non funziona per tutti i tipi; il metodo dovrebbe restituire un puntatore o un tipo compatibile con un puntatore).

Il Design Pattern Target-Azione

Nel suo trattamento di controlli di interfacce utente, l'Application Kit fa buon uso dell'abilità di variare sia ricevente che messaggio.

Oggetti NSControl sono graficamente dispositivi che possono essere usati per dare istruzioni ad un'applicazione. La maggior parte somigliano a dispositivi di controllo del mondo reale come bottoni, interruttori, campi di testo, menu ecc... Nel software questi dispositivi si trovano tra applicazione e utente. Essi interpretano gli eventi che vengono dai dispositivi hardware come la tastiera ed il mouse e li traducono in istruzioni specifiche per l'applicazione. Per esempio, un pulsante etichettato "Find" tradurrebbe un click del mouse in un'istruzione per l'applicazione per iniziare a cercare qualcosa.

L'Application Kit definisce un modello per creare dispositivi di controllo e di suo, definisce pochi dispositivi immediatamente disponibili. Ad esempio, la classe NSButtonCell definisce un oggetto che puoi assegnare ad un'istanza di NSMatrix ed inizializzare con una taglia, un'etichetta, un'immagine, un carattere, e una tastiera alternativa. Quando l'utente clicca sul pulsante (o usa la tastiera alternativa), l'oggetto NSButtonCell invia un messaggio che istruisce l'applicazione a fare qualcosa. Per fare questo, un oggetto NSButtonCell deve essere inizializzato non solo con un'immagine, dimensione ed etichetta ma con direzioni su che messaggio inviare e a chi inviarlo. Di conseguenza un'istanza di NSButtonCell può essere inizializzata per un messaggio d'azione, il selettore del metodo che dovrebbe usare nel messaggio che invia, ed il target, l'oggetto che dovrebbe ricevere il messaggio.

[myButtonCell setAction:@selector(reapTheWind:)];

[myButtonCell setTarget:anObject];

Il pulsante cella invia il messaggio usando il metodo performSelector:withObject: di NSObject. Tutti i messaggi d'azione prendono un singolo argomento, l'id del dispositivo di controllo che invia il messaggio.

Se Objective-C non permettesse ai messaggi di essere variati, tutti gli oggetti NSButtonCell dovrebbero inviare lo stesso messaggio; il nome del metodo dovrebbe essere congelato nel codice sorgente di NSButtonCell. Invece di implementare semplicemente un meccanismo per traslare le azioni dell'utente in messaggi d'azione, i pulsanti celle e altri controlli dovrebbero vincolare il contenuto del messaggio. Questo renderebbe difficile per qualunque oggetto rispondere a più di un button cell. Ci dovrebbe anche essere un unico target per un pulsante, o l'oggetto target dovrebbe scoprire da quale bottone viene il messaggio e agire di conseguenza.

Ogni volta che riorganizzi l'interfaccia utente, dovresti anche re-implementare il metodo che risponde al messaggio azione. Questa sarebbe una complicazione non necessaria che l'Objective-C evita felicemente.

Evitare Errori nei Messaggi

Se un oggetto riceve un messaggio per eseguire un metodo che non è nel suo repertorio, risulterà un errore. è la stessa sorta di errore di chiamare una funzione non esistente. Ma poiché i messaggi occorrono a runtime, l'errore spesso non è evidente finché il programma non viene eseguito.

è relativamente semplice evitare questi errori quando il selettore del messaggio è costante e la classe dell'oggetto ricevente è conosciuta. Come scrivi i tuoi programmi, puoi accertarti che il ricevente sia in grado di rispondere. Se il ricevente è tipato staticamente, il compilatore esegue questo test per te.

Comunque, se il selettore dl messaggio o la classe del ricevente varia, potrebbe essere necessario post-porre questo test fino a runtime. Il metodo respondsToSelector:, definito nella classe NSObject, determina se un ricevente può rispondere ad un messaggio. Prende il selettore di metodo come un argomento e restituisce se il ricevente ha accesso a metodi che combaciano con il selettore:

if ( [anObject respondsToSelector:@selector(setOrigin::)] )

[anObject setOrigin:0.0 :0.0];

else

fprintf(stderr, "%s can’t be placed\n",

[NSStringFromClass([anObject class]) UTF8String]);

Il test respondsToSelector: è specialmente importante quando si inviano messaggi ad oggetti di cui non hai il controllo al tempo di compilazione. Ad esempio, se scrivi codice che invia un messaggio ad un oggetto rappresentato da una variabile che altri possono impostare, dovresti accertarti che il ricevente implementi un metodo che risponda al messaggio.

Nota: Un oggetto si può anche sistemare per avere i messaggi che riceve, inoltrati ad altri oggetti se esso non può rispondere direttamente ai messaggi da solo. In tal caso, appare che l'oggetto può gestire il messaggio, anche se l'oggetto risponde al messaggio indirettamente assegnandolo ad un altro oggetto.

Fine Parte 11

Finisce qui l'undicesimo articolo di questa Guida dedicato ai Selettori del linguaggio di programmazione Objective-C. Il prossimo post di questa guida, parlerà della Gestione delle Eccezioni.

Segnalatemi eventuali errori, o commentate l'articolo se l'avete trovato utile, anche per incentivarmi a continuare a pubblicare le mie traduzioni. Iscrivetevi ai feed del blog per essere sempre aggiornati automaticamente ogni volta che sono disponibili nuovi contenuti.
Nella barra laterale del blog potete trovare l'elenco di tutti gli articoli di questa guida.

Guida Objective-C in Italiano - Comportamenti Statici - Parte 10

noreply@blogger.com (Unknown) — Sun, 02 May 2010 14:03:00 +0000

Nel decimo capitolo della Guida in Italiano alla programmazione in Objective-C, parleremo approfonditamente della tipatura statica, abilitare comportamenti statici rispetto a quelli che in Objective-C sono dinamici di default.

Questo post è una traduzione in italiano della Guida all'Objective C, presente sul sito developer.apple.com a questo link. L'Objective C è il linguaggio di programmazione per creare applicazioni per iPhone. Questo articolo può interessare a tutti gli sviluppatori che vogliono imparare le basi di questo linguaggio che è il fondamento per programmare nuove applicazioni per Mac Os X, iPhone ed iPad.

Abilitare Comportamenti Statici

Questo capitolo spiega come funziona la tipatura statica e parla di alcune altre caratteristiche dell'Objective-C, incluso metodi per sovrastare temporaneamente il suo dinamismo inerente.

Comportamento Dinamico di Default

Da progettazione, gli oggetti Objective-C sono entità dinamiche. Quante più decisioni possibili su di loro sono spinte dal tempo di compilazione al tempo di esecuzione:

La memoria per gli oggetti è allocata dinamicamente a runtime dai metodi di classe che creano nuove istanze.
Gli Oggetti sono tipati dinamicamente. Nel codice sorgente (a tempo di compilazione), ogni variabile di un oggetto può essere tipata id, non importa di che classe sia l'oggetto. L'esatta classe di una variabile id (e quindi i suoi metodi particolari e la struttura dati) non è determinata finché il programma non è in esecuzione.
Messaggi e metodi sono legati dinamicamente. Una procedura di runtime fà combaciare il selettore di metodo nel messaggio con un'implementazione di metodo che appartiene al ricevente.

Queste caratteristiche danno ai programmi OO una grande flessibilità, ma c'è un prezzo da pagare. In particolare, il compilatore non può controllare i tipi esatti (classi) delle variabili id. Per permettere un miglior controllo di tipo a tempo di compilazione, e per rendere il codice più auto-documentante, Objective-C permette agli oggetti di essere tipati staticamente con un nome di classe piuttosto che la tipatura generica come id. Permette anche di spegnere alcune delle caratteristiche OO per spostare operazioni dal tempo di esecuzione a quello di compilazione.

Nota: I messaggi sono qualcosa di più lento delle chiamate a funzioni, tipicamente incorrono in una quantità insignificante di lavoro aggiuntivo comparati al lavoro attualmente eseguito. Il caso particolarmente raro in cui bypassare il dinamismo dell'Objective-C potrebbe essere permesso, può essere provato usando gli strumenti di analisi come Shark o Instruments.

Tipatura Statica

Se un puntatore ad un nome di classe è usato al posto di un id in una dichiarazione di oggetto,

Rectangle *thisObject;

Il compilatore restringe il valore della variabile dichiarata ad essere o un'istanza della classe nominata nella dichiarazione o un'istanza di una classe che eredita dalla classe nominata. Nell'esempio sopra, ThisObject può essere solo un Rectangle di un qualche tipo.

Tipare staticamente oggetti ha la stesse strutture dati interne degli oggetti dichiarati id. Il tipo non influenza l'oggetto; influenza dolo la quantità di informazione data al compilatore circa l'oggetto e la quantità di informazione disponibile a quelli che leggono il codice sorgente.

La tipatura statica non influenza neanche il modo in cui l'oggetto è trattato a runtime. Gli oggetti staticamente tipati sono allocati dinamicamente dagli stessi metodi di classe che creano le istanze di tipo id. Se Square (quadrato) è una sottoclasse di Rectangle, il seguente codice produrrà ancora un oggetto con tutte le variabili di istanza di uno Square, non solo quelle di un Rectangle:

Rectangle *thisObject = [[Square alloc] init];

I messaggi inviati ad oggetti tipati staticamente sono legati dinamicamente, proprio come per gli oggetti tipati id. Il tipo esatto di un ricevente tipato staticamente è determinato ancora a runtime come una parte del processo di messaggistica. Un messaggio display inviato a thisObject

[thisObject display];

esegue la versione del metodo definita nella classe Square, non in quella della sua superclasse Rectangle.

Dando al compilatore più informazioni su un oggetto, la tipatura statica apre le possibilità che siano queste info siano assenti per oggetti tipati id:

In alcune situazioni, permette i controlli di tipo a tempo di compilazione.
Può liberare oggetti dalla restrizione che i metodi nominati identicamente devono avere identici valori di ritorno e tipi di argomenti.
Permette di usare la struttura operatore punto per accedere direttamente alle variabili d'istanza di un oggetto.

I primi due argomenti sono discussi nella sezione che segue. Il terzo è spiegato nel secondo articolo di questa guida "Definire Classi".

Controlli di Tipo

Con l'informazione aggiuntiva fornita dalla tipatura statica, il compilatore può consegnare un servizio di controllo di tipi migliore in due situazioni:

Quando un messaggio è inviato a un ricevente tipato staticamente, il compilatore può assicurarsi che il ricevente può rispondere. Un warning è emesso se il ricevente non ha accesso al metodo nominato nel messaggio.
Quando un oggetto tipato staticaemente è assegnato a una variabile tipata staticamente, il compilatore si accerta che i tipi siano compatibili. Emette un warning se non lo sono.

Un assegnamento può essere fatto senza warning, se la classe dell'oggetto definito è identica a, o eredita da, la classe della variabile che riceve l'assegnamento. Il seguente esempio illustra questo:

Shape *aShape;

Rectangle *aRect;

aRect = [[Rectangle alloc] init];

aShape = aRect;

Qui aRect può essere assegnato a aShape perchè un Rectangle è un tipo di Shape - la classe Rectangle eredita da Shape. Comunque, se i ruoli delle due variabili sono invertiti e aShape è assegnata a aRect, il compilatore genera un warning; non tutte le forme sono Rettangoli.

Non c'è controllo quando l'espressione su uno dei due lati dell'assegnamento è un id. Un oggetto tipato staticamente può essere liberamente assegnato ad un id, o un id a un oggetto tipato staticamente. Perché i metodi come alloc ed init restituiscono variabili tipate staticamente. Il seguente codice è incline ad errori, ma ciò nonostante si concede:

Rectangle *aRect;

aRect = [[Shape alloc] init];

Tipi di Ritorno e degli Argomenti

In generale, i metodi in classi diverse che hanno lo stesso selettore (lo stesso nome) devono anche condividere gli stessi tipi di ritorno e tipi di argomenti. Questo vincolo è imposto dal compilatore per permettere il collegamento dinamico (dynamic binding). Poiché la classe di un messaggio ricevente, (e quindi dettagli specifici di classe riguardo al metodo che gli è chiesto di eseguire) non può essere conosciuta a tempo di compilazione, il compilatore deve trattare allo stesso modo tutti i metodi con lo stesso nome. Quando prepara le informazioni sul ritorno del metodo e sui tipi degli argomenti per il sistema di runtime, crea solo una descrizione di metodo per ogni selettore di metodo.

Comunque, quando un messaggio è inviato a un oggetto tipato staticamente, la classe del ricevente è conosciuta dal compilatore. Il compilatore ha accesso a informazioni specifiche della classe riguardo ai metodi. Quindi, il messaggio è liberato dalle restrizioni sui suoi valori di ritorno e tipi di argomenti.

Tipatura Statica a una Classe Ereditata

Un'istanza può essere tipata staticamente alla sua propria classe o a qualunque classe da cui eredita. Tutte le istanze, ad esempio, possono essere tipate staticamente come NSObject.

Comunque, il compilatore capisce la classe di un oggetto tipato staticamente solo dal nome di classe nella designazione del tipo, ed effettua il suo controllo di tipi di conseguenza. Tipare un'istanza a una classe ereditata può quindi risultare in discrepanze tra ciò che il compilatore pensa che potrebbe accadere a runtime e cosa realmente succede.

Ad esempio, se tipi staticamente un'istanza di Rectangle come una Shape,

Shape *myRectangle = [[Rectangle alloc] init];

Il compilatore la tratterà come una Shape. Se invii all'oggetto un messaggio per eseguire un metodo di Rectangle,

BOOL solid = [myRectangle isFilled];

Il compilatore si lamenterà. Il metodo isFilled è definito nella classe Rectangle ma non in Shape.

Comunque, se gli invii un messaggio per eseguire un metodo che classe Shape conosce,

[myRectangle display];

Il compilatore non si lamenterà, anche se Rectangle sovrascrive il metodo. A runtime, è eseguita la versione del metodo di Rectangle.

In modo analogo, supponiamo che la classe sorastante dichiara un metodo worry che restituisce un double,

- (double)worry;

e la sottoclasse di mezzo sovrascrive il metodo e dichiara un nuovo tipo di ritorno:

- (int)worry;

Se un'istanza è tipata staticamente alla classe superiore, il compilatore penserà che il suo metodo worry restituisce un double, e se un istanza è tipata alla classe di mezzo, penserà che worry restituisce un intero. Risulteranno ovviamente errori se un'istanza della classe di mezzo è tipata alla classe superiore. Il compilatore informerà il sistema di runtime che un messaggio worry è inviato ad un oggetto che restituisce un double, ma a runtime esso restituisce attualmente un int e genera un errore.

La tipatura statica può liberare metodi nominati in modo identico dalla restrizione che devono avere valori di ritorno e tipi di argomento identici, ma lo può fare così affidabilmente solo se i metodi sono dichiarati in rami differenti della gerarchia delle classi.

Fine Parte 10

Finisce qui il decimo articolo di questa Guida dedicato alla tipatura statica nel linguaggio di programmazione Objective-C. Il prossimo post di questa guida, parlerà dei Selettori.

Segnalatemi eventuali errori, o commentate l'articolo se l'avete trovato utile, anche per incentivarmi a continuare a pubblicare le mie traduzioni. Iscrivetevi ai feed del blog per essere sempre aggiornati automaticamente ogni volta che sono disponibili nuovi contenuti. Nella barra laterale del blog potete trovare l'elenco di tutti gli articoli di questa guida.

Guida Objective-C in Italiano - Parte 9 - Enumerazione Veloce

noreply@blogger.com (Unknown) — Sat, 01 May 2010 10:25:00 +0000

Enumerare oggetti di una collezione, tramite la caratteristica Enumerazione Veloce; questo sarà l'argomento trattato oggi, in questa nona parte della Guida in Italiano alla programmazione in Objective-C.

Questo post è una traduzione in italiano della Guida all'Objective C, presente sul sito developer.apple.com a questo link. L'Objective C è il linguaggio di programmazione per creare applicazioni per iPhone. Questo articolo può interessare a tutti gli sviluppatori che vogliono imparare le basi di questo linguaggio che è il fondamento per programmare nuove applicazioni per Mac Os X, iPhone ed iPad.

Enumerazione Veloce

L'enumerazione veloce è una caratteristica del linguaggio che ti permette di enumerare in modo sicuro ed efficiente i contenuti di una collezione usando una sintassi efficiente.

La caratteristica for…in

L'enumerazione veloce è una caratteristica del linguaggio che ti permette di enumerare in modo sicuro ed efficiente i contenuti di una collezione usando una sintassi efficiente. La sintassi è definita come segue:

for ( Tipo nuovaVariabile in espressione ) { statements }

Tipo nuovaVariabile;

for ( nuovaVariabile in expression ) { statements }

In entrambi i casi, le espressioni raccolgono un oggetto conforme al protocollo NSFastEnumeration. La variabile che itera è impostata a turno ad ogni elemento nell'oggetto restituito, e il codice definito dagli statements è eseguito. La variabile che itera è impostata a nil quando il ciclo finisce esaurendo la sorgente del gruppo di oggetti. Se il ciclo è terminato presto, la variabile che itera è lasciata a puntare all'ultimo elemento dell'iterazione.

Ci sono molti vantaggi dell'uso dell'enumerazione veloce:

L'enumerazione è considerevolmente più efficiente rispetto ad usare direttamente NSEnumerator.
La sintassi è concisa.
L'enumerazione è sicura - l'enumeratore ha una sentinella di mutazione, così che provi a modificare la collezione durante l'enumerazione, verrà emessa un'eccezione.

Dato che la mutazione dell'oggetto durante l'iterazione è vietata, puoi eseguire anche enumerazioni multiple contemporaneamente.

Adottare l'enumerazione veloce

Qualsiasi classe le cui istanze forniscono un accesso ad una collezione di altri oggetti può adottare il protocollo NSFastEnumeration. La collezione di classi Cocoa - NSArray, NSDictionary, e NSSet - adottano questo protocollo, come fà NSEnumerator. Dovrebbe essere ovvio che nei casi di NSArray e NSSet l'enumerazione riguarda i loro contenuti. Per altre classi, la documentazione corrispondente potrebbe chiarire che proprietà è iterata - ad esempio, NSDictionary e la classe NSManageObjectModel del Core Data forniscono supporto per l'enumerazione veloce; NSDictionary numera le sue chiavi, e NSManageObjectModel enumera le sue entità.

Usare l'enumerazione veloce

Il seguente codice d'esempio illustra l'uso dell'enumerazione veloce con oggetti NSArray e NSDictionary.

NSArray *array = [NSArray arrayWithObjects:
   @"One", @"Two", @"Three", @"Four", nil];

for (NSString *element in array) {
   NSLog(@"element: %@", element);
}

NSDictionary *dictionary = [NSDictionary dictionaryWithObjectsAndKeys:
   @"quattuor", @"four", @"quinque", @"five", @"sex", @"six", nil];

NSString *key;
for (key in dictionary) {
   NSLog(@"English: %@, Latin: %@", key, [dictionary valueForKey:key]);
}

Puoi anche usare oggetti NSEnumerator con l'enumerazione veloce, come illustrato nel seguente esempio:

NSArray *array = [NSArray arrayWithObjects:
   @"One", @"Two", @"Three", @"Four", nil];

NSEnumerator *enumerator = [array reverseObjectEnumerator];
for (NSString *element in enumerator) {
   if ([element isEqualToString:@"Three"]) {
   break;
   }
}

NSString *next = [enumerator nextObject];
// next = "Two"

Per collezioni o enumeratori che hanno un ordine ben definito - come NSArray o istanze di NSEnumerator derivate da un array - l'enumerazione procede in quell'ordine, quindi, per conoscere l'indice dell'elemento della collezione che vi serve, vi basterà contare le iterazioni.

NSArray *array = /* assume this exists */;

NSUInteger index = 0;

for (id element in array) {
NSLog(@"Element at index %u is: %@", index, element); index++;
}

In altri rispetti, la caratteristica si comporta come un ciclo for standard. Puoi usare break per interrompere l'iterazione; e se vuoi saltare elementi puoi usare uno statement condizionale annidato come mostrato nel seguente esempio:

NSArray *array = /* assumiamo che questo esista */;

for (id element in array) {
   if (/* qualche test per l'elemento */) {
   // statements che si applicano ai soli elementi che superano il test
   }
}

Se vuoi saltare il primo elemento e poi processare non più di cinque ulteriori elementi, potresti fare come mostrato in questo esempio:

NSArray *array = /* assumiamo che questo esista */;
NSUInteger index = 0;

for (id element in array) {
   if (index != 0) {
   NSLog(@"Element at index %u is: %@", index, element);
   }
   if (++index >= 6) {
   break;
   }
}

Fine Parte 9

Finisce qui il nono articolo di questa Guida dedicato all'Enumerazione Veloce del linguaggio di programmazione Objective-C. Il prossimo post di questa guida, parlerà di come abilitare comportamenti statici; vedremo quindi più in dettaglio come funziona la tipatura statica, e discuteremo di alcune caratteristiche dell'Objective-C come vari modi per sormontare temporaneamente il suo dinamismo.

Segnalatemi eventuali errori, o commentate l'articolo se l'avete trovato utile, anche per incentivarmi a continuare a pubblicare le mie traduzioni. Iscrivetevi ai feed del blog per essere sempre aggiornati automaticamente ogni volta che sono disponibili nuovi contenuti.
Nella barra laterale del blog potete trovare l'elenco di tutti gli articoli di questa guida.

Guida Objective-C in Italiano - Parte 8 - Riferimenti Associativi

noreply@blogger.com (Unknown) — Fri, 30 Apr 2010 09:21:00 +0000

Questa è l'ottava parte della Guida alla programmazione in Objective-C, oggi parleremo di Riferimenti Associativi.

Questo post è una traduzione in italiano della Guida all'Objective C, presente sul sito developer.apple.com a questo link. L'Objective C è il linguaggio di programmazione per creare applicazioni per iPhone. Questo articolo può interessare a tutti gli sviluppatori che vogliono imparare le basi di questo linguaggio che è il fondamento per programmare nuove applicazioni per Mac Os X, iPhone ed iPad.

Riferimenti Associativi

Si usano i riferimenti associativi per simulare l'aggiunta di variabili di istanza di un oggetto ad una classe esistente.

I riferimenti associativi sono disponibili solo in Mac OS X v10.6 e successivi.

Aggiungere Memoria fuori a una Definizione di Classe

Usando i riferimenti associativi, puoi aggiungere memoria ad un oggetto senza modificare la dichiarazione di classe. Questo può essere utile se non hai accesso al codice sorgente della classe, o se per motivi di compatibilità binaria non puoi alterare il layout dell'oggetto.

Le Associazioni sono basate su una chiave, quindi per ogni oggetto puoi aggiungere quante associazioni vuoi, ognuna usando una chiave diversa. Un'associazione può anche assicurare che l'oggetto associato rimane valido per almeno il tempo di vita dell'oggetto sorgente (senza la possibilità di introdurre cicli non riscuotibili in un ambiente garbage-collected).

Creare Associazioni

Usate la funzione Objective-C di runtime objc_setAssociatedObject per creare un'associazione tra un oggetto ed un altro. La funzione prende quattro argomenti: l'oggetto sorgente, una chiave, il valore e una politica di associazione costante. Di queste, la chiave e la politica di associazione meritano ulteriori discussioni.

La chiave è un puntatore a void. La chiave per ogni associazione deve essere unica. Un pattern tipico è usare una variabile statica.
La politica specifica se l'oggetto associato è assegnato, conservato o copiato (assign, retain, copy) e se l'associazione è fatta atomicamente o non-atomicamente. Questo segue un pattern simile agli attributi di una proprietà dichiarata. Specifica la politica per la relazione usando una costante (vedi objc_AssociationPolicy).

Il seguente esempio mostra come puoi stabilire un'associazione tra un array ed una stringa.
Listato 7-1 Stabilire un'associazione tra un array e una stringa

static char overviewKey;

NSArray *array = [[NSArray alloc] initWithObjects:@"One", @"Two", @"Three", nil];

// For the purposes of illustration, use initWithFormat: to ensure the string can be deallocated

NSString *overview = [[NSString alloc] initWithFormat:@"%@", @"First three numbers"];

objc_setAssociatedObject(array, &overviewKey, overview, OBJC_ASSOCIATION_RETAIN);

[overview release];

// (1) overview valid

[array release];

// (2) overview invalid

Al punto (1), la stringa overview è ancora valida poiché la politica OBJC_ASSOCIATION_RETAIN specifica che l'array conserva l'oggetto associato. Quando l'array è deallocato, (al punto 2), overview è rilasciata e in questo caso quindi, anche deallocata. Se provi, ad esempio, ad annotare il valore di overview, genererai un'eccezione di runtime.

Recuperare Oggetti Associati

Puoi recuperare un oggetto associato usando la funzione di runtime di Objective-C objc_getAssociatedObject. Continuando l'esempio mostrato nel listato 7-1, puoi recuperare overview dall'array usando la seguente linea di codice:

NSString *associatedObject = (NSString *)objc_getAssociatedObject(array, &overviewKey);

Rompere Associazioni

Per rompere un'associazione, si usa tipicamente objc_setAssociatedObject, passandogli nil come valore. Continuando l'esempio mostrato nel listato 7-1, potresti rompere l'associazione tra array e stringa overview usando la seguente linea di codice:

objc_setAssociatedObject(array, &overviewKey, nil, OBJC_ASSOCIATION_ASSIGN);

(Dato che l'oggetto associato è stato impostato a nil, la politica non è attualmente importante). Per rompere tutte le associazioni di un oggetto, puoi usare objc_removeAssociatedObjects. In generale, è sconsigliato usare questo dato che rompe tutte le associazioni per tutti i clienti. Usa questa funzione solo se hai bisogno di restaurare un oggetto a condizioni incontaminate.

Esempio Completo

Il seguente programma combina gli esempi di codice delle sezioni precedenti.

#import
#import

int main (int argc, const char * argv[]) {
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

static char overviewKey;

NSArray *array = [[NSArray alloc] initWithObjects:@"One", @"Two", @"Three", nil];
// For the purposes of illustration, use initWithFormat: to ensure we get a // deallocatable string
NSString *overview = [[NSString alloc] initWithFormat:@"%@", @"First three numbers"];

objc_setAssociatedObject(array, &overviewKey, overview, OBJC_ASSOCIATION_RETAIN);
[overview release];

NSString *associatedObject = (NSString *)objc_getAssociatedObject(array, &overviewKey);
NSLog(@"associatedObject: %@", associatedObject);

objc_setAssociatedObject(array, &overviewKey, nil, OBJC_ASSOCIATION_ASSIGN);
[array release];

[pool drain];
return 0;
}

Fine Ottava parte

Finisce qui l'ottavo articolo di questa Guida dedicato ai Riferimenti Associativi del linguaggio di programmazione Objective-C. Spero col tempo di realizzare un'utile manuale disponibile a tutti. Il prossimo post di questa guida, tratterà l'Enumerazione Veloce, un utile strumento che fornisce una sintassi concisa, efficiente e sicura, per enumerare i contenuti di una collezione. Segnalatemi eventuali errori, o commentate l'articolo se l'avete trovato utile, anche per incentivarmi a continuare a pubblicare le mie traduzioni. Iscrivetevi ai feed del blog per essere sempre aggiornati automaticamente ogni volta che sono disponibili nuovi contenuti. Nella barra laterale del blog potete trovare l'elenco di tutti gli articoli di questa guida.

Guida Objective-C in Italiano - Parte 7 - Categorie ed Estensioni

noreply@blogger.com (Unknown) — Thu, 29 Apr 2010 12:44:00 +0000

Eccoci alla settima parte della Guida alla programmazione in Objective-C, oggi parleremo di Categorie ed Estensioni.

Questo post è una traduzione in italiano della Guida all'Objective C, presente sul sito developer.apple.com a questo link. L'Objective C è il linguaggio di programmazione per creare applicazioni per iPhone. Questo articolo può interessare a tutti gli sviluppatori che vogliono imparare le basi di questo linguaggio che è il fondamento per programmare nuove applicazioni per Mac Os X, iPhone ed iPad.

Categorie ed Estensioni

Una categoria ti permette di aggiungere metodi ad una classe esitente - anche ad una di cui no hai il codice sorgente. Questa è una caratteristica molto potente che ti permette di estendere le funzionalità di una classe esistente senza crearne una sottoclasse. Usando le categorie, puoi anche dividere l'implementazione delle tue classi tra molti files. Le estensioni delle classi sono simili, ma permettono ad API aggiuntive richieste di essere dichiarate per una classe in locazioni diverse dal blocco @interface della classe primaria.

Aggiungere Metodi a Classi

Puoi aggiungere metodi ad una classe dichiarandoli in un file interfaccia sotto un nome di categoria e definendoli in un file implementazione sotto lo stesso nome. Il nome di categoria indica che i metodi sono delle aggiunte ad una classe dichiarata da qualche altra parte, non una nuova classe. non pouoi, comunque usare una categoria per aggiungere variabili di istanza ad una classe.

I metodi che la categoria aggiunge diventano parte del tipo della classe. Ad esempio i metodi aggiunti alla classe NSArray in una categoria sono tra i metodi che il compilatore si aspetta di trovare nel repertorio dei metodi di un'istanza della classe NSArray. I metodi aggiunti alla classe NSArray in una sottoclasse non sono inclusi nel tipo NSArray. (Questo importa solo per oggetti tipati staticamente dato che lo static typing è l'unico modo per il compilatore di conoscere la classe di un oggetto).

I metodi di Categoria possono fare qualunque cosa che possono fare i metodi definiti nella classe. A runtime non c'è differenza. I metodi che la categoria aggiunge alla classe sono ereditati da tutte le sottoclassi, proprio come gli altri metodi.

La dichiarazione di un'interfaccia di categoria appare molto come una dichiarazione di interfaccia di classe - tranne che il nome di categoria è elencato tra parentesi dopo il nome di classe e la superclasse non è menzionata. A meno che i suoi metodi non accedano ad alcuna variabile di istanza della classe, la categoria deve importare il file interfaccia della classe che estende:

#import "ClassName.h"

@interface ClassName ( CategoryName )

// method declarations

@end

L'implementazione, come al solito, importa la sua propria interfaccia. Una convenzione comune per i nomi è che il nome del file di base della categoria è il nome della classe che la categoria estende seguito da un "+" seguito dal nome della categoria. Un'implementazione di categoria (in un file nominato NomeClasse+NomeCategoria.m) potrebbe quindi apparire così:

#import "ClassName+CategoryName.h"

@implementation ClassName ( CategoryName )

// method definitions

@end

Nota che una categoria non può dichiarare variabil idi istanza aggiuntive per la classe; include solo metodi. Comnque, tutte le variabili di istanza entro lo scope della classe sono anche nello scope della categoria. questo include tutte le variabili di istanza dichiarate dalla classe, anche quelle dichiarate @private.

Non c'è limite al numero di categorie che puoi aggiungere ad una classe, ma ogni nome di categoria deve essere diverso, ed ognuno dovrebbe dichiarare e definire un insieme diverso di metodi.

Come Usare le Categorie

Ci sono tanti modi di usare le categorie:

Per estendere classi definite da altrei implementatori. Ad esempio, se puoi aggiungre metodi alle classi definite nel frameworks Cocoa. I metodi aggiunti sono ereditati dalle sottoclassi e sono indistinguibili a runtime dai metodi originali della classe.
Come alternativa ad una sottoclasse. Piuttosto che definire una sottoclasse per estendere una classe esistente, attraverso una categoria puoi aggiungeremetodi alla classe direttamente. Ad esempio, puoi aggiungere categorie a NSArray e altre classi Cocoa. Come nel caso di una sottoclasse, non hai bisogno del codice sorgente della classe che stai estendendo.
Per distribuire l'implementazione di una nuova classe in files sorgenti separati. Ad esempio, puoi raggruppare i metodi di una classe grande in diverse categorie e mettere ogni categoria in un file diverso. Quando sono usate in questo modo, le categorie possono beneficiare del processo di sviluppo in un vari modi - Esse:

Forniscono un semplice modo di raggruppare metodi correlati. Metodi simili definiti in classi diverse possono essere messi insieme nello stesso file sorgente.
Semplifica la gestione di una classe grande quando molti sviluppatori contribuiscono alla sua definizione.
Ti permette di raggiungere alcuni dei benefici della compilazione incrementale per una classe molto grande.
Può aiutare a migliorare la località delle referenze per metodi comunemente usati.
Ti Abilita a configurare una classe diversamente per applicazioni separate, senza dover mantenere diverse versioni dello stesso codice.

Sebbene il linguaggio ti permette di usare una categoria per sovrascrivere i metodi che la classe eredita, o anche i metodi dichiarati nell'interfaccia della classe, è fortemente sconsigliato l'uso di questa funzionalità. Una categoria non è una sostituta per una sottoclasse. Ci sono molte imperfezioni significanti:

Quando una categoria sovrascrive un metodo ereditato, il metodo nella categoria può, come è solito, invocare l'implementazione ereditata tramite un messaggio a super. Comunque, se una categoria sovrascrive un metodo che esiste già nella classe della categoria, non c'è modo per invocare l'implementazione originale.
Una categoria non può sovrascrivere con affidabilità i metodi dichiarati in un altra categoria della stessa classe. Questo problema è particolarmente significante dato che molte delle classi Cocoa sono implementate usando le categorie. Un metodo basato su framework che provi a sovrascrivere potrebbe essere stato implementato in una categoria, e quindi non è definito quale implementazione ha la precedenza.
La presena di alcuni metodi potrebbe causare cambi dei comportamenti tra tutti i frameworks. Ad esempio, se aggiungi un'implementazione di windowWillClose: a NSObject, questo causerà che tutte le finestre delegate risponderanno a quel metodo e potrebbero modificare il comportamento di tutte le istanze di NSWindow. Questo potrebbe causare cambiamenti misteriosi nel comportamento e potrebbe condurre a crashes.

Categorie della Classe Radice

Una categoria può aggiungere metodi ad ogni classe, incluso nella classe radice. I metodi aggiunti a NSObject diventano disponibili a tutte le classi che sono collegate al tuo codice. Mentre questo può essere utile a volte, può anche essere abbastanza pericoloso. Sebbene potrebbe sembrare che le modifiche che le categorie fanno siano ben capite e di impatto limitato, l'ereditarietà gli da un ampio scope. Potresti fare dei cambi non intenzionali a classi non viste; potresti non conoscere tutte le conseguenze di ciò che stai facendo. Inoltre, gli altri che non sono a conoscenza dei tuoi cambi non capiranno cosa stanno facendo.

In aggiunta, ci sono altre due considerazioni da tenere a mente quando si implementano metodi per la classe radice:

Messaggi a super sono invalidi (non c'è la superclasse).
Gli oggetti di classe possono eseguire metodi di istanza definiti nella classe radice.

Normalmente gli oggetti di classe possono eseguire solo metodi di classe. Ma i metodi di istanza definiti nella classe radice sono un caso speciale. Essi definiscono un'interfaccia al sistema di runtime che tutti gli oggetti ereditano. Gli oggetti di classe sono oggetti full-fledged e devono condividere la stessa interfaccia.

Questa caratteristica significa che hai bisogno di tener conto della possibilità che un metodo di istanza che definisci in una categoria della classe NSObject potrebbe essere eseguito non solo da istanze ma da anche da oggetti di classe. Ad esempio, nel corpo del metodo, self potrebbe significare un oggetto di classe così come un'istanza.

Estensioni

Le estensioni di classi sono come categorie "anonime", tranne che i metodi che dichiarano devono essere implementati nel blocco principale @implementation per la classe corrispondente.

È comune per una classe avere un'API pubblicamente dichiarata e poi avere API aggiuntiva dichiarata privatamente per solo uso della classe o del framework dentro il quale risiede la classe. Puoi dichiarare tale API in una categoria (o in più di una categoria) in un file header privato o in un file di implementazione come descritto sopra. Questo funziona, ma il compilatore non può verificare che tutti i metodi dichiarati siano implementati.

Ad esempio, il compilatore compilerà senza errori le seguenti dichiarazioni e implementazioni:

@interface MyObject : NSObject

{

NSNumber *number;

}

- (NSNumber *)number;

@end

@interface MyObject (Setter)

- (void)setNumber:(NSNumber *)newNumber;

@end

@implementation MyObject

- (NSNumber *)number {

return number;

}

@end

Nota che non c'è implementazione del metodo setNumber:. Se è invocato a runtime genererà un errore.

Le estensioni di classe ti permettono di dichiarare API aggiuntive richieste per una classe in locazioni diverse da dentro al blocco primario @interface della classe, come illustrato nel seguente esempio:

@interface MyObject : NSObject

{

NSNumber *number;

}

- (NSNumber *)number;

@end

@interface MyObject ()

- (void)setNumber:(NSNumber *)newNumber;

@end

@implementation MyObject

- (NSNumber *)number {

return number;

}

- (void)setNumber:(NSNumber *)newNumber {

number = newNumber;

}

@end

Nota che in questo caso:

Non è dato un nome nelle parentesi nel secondo blocco @interface;
L'implementazione del metodo setNumber: appare dentro al blocco @implementation princpiale della classe.

L'implementazione del metodo setNumber. deve apparire dentro al blocco @implementation princpale della classe (non poui implementarlo in una categoria). Se questo non è il caso, il compilatore emetterà un warning avvisando che non può trovare una definizione di metodo per setNumber:.

Fine Settima Parte

Finisce qui il settimo articolo di questa Guida dedicato alle Categorie e Estensioni del linguaggio di programmazione Objective-C. Spero col tempo di realizzare un'utile manuale disponibile a tutti. Il prossimo post di questa guida, tratterà i Riferimenti Associativi, un utile strumento per simulare l'aggiunta di variabili di istanza di un oggetto ad una classe esistente. Segnalatemi eventuali errori, o commentate l'articolo se l'avete trovato utile, anche per incentivarmi a continuare a pubblicare le mie traduzioni. Iscrivetevi ai feed del blog per essere sempre aggiornati automaticamente ogni volta che sono disponibili nuovi contenuti. Nella barra laterale del blog potete trovare l'elenco di tutti gli articoli di questa guida.

Guida Objective-C in Italiano - Parte 6 - Le proprietà Dichiarate

noreply@blogger.com (Unknown) — Wed, 28 Apr 2010 17:06:00 +0000

In questa sesta parte della Guida alla programmazione in Objective-C parleremo delle proprietà dichiarate delle classi, come si dichiarano, come si implementano, come si usano e come si sintetizzano automaticamente i loro metodi accessori.

Questo post è una traduzione in italiano della Guida all'Objective C, presente sul sito developer.apple.com a questo link. L'Objective C è il linguaggio di programmazione per creare applicazioni per iPhone. Questo articolo può interessare a tutti gli sviluppatori che vogliono imparare le basi di questo linguaggio che è il fondamento per programmare nuove applicazioni per Mac Os X, iPhone ed iPad.

Proprietà Dichiarate

Le proprietà dichiarate Objective-C fornisce un semplice modo di dichiarare ed implementare i metodi accessori di un metodo.

Anteprima

Questi sono due aspetti di questa caratteristica del linguaggio: gli elementi sintattici che usi per specificare e sintetizzare le proprietà dichiarate, e un elemento sintattico collegato che sarà descritto in "Sintassi Punto".

Tipicamente accedi alle proprietà di un oggetto (i suoi attributi e relazioni) attraverso una coppia di metodi accessori (getter e setter). Usando i metodi accessori, aderisci al principio dell'incapsulamento. Puoi esercitare uno stretto controllo del comportamento della coppia getter/setter e della gestione dello stato di fondo mentre i clients delle API restano isolati dai cambiamenti dell'implementazione.

Sebbene usare metodi accessori abbia vantaggi significativi, scrivere metodi accessori è un processo noioso - in particolare se devi scrivere codice per supportare entrambi ambienti garbage collected e reference counted. Inoltre, aspetti delle proprietà che possono essere importanti per i clienti delle API sono lasciate oscurate - come se i metodi accessori fossero thread-safe o se nuovi valori sono copiati quando si impostano.

Le proprietà dichiarate indirizzano i problemi con metodi accessori standard fornendo le seguenti caratteristiche:

La dichiarazione di proprietà fornisce una chiara, ed esplicita specifica di come i metodi accessori si comportano.
Il compilatore può sintetizzare i metodi accessori per te, in accordo alla specifica da te fornita nella dichiarazione. Questo significa che hai meno codice da scrivere e mantenere.
Le proprietà sono rappresentate sintatticamente come identificatori e hanno uno scope, quindi il compilatore può identificare un uso di proprietà non dichiarate.

Dichiarazione di Proprietà e Implementazione

Ci sono due parti di una proprietà dichiarata, la sua dichiarazione e la sua implementazione.

Dichiarazione di Proprietà

Una dichiarazione di proprietà inizia con la parola chiave @property. @property può apparire ovunque nella lista della dichiarazione dei metodi trovata nella @interface di una classe. @property può anche apparire nella dichiarazione di un protocollo o di una categoria.

@property(attributes) type name;

@property dichiara una proprietà. Una insieme opzionale di attributi tra parentesi, fornisce dettagli aggiuntivi riguardo alle semantiche di memoria e altri comportamenti della proprietà. Come ogni altro tipo Objective-C, ogni proprietà ha una specifica di tipo ed un nome.

Il listato 5-1 illustra la dichiarazione di una semplice proprietà.

Listato 5-1 Dichiarazione di una semplice proprietà

@interface MyClass : NSObject

{

float value;

}

@property float value;

@end

Puoi pensare che una dichiarazione di proprietà sia l'equivalente a dichiarare due metodi accessori. Così

@property float value;

è equivalente a:

- (float)value;

- (void)setValue:(float)newValue;

Una dichiarazione di proprietà comunque, fornisce informazioni aggiuntive su come i metodi accessori sono implementati, come descritto in Attributi di dichiarazioni di proprietà.

Attributi di Dichiarazioni di Proprietà

Potete decorare una proprietà con degli attributi usando la forma @property(attribute [, attribute2, ...]). Come i metodi, le proprietà hanno lo scope nella dichiarazione di interfaccia che le racchiude. Per le dichiarazioni di proprietà che usano una lista di nomi di variabili delimitata da virgole, gli attributi di proprietà si applicano a tutte le proprietà nominate.

Se usi la direttiva @synthesize per dire al compilatore di creare i metodi accessori, il codice che genera combacerà con la specifica data dalle parolechiave. Se implementi i metodi accessori per conto tuo, dovresti appunto assicurarti che combacino con la specifica (ad esempio, se specifichi "copy", ti devi assicurare che effettivamente copi il valore di input nel metodo setter).

Nomi dei Metodi Accessori

I nomi di default per i metodi getter e setter associati ad una proprietà, sono "nomeProprietà" e "setNomeProprietà:" rispettivamente - ad esempio, avendo una proprietà "foo", gli accessori sarebbero foo e setFoo:. Gli attributi seguenti permettono invece di specificare nomi personalizzati. Sono entrambi opzionali e potrebbero apparire con qualunque altro attributo (tranne per readonly nel caso di setter=).

getter=getterName
Specifica il nome del metodo accessorio get per la proprietà. Il getter deve restituire un tipo che combacia con il tipo della proprietà e non prendere argomenti.

setter=setterName
Specifica il nome del metodo accessorio set per la proprietà. Il metodo setter deve prendere un singolo argomento il cui tipo combaci con il tipo della proprietà e deve restituire void.
Se specifichi che una proprietà è readonly allora specifichi anche un setter con setter=, otterrai un warning dal compilatore.

Tipicamente dovresti specificare i nomi dei metodi accessori che sono chiave-valore codifica compiacente - una ragione comune per usare il decoratore getter è di aderire alla convenzione isNomeProprietà per valori booleani.

Scrivibilità

Questi attributi specificano se una proprietà ha un metodo accessorio set associato o meno. Sono mutuamente esclusivi.

readwrite
Indica che la proprietà dovrebbe essere trattata come read/write. Questa è l'opzione di default.
Entrambi i metodi getter e setter saranno richiesti nella @implementation. Se usi @synthesize nel blocco implementazione, i metodi getter e setter saranno sintetizzati.

readonly
Indicache la proprietà è read-only.
Se specifichi readonly, sarà richiesto solo un metodo getter nella @implementation. Se usi @synthesize nel blocco dell' implementazione, sarà sintetizzato solo il metodo getter. Inoltre, se provi ad assegnare un valore usando la sintassi punto, ottieni un errore di compilazione.

Semantica Setter

Questi attributi specificano le semantiche di un accessorio set. Sono mutualmente esclusive.

assign
Specifica che il setter usa un assegnamento semplice. Questo è di default.
Tipicamente usi questo attributo per tipi scalari come NSInteger e CGRect, o (in un ambiente reference-counted) per oggetti di cui non sei il proprietario come i delegati.

retain ed assign sono praticamente la stessa cosa in ambienti garbage-collected.

retain
Specifica che dovrebbe essere invocato retain sull'oggetto sotto assegnamento. (Di default è assign.) Il valore precedente è inviato a un messaggio release.
Prima di Mac OS X v10.6, questo attributo era valido solo per tipi di oggetti Objective-C (quindi non puoi specificare retain per oggetti di Core Foundation).

Su Mac OS X v10.6 e successivi, puoi usare __attributo__ parolachiave per specificare che una proprietà del Core Foundation dovrebbe essere trattata come un oggetto Objective-C per la gestione della memoria, come illustrato in questo esempio:

@property(retain) __attribute__((NSObject)) CFDictionaryRef myDictionary;

copy
Specifica che una copia dell'oggetto dovrebbe essere usata per l'assegnamento (di default è assign). Il valore precedente è inviato a un messaggio release.
La copia è fatta invocando il metodo copy. Questo attributo è valido solo per tipi di oggetti, che devono implementare il protocolo NSCopying.

Si applicano vincoli differenti a seconda di se si usa la garbage collection o no:

Se non usi la garbage collection, per le proprietà degli oggetti devi esplicitamente specificare uno tra assign, retain o copy - altrimenti avrai un warning dal compilatore. (Questo ti incoraggia a pensare su che tipo di comportamento vuoi per la gestione della memoria e a digitarlo esplicitamente). Per decidere quale dovresti scegliere, devi capire le politiche di gestione memoria di Cocoa (Vedi Memory Management Programming Guide for Cocoa).
Se usi la garbage collection, non otterrai un warning se usi il default (che è, se non specifichi nulla tra assign, retain o copy) a meno che il tipo della proprietà sia una classe conforme ad NSCopying. Il default è di solito quello che vuoi; se il tipo della proprietà può essere copiato, comunque, per preservare l'incapsulamento spesso vorrai fare una copia privata dell'oggetto.

Atomicità

Questo attributo specifica che i metodi accessori non sono atomici. (non c'è una parola chiave per denotare atomico).

nonatomic
Specifica che i metodi accessori sono non-atomici. Di default, i metodi accessori sono atomici.
Le proprietà sono atomiche di default quindi i loro metodi accessori sintetizzati forniscono un accesso robusto alle proprietà in un ambiente multi-threaded - che è, il valore restituito dal getter o settato tramite il setter è sempre pienamente recuperato o impostato senza curarsi di quali altri threads sono concorrentemente in esecuzione.

Se non specifichi nonatomic, allora in un ambiente reference counted, un metodo accessorio sintetizzato per una proprietà di un oggetto usa un lock e conserva e autorilascia il valore restituito - l'implementazione sarà simile alla seguente:

[_internal lock]; // lock using an object-level lock

id result = [[value retain] autorelease];

[_internal unlock];

return result;

Se specifichi nonatomic, allora un accessorio sintetizzato per una proprietà di un oggetto semplicemente restituisce il valore direttamente.

Markup e Deprecazione

Le proprietà supportano la piena gamma di decoratori di stile C. Le proprietà possono essere deprecate e supportare attributi di markup di stile __attribute__ , come illustrato nel seguente esempio:

@property CGFloat x

AVAILABLE_MAC_OS_X_VERSION_10_1_AND_LATER_BUT_DEPRECATED_IN_MAC_OS_X_VERSION_10_4;

@property CGFloat y __attribute__((...));

Se vuoi specificare che una proprietà è un'outlet di Interface Builder, puoi usare l'identificatore IBOutlet:

@property (nonatomic, retain) IBOutlet NSButton *myButton;

IBOutlet non è una parte formale della lista degli attributi.

Se usi la garbage collection, puoi usare modificatori di storage come __weak e __strong in una dichiarazione di proprietà:

@property (nonatomic, retain) __weak Link *parent;

ma non sono una parte formale della lista degli attributi.

Direttive di Implementazione di Proprietà

Puoi usare le direttive @synthesize e @dynamic nei blocchi @implementation per innescare specifiche azioni del compilatore. Nota che nessuna delle due è richiestaper qualunque dichiarazione di @property data.

Importante: se non specifichi nè @synthesize nè @dynamic per una particolare proprietà, devi fornire un'implementazione dei metodi getter e un setter (o solo du un getter nel caso di una proprietà readonly) per questa proprietà.

@synthesize
Usi la parola chiave @synthesize per dire al compilatore che dovrebbe sintetizzare i metodi setter e/o getter per la proprietà se non li fornisci nel blocco @implementagion.

Listato 5-2 Usare @synthesize

@interface MyClass : NSObject

{

NSString *value;

}

@property(copy, readwrite) NSString *value;

@end

@implementation MyClass

@synthesize value;

@end

Puoi usare la forma property=ivar per indicare che una particolare variabile di istanza dovrebbe essere usata per la proprietà, ad esempio:

@synthesize firstName, lastName, age = yearsOld;

Questo specifica che i metodi accessori per firstName, lastName, e age dovrebbero essere sintetizzati e che la proprietà age è rappresentata dalla variabile di istanza yearsOld.

Se specifichi o no il nome della variabile di istanza, @synthesize può solo usare una variabile di istanza dalla classe corrente, non una superclasse.

Ci sono differenze nel comportamento che dipendono dal runtime:

Per i runtime a eredità, le variabili di istanza devono già essere dichiarate nel blocco @interface della classe corrente. Se una variabile di istanza dello stesso nome e di tipo compatibile a quello della proprietà esiste, è usata - altrimenti, otterrai un errore di compilazione.
Per i runtime moderni, le variabili di istanza sono sintetizzate come serve. Se esiste già una variabile di istanza con lo stesso nome, è usata.

@dynamic
Si usa la parola chiave @dynamic per dire al compilatore che adempirete al contratto delle API implicito da una proprietà o fornendo implementazioni di metodi direttamente, o a runtime usando altri meccanismi come il caricamento dinamico del codice o risoluzione di metodo dinamico. L'esempio mostrato nel listato 5-3 illustra l'uso delle implementazioni dirette di metodo - equivalente all'esempio del listato 5-2.

Listato 5-3 Usare @dynamic con implementazioni dirette di metodo

@interface MyClass : NSObject

{

NSString *value;

}

@property(copy, readwrite) NSString *value;

@end

// assume using garbage collection

@implementation MyClass

@dynamic value;

- (NSString *)value {

return value;

}

- (void)setValue:(NSString *)newValue {

if (newValue != value) {

value = [newValue copy];

}

}

@end

Usare le Proprietà

Tipi Supportati

Puoi dichiarare una proprietà per qualunque classe Objective-C, tipo di dati Core Foundation o tipi "plain old data" (POD).

Ri-dichiarazione di Proprietà

Puoi re-dichiarare una proprietà in una sottoclasse, ma (ad eccezione di readonly contro readwrite) devi ripetere i suoi attributi per intero nelle sottoclassi. Vale lo stesso per una proprietà dichiarata in una categoria o in un protocollo - mentre le proprietà possono essere re-dichiarate in una categoria o protocollo, gli attributi di proprietà devono essere ripetute per intero.

Se dichiari una proprietà readonly in una classe, puoi re-dichiararla come readwrite in un estensione di classe , un protocollo o una sottoclasse. Nel caso di un'estensione re-dichiarazione di classe, il fatto che la proprietà era re-dichiarata prima di ogni statement @synthesize causerà la sintetizzazione del setter. L'abilità di re-dichiarare una proprietà readonly come read/write abilita due pattern di implementazioni comuni: una sottoclasse mutabile di una classe immutabile (NSstring, NSarray, e NSDictionary sono tutti esempi) e una proprietà che ha API pubbliche che è readonly ma ha un'implementazione readwrite privata interna alla classe. Il seguente esempio mostra l'uso di un estensione di classe per fornire una proprietà che è dichiarata come readonly nell'header pubblico ma che è re-dichiarata privatamente come read/write.

// public header file

@interface MyObject : NSObject {

NSString *language;

}

@property (readonly, copy) NSString *language;

@end

// private implementation file

@interface MyObject ()

@property (readwrite, copy) NSString *language;

@end

@implementation MyObject

@synthesize language;

@end

Copy

Se usi l'attributo di dichiarazione copy, specifichi che un valore è copiato durante l'assegnamento. Se sintetizzi l'accessorio corrispondente, il metodo sintetizzato usa il metodo copy. Questo è utile per attributi come oggetti String dove c'è una possibilità che il nuovo valore passato ad un setter potrebbe essere mutabile (ad esempio, un istanza di NSMutableString) e tu vuoi assicurarti che il tuo oggetto ha la sua copia privata immutabile. Ad esempio, se dichiari una proprietà come segue:

@property (nonatomic, copy) NSString *string;

allora il metodo setter sintetizzato è simile al seguente:

-(void)setString:(NSString *)newString {

if (string != newString) {

[string release];

string = [newString copy];

}

}

Sebbene questo funzioni bene per le stringhe, potrebbe presentare un problema se l'attributo è una collezione come un array o un insieme. Tipicamente vuoi che queste collezioni siano mutabili, ma il metodo copy restituisce una versione immutabile della collezione. In questa situazione devi fornire una tua propria implementazione del metodo setter, come illustrato nel seguente esempio:

@interface MyClass : NSObject {

NSMutableArray *myArray;

}

@property (nonatomic, copy) NSMutableArray *myArray;

@end

@implementation MyClass

@synthesize myArray;

- (void)setMyArray:(NSMutableArray *)newArray {

if (myArray != newArray) {

[myArray release];

myArray = [newArray mutableCopy];

}

}

@end

dealloc

Le proprietà dichiarate fondamentalmente prendono il posto delle dichiarazioni dei metodi accessori; quando sintetizzi una proprietà il compilatore crea soltanto qualsiasi metodo accessorio assente. Non c'è interazione diretta con il metodo dealloc - le proprietà non sono automaticamente rilasciate per te. Le proprietà dichiarate forniscono un utile metodo per controllare incrociatamente l'implementazione del metodo dealloc: Puoi cercare tutte le dichiarazioni di proprietà nel tuo file header e assicurarti che le proprietà dell'oggetto NON marcate con assign siano rilasciate, e quelle marcate con assign non siano rilasciate.

Nota: Tipicamente in un metodo dealloc dovresti rilasciare variabili di istanza di un oggetto direttamente (invece che invocare un metodo accessorio set passandogli nil come parametro), come illustrato in questo esempio:

- (void)dealloc {

[property release];

[super dealloc];

}

Se stai usando il runtime moderno e sintetizzando le variabili di istanza, non puoi accedere alle variabili di istanza diretatmente, quindi devi invocare il metodo accessorio:

- (void)dealloc {

[self setProperty:nil];

[super dealloc];

}

Core Foundation

Come già detto prima, prima di Mac OS X v10.6 non si poteva specificare l'attributo retain per tipi di non-oggetti. Se, quindi dichiari una proprietà il cui tipo è un CFType (Core Foundation Type) e sintetizzi i metodi accessori come illustrato nel seguente esempio:

@interface MyClass : NSObject

{

CGImageRef myImage;

}

@property(readwrite) CGImageRef myImage;

@end

@implementation MyClass

@synthesize myImage;

@end

allora in un ambiente reference counted il metodo set generato assegnerà semplicemente il nuovo valore alla variabile di istanza (il nuovo valore non è conservato e il vecchio valore non è rilasciato). Questo è tipicamente incorretto, quindi non dovreste sintetizzare i metodi ma dovreste implementarli voi.

In un ambiente garbage collected, se la variabile è dichiarata __strong:

...

__strong CGImageRef myImage;

...

@property CGImageRef myImage;

allora gli accessori sono sintetizzati appropriatamente - l'immagine non sarà CFRetain, ma il setter attiverà una barriera di scrittura.

Esempio

Il seguente esempio illustra l'uso di proprietà in molti modi diversi:
Il protocollo Link dichiara una proprietà, next.

MyClass adotta il protocollo Link quindi dichiara implicitamente anche la proprietà next. MyClass dichiara anche diverse altre proprietà.
creationTimestamp e next sono sintetizzate ma usano variabili di istanza esistenti con nomi diversi;
name è sintetizzato, e usa sintesi di variabile di istanza (richiamare quella sintesi della variabile di istanza non è supportato dal legacy runtime;
gratuitousFloat ha una direttiva dynamic — è supportata usando l'implementazione diretta dei metodi;
nameAndAge non ha una direttiva dynamic, ma questo è il valore di default; è supportato usando un'implementazione diretta dei metodi (dato che è readonly, richiede solo un getter) con un nome specificato (nameAndAgeAsString).

Listato 5-4 Dichiarare proprietà per una classe

@protocol Link

@property id <Link> next;

@end

@interface MyClass : NSObject <Link>

{

NSTimeInterval intervalSinceReferenceDate;

CGFloat gratuitousFloat;

id <Link> nextLink;

}

@property(readonly) NSTimeInterval creationTimestamp;

@property(copy) NSString *name;

@property CGFloat gratuitousFloat;

@property(readonly, getter=nameAndAgeAsString) NSString *nameAndAge;

@end

@implementation MyClass

@synthesize creationTimestamp = intervalSinceReferenceDate, name;

// Synthesizing 'name' is an error in legacy runtimes;

// in modern runtimes, the instance variable is synthesized.

@synthesize next = nextLink;

// Uses instance variable "nextLink" for storage.

@dynamic gratuitousFloat;

// This directive is not strictly necessary.

- (CGFloat)gratuitousFloat {

return gratuitousFloat;

}

- (void)setGratuitousFloat:(CGFloat)aValue {

gratuitousFloat = aValue;

}

- (NSString *)nameAndAgeAsString {

return [NSString stringWithFormat:@"%@ (%fs)", [self name],

[NSDate timeIntervalSinceReferenceDate] - intervalSinceReferenceDate];

}

- (id)init {

if (self = [super init]) {

intervalSinceReferenceDate = [NSDate timeIntervalSinceReferenceDate];

}

return self;

}

- (void)dealloc {

[nextLink release];

[name release];

[super dealloc];

}

@end

Sottoclassi con Proprietà

Puoi sovrascrivere una proprietà readonly per renderla scrivibile. Ad esempio, potresti definire una classe MyInteger con una proprietà readonly, value:

@interface MyInteger : NSObject

{

NSInteger value;

}

@property(readonly) NSInteger value;

@end

@implementation MyInteger

@synthesize value;

@end

Potresti poi implementare una sottoclasse, MyMutableInteger, che ridefinisce la proprietà per renderla scrivibile:

@interface MyMutableInteger : MyInteger

@property(readwrite) NSInteger value;

@end

@implementation MyMutableInteger

@dynamic value;

- (void)setValue:(NSInteger)newX {

value = newX;

}

@end

Prestazioni e Threading

Se fornisci la tua implementazione dei metodi, il fatto che dichiari una proprietà non ha effetto sulla sua efficienza o sulla sicurezza del thread.

Se usi proprietà sintetizzate, le implementazioni di metodo generate dal compilatore dipendono dalla specifica che fornisci. Gli attributi di dichiarazione che influenzano le prestazioni ed il threading sono retain, assign, copy, e nonatomic. Le prime tre influenzano soltanto la parte dell'implementazione dell'assegnamento del metodo set, come illustrato sotto (l'implementazione potrebbe non essere esattamente come mostrato):

// assign

property = newValue;

// retain

if (property != newValue) {

[property release];

property = [newValue retain];

}

// copy

if (property != newValue) {

[property release];

property = [newValue copy];

}

L'effetto dell'attributo nonatomic dipende dall'ambiente. Di default, gli accessori sintetizzati sono atomici. In un ambiente reference counted, garantire comportamenti atomici richiede l'uso di una chiusura; inoltre un oggetto restituito è conservato e autorilasciato, come abbiamo già visto precedentemente. Se tali accessori sono invocati frequentemente, questo potrebbe avere un impatto significante sulle prestazioni. In un ambiente garbage collected, la maggior parte dei metodi sintetizzati sono atomici.

È importante capire che l'obbiettivo dell'implementazione atomica è fornire robusti metodi accessori - non garantisce correttezza del codice. Sebbene "atomic" significa che l'accesso alla proprietà è thread-safe, rendere atomiche tutte le proprietà della tua classe non vuol dire che la tua classe o piu generalmente il grafico del tuo oggetto sia "thread safe" - la sicurezza del thread non può essere espressa al livello di metodi accessori individuali.

Differenze di Runtime

In generale il comportamento delle proprietà è identico su tutti i runtimes. C'è una differenza chiave: il runtime moderno supporta sintesi di variabili di istanza e il legacy runtime no.

Per far funzionare @synthesize nel legacy runtime, devi fornire una variabile di istanza con lo stesso nome e di tipo compatibile con la proprietà o specificare un altra variabile di istanza esistente nello statement @synthesize. con il runtime moderno, non fornisci una variabile di istanza, il compilatore ne aggiunge una per te. Ad esempio, data la seguente dichiarazione e implementazione di classe:

@interface MyClass : NSObject {

float sameName;

float otherName;

}

@property float sameName;

@property float differentName;

@property float noDeclaredIvar;

@end

@implementation MyClass

@synthesize sameName;

@synthesize differentName=otherName;

@synthesize noDeclaredIvar;

@end

Il compilatore per il runtime legacy dovrebbe generare un errore a @synthesize noDeclaredIvar; considerando che il compilatore per il runtime moderno aggiungerebbe una variabile di istana per rappresentare noDeclaredIvar.

Fine Sesta Parte

Finisce qui il sesto articolo di questa Guida dedicato alle Proprietà Dichiarate delle classi del linguaggio di programmazione Objective-C. Spero col tempo di realizzare un'utile manuale disponibile a tutti. Il prossimo post di questa guida, tratterà le Categorie e le Estensioni. Segnalatemi eventuali errori, o commentate l'articolo se l'avete trovato utile, anche per incentivarmi a continuare a pubblicare le mie traduzioni. Iscrivetevi ai feed del blog per essere sempre aggiornati automaticamente ogni volta che sono disponibili nuovi contenuti. nella colonna a destra di questo blog potete trovare tutti i link agli articoli di questa guida.

Guida Objective-C in Italiano - Parte 5 - I Protocolli

noreply@blogger.com (Unknown) — Mon, 19 Apr 2010 20:59:00 +0000

Siamo arrivati alla quinta parte della Guida all'Objective-C, negli articoli precedenti abbiamo parlato a lungo dei concetti base del linguaggio quali, gli Oggetti, le Classi, la definizione di Classi e Interfacce, e l'inizializzazione degli Oggetti. Oggi vi faremo luce su tutti gli aspetti di un utile strumento di questo linguaggio che è rappresentato dai Protocolli.

Ricordo che il presente post è una traduzione in italiano della Guida all'Objective C, presente sul sito developer.apple.com a questo link. L'Objective C è il linguaggio di programmazione per creare applicazioni per iPhone. Questa guida potrebbe interessare a tutti gli sviluppatori che vogliono imparare le basi di questo linguaggio che è il fondamento per programmare nuove applicazioni per Mac Os X, iPhone ed iPad.

Protocolli

I protocolli dichiarano metodi che possono essere implementati in ogni classe. I protocolli sono utili in almeno tre situazioni:

Per dichiarare metodi che altri pensano di implementare
Per dichiarare l'interfaccia a un oggetto e nasconderla alla sua classe
Per catturare similarità tra le classi che non sono correlate gerarchicamente.

Dichiarare Interfacce da far implementare agli altri

Classe e categoria di interfacce dichiarano metodi che sono associati con una classe particolare - metodi principali che la classe implementa. Protocolli formali e informali, d'altro canto, dichiarano metodi che sono indipendenti da qualunque classe specifica, ma che qualunque classe, e forse molte classi, potrebbero implementare.

Un protocollo è semplicemente una lista di dichiarazioni di metodi, non allegate ad una definizione di classe. Per esempio, questi metodi che riportano azioni dell'utente sul mouse, potrebbero essere raggruppati in un protocollo:

- (void)mouseDown:(NSEvent *)theEvent;

- (void)mouseDragged:(NSEvent *)theEvent;

- (void)mouseUp:(NSEvent *)theEvent;

Ogni classe che vuole rispondere ad eventi del mouse dovrebbe adottare il protocollo e implementare i suoi metodi.

I protocolli liberano le dichiarazioni dei metodi dalla dipendenza dalla gerarchia di classe, così che possono essere usate in modi in cui classi e categorie non possono. I protocolli elencano metodi che sono (o possono essere) implementati da qualche parte, ma l'identità della classe che li implementa non è di interesse. Cosa è di interesse o meno è una particolare classe conforme al protocollo - se ha implementato dei metodi che il protocollo dichiara. Così gli oggetti possono essere raggruppati in tipi, non solo su basi di somiglianza dovute al fatto che ereditano dalla stessa classe, ma anche sulla base della loro somiglianza in conformazione allo stesso protocollo. Le classi in rami non collegati della gerarchia ereditaria, potrebbero essere tipate ugualmente perché sono conformi allo stesso protocollo.

I protocolli possono giocare un ruolo significante nella progettazione OO, specialmente quando un progetto è diviso tra più implementatori o se incorpora oggetti sviluppati in altri progetti. Il software Cocoa usa pesantemente i protocolli per supportare la comunicazione tra i processi attraverso i messaggi Objective-C.

Comunque, un programma Objective-C non ha bisogno di usare protocolli. A differenza della definizione di classi e le espressioni di messaggi, sono opzionali. Alcuni frameworks Cocoa li usano; altri no. Dipende tutto dal compito attuale.

Metodi per gli altri da implementare.

Se conosci la classe di un oggetto, puoi guardare la sua dichiarazione di interfaccia ( e le dichiarazioni delle interfacce delle classi da cui eredita) per trovare a quali messaggi risponde. Queste dichiarazioni annunciano i messaggi che ricevono. I protocolli forniscono anche un modo per fargli annunciare i messaggi che inviano.

La comunicazione funziona in entrambi i modi; oggetti inviano messaggi così come lì ricevono. Ad esempio, un oggetto potrebbe delegare responsabilità per una certa operazione ad un altro oggetto, o potrebbe in occasione semplicemente aver bisogno di chiedere informazioni ad un altro oggetto. In alcuni casi, un oggetto potrebbe voler notificare ad altri oggetti le sue azioni così che loro possano prendere qualsiasi misura collaterale che potrebbe essere richiesta.

Se sviluppi la classe di un sender e la classe di un receiver come parte dello stesso progetto (o se qualcun altro ti ha fornito il ricevitore e i suoi file interfaccia), questa comunicazione è facilmente coordinata. Il sender semplicemente importa il file interfaccia del receiver. Il file importato dichiara i selettori di metodo che il sender usa nei messaggi che invia.

Comunque, se sviluppi un oggetto che invia messaggi a oggetti che non sono definiti - oggetti che stai lasciando agli altri da implementare - non vuoi avere il file di interfaccia del ricevente. Vi serve un altro modo di dichiarare i metodi che usate nei messaggi ma che non implementate. Un protocollo serve a questo scopo. Informa il compilatore riguardo ai metodi che la classe usa informa anche gli altri implementatori dei metodi che hanno bisogno di definire per avere i loro oggetti che lavorano con i tuoi.

Supponiamo, ad esempio, che sviluppi un oggetto che chiede l'assistenza di un altro oggetto inviandogli il messaggio helpOut: ed altri messaggi. Fornisci una variabile di istanza assistant per memorizzare l'outlet per questi messaggi e definire un metodo compagno per impostare la variabile di istanza. Questo metodo permette agli altri oggetti di registrarsi come potenziali destinatari per i messaggi del tuo oggetto:

- setAssistant:anObject

{

assistant = anObject;

}

Allora, ogni volta che un messaggio sta per essere inviato ad assistant, è fatto un controllo per accertarsi che il ricevente implementi un metodo che possa rispondere:

- (BOOL)doWork

{

...

if ( [assistant respondsToSelector:@selector(helpOut:)] ) {

[assistant helpOut:self];

return YES;

}

return NO;

}

Dato che, quando hai scritto questo codice, non potevi sapere che tipo di oggetti avrebbero potuto registrarsi come assistant, puoi solo dichiarare un protocollo per il metodo helpOut:; non puoi importare il file interfaccia della classe che lo implementa.

Dichiarare Interfacce per Oggetti Anonimi

Un protocollo può essere usato per dichiarare i metodi di un oggetto anonimo, un oggetto di classe sconosciuta. Un oggetto anonimo può rappresentare un servizio o gestire un insieme limitato di funzioni, specialmente dove serve un solo grande oggetto della sua classe. (Oggetti che giocano un ruolo fondamentale nel definire l'architettura di un'applicazione e oggetti che devi inizializzare prima di usare non sono buoni candidati per l'anonimità).

Gli oggetti non sono anonimi al loro sviluppatore, ovviamente, ma sono anonimi quando lo sviluppatore fornisce loro a qualcun altro. Ad esempio, considera le seguenti situazioni:

Qualcuno che fornisce un framework o una suite di oggetti ad altri da usare può includere oggetti che non sono identificati da un nome di classe o un file interfaccia. Mancando nome e interfaccia di classe, gli utenti non hanno modo di creare istanze della classe. Invece, il fornitore deve fornire un'istanza pronta fatta. Tipicamente, un metodo in un'altra classe restituisce un oggetto usabile:

id formatter = [receiver formattingService];

 L'oggetto restituito dal metodo è un oggetto senza un'identità di classe, almeno non uno dei fornitori è disposto a rivelare. Affinchè sia utile, il fornitore deve voler identificare almeno alcuni dei messaggi a cui esso può rispondere. Questo è fatto associando l'oggetto con una lista di metodi dichiarati in un protocollo.
Puoi inviare messaggi Objective-C a oggetti remoti - oggetti in altre applicazioni. Ogni applicazione ha la sua propria struttura, classi e logica interna. Ma non ti serve sapere come un'altra applicazione funziona o con cosa i suoi componenti stanno comunicando. Da straniero, tutto quello che devi sapere è quali messaggi puoi inviare (il protocollo) e dove inviarli (il ricevente). Un'applicazione che pubblica uno dei suoi oggetti come potenziale ricevente di messaggi remoti, deve anche pubblicare un protocollo che dichiara i metodi che l'oggetto userà per rispondere a quei messaggi. Non deve rivelare nient'altro che l'oggetto. L'applicazione che invia non ha bisogno di conoscere la classe dell'oggetto o usare la classe nel suo proprio design Tutto ciò che gli serve è il protocollo.

I protocolli rendono possibili gli oggetti anonimi. Senza un protocollo, non ci sarebbe modo di dichiarare un'interfaccia a un oggetto senza identificare la sua classe.

Nota: anche se il fornitore di un oggetto anonimo non rivela la sua classe, l'oggetto stesso si rivela a runtime. Un messaggio di classe restituisce la classe dell'oggetto anonimo. Comunque, c'è solitamente poco punto nel cercare queste informazioni extra; L'informazione nel protocollo è sufficiente.

Somiglianze Non-Gerarchiche

Se più di una classe implementasse un insieme di metodi, quelle classi sarebbero spesso raggruppate sotto una classe astratta che dichiara i metodi che hanno in comune. Ogni sottoclasse potrebbe re-implementare i metodi a modo proprio, ma la gerarchia ereditaria e la dichiarazione in comune nella classe astratta cattura la somiglianza essenziale tra le sottoclassi.
Comunque, a volte non è possibile raggruppare metodi in comune in una classe astratta. Le classi non correlate in molti aspetti, che non potrebbero tuttavia aver bisogno di implementare alcuni metodi simili. Questa somiglianza singolare potrebbe non giustificare una relazione gerarchica. Ad esempio, potresti volere aggiungere un supporto per creare una rappresentazione XML degli oggetti nella tua applicazione e per inizializzare oggetti da una rappresentazione XML:

- (NSXMLElement *)XMLRepresentation;

- initFromXMLRepresentation:(NSXMLElement *)xmlString;

Questi metodi potrebbero essere raggruppati in un protocollo e le somiglianze tra le classi che lo implementano stimate per annotare che sono tutte conformi allo stesso protocollo.

Gli oggetti possono essere tipati a seconda delle somiglianze (i protocolli a cui sono conformi), piuttosto che a seconda della loro classe. Ad esempio, un'istanza di NSMatrix deve comunicare con gli oggetti che rappresentano le sue celle. La matrice potrebbe richiedere che ognuno di questi oggetti sia un tipo di NSCell (una classe basata su tipo) e affidarsi al fatto che tutti gli oggetti che eredita dalla classe NSCell hanno metodi che hanno bisogno di rispondere a messaggi di NSMatrix. Alternativamente, l'oggetto NSMatrix potrebbe richiedere che oggetti rappresentanti celle abbiano metodi che possono a rispondere a un particolare insieme di messaggi (un tipo basato su protocollo). In questo caso, l'oggetto NSMatrix non si preoccuperebbe di a quale classe appartiene un oggetto cella, appena ha implementato i metodi.

Protocolli Formali

Il linguaggio Objective-C fornisce un modo di dichiarare formalmente una lista di metodi come un protocollo. I protocolli formali sono supportati dal linguaggio e dal sistema di runtime. Ad esempio, il compilatore può controllare i tipi basati su protocolli, e gli oggetti possono introspezionare a runtime per riportare se sono o non sono conformi a un protocollo.

Dichiarare un Protocollo

I protocolli formali si dichiarano con la direttiva @protocol :

@protocol ProtocolName

method declarations

@end

Ad esempio, puoi dichiarare un protocollo di rappresentazione XML in questo modo:

@protocol MyXMLSupport

- initFromXMLRepresentation:(NSXMLElement *)XMLElement;

- (NSXMLElement *)XMLRepresentation;

@end

Diversamente dai nomi di classi, i nomi dei protocolli non hanno visibilità globale. Vivono nel loro proprio namespace.

Metodi di Protocolli Opzionali

I metodi dei protocolli possono essere segnati come opzionali usando la parola chiave @optional. La parola chiave @required, corrisponde a @optional e denota formalmente la semantica del comportamento di default. Puoi usare @optional e @required per partizionare il tuo protocollo in sezioni. Se non specifichi alcuna parola chiave, è richiesto @required.

@protocol MyProtocol

- (void)requiredMethod;

@optional

- (void)anOptionalMethod;

- (void)anotherOptionalMethod;

@required

- (void)anotherRequiredMethod;

@end

Nota: In Mac OS X v10.5, i protocolli potrebbero non includere le proprietà dichiarate opzionali. Questo vincolo è rimosso da Mac OS X v10.6 in poi.

Protocolli Informali

In aggiunta ai protocolli formali, puoi anche definire un protocollo informale raggruppando i metodi in dichiarazioni di categoria:

@interface NSObject ( MyXMLSupport )

- initFromXMLRepresentation:(NSXMLElement *)XMLElement;

- (NSXMLElement *)XMLRepresentation;

@end

I protocolli informali sono tipicamente dichiarati come categorie della classe NSObject, dato che associano largamente i nomi dei metodi con qualunque classe che eredita da NSObject. Dato che tutte le classi ereditano dalla classe radice, i metodi non sono ristretti ad alcuna parte della gerarchia. (Potrebbe anche essere possibile dichiarare un protocollo informale come categoria di un'altra classe per limitarlo a un certo ramo della gerarchia, ma ci sono poche ragioni per farlo).

Una volta usato per dichiarare un protocollo, un'interfaccia di categoria non ha un'implementazione corrispondente. Invece, le classi che implementano il protocollo dichiarano ancora i metodi nei loro propri files di interfaccia e li definiscono insieme con gli altri metodi nei loro files di implementazione.

Un protocollo informale piega le regole delle dichiarazioni di categoria per elencare un gruppo di metodi ma non associarli ad alcuna classe o implementazione particolare.

Per essere informali, i protocolli dichiarati nelle categorie non ricevono molto supporto dal linguaggio. Non ci sono controlli di tipo a tempo di compilazione e neanche un controllo a runtime per vedere se un oggetto è conforme al protocollo. Per ottenere questi benefici, dovete usare un protocollo formale. Un protocollo informale potrebbe essere utile quando tutti i metodi sono opzionali, come per un delegato, ma è tipicamente meglio usare un protocollo formale con i metodi opzionali.

Oggetti dei Protocolli

Proprio come le classi sono rappresentate a runtime dagli oggetti della classe e i metodi dai codici selettori, i protocolli formali sono rappresentati da una speciale istanza-tipo di dati della classe Protocol. Il codice sorgente che si occupa del protocollo deve riferirsi all'oggetto di Protocol.

In molti modi, i protocolli sono simili alle definizioni di classe. Entrambi dichiarano metodi, e a runtime entrambi sono rappresentati da oggetti - classi da oggetti Class e protocolli da oggetti Protocol. Come gli oggetti di classe, gli oggetti di protocollo sono creati automaticamente dalle definizioni e le dichiarazioni trovate nel codice sorgente e sono usati dal sistema di runtime. Non sono allocati e inizializzati in codice sorgente programma.

Il codice sorgente può riferirsi a un oggetto protocollo usando la direttiva @protocol( ) - la stessa direttiva che dichiara un protocollo, tranne che qui ha un insieme di parentesi tonde. Le parentesi racchiudono il nome del protocollo:

Protocol *myXMLSupportProtocol = @protocol(MyXMLSupport);

Questo è l'unico modo per il codice sorgente di evocare un oggetto Protocol. Diversamente da un nome di classe, un nome di protocollo non designa l'oggetto - tranne dentro @protocol( ).

Il compilatore crea un oggetto Protocol per ogni dichiarazione di protocollo che incontra, ma solo se il protocollo è anche:

Adottato da una classe, o
Riferito a qualche punto nel codice sorgente (usando @protocol( ) )

I protocolli che sono dichiarati ma non usati (tranne per il controllo dei tipi descritto sotto) non sono rappresentati da oggetti Protocol a runtime.

Adottare un Protocollo

Adottare un protocollo è simile in alcuni modi a dichiarare una superclasse. Entrambi i metodi definiscono alla classe. La dichiarazione di superclasse gli assegna i metodi ereditati; Il protocollo gli assegna metodi dichiarati nella lista del protocollo. Si dice che una classe adotta un protocollo formale se nella sua dichiarazione, elenca il protocollo tra parentesi angolari dopo il nome della superclasse:

@interface ClassName : ItsSuperclass < protocol list >

Le categorie adottano protocolli più o meno allo stesso modo:

@interface ClassName ( CategoryName ) < protocol list >

Una classe può adottare più di un protocollo; i nomi nella lista dei protocolli sono separati da virgole.

@interface Formatter : NSObject < Formatting, Prettifying >

Una classe o categoria che adotta un protocollo deve implementare tutti i metodi richiesti che il protocollo dichiara, altrimenti il compilatore emetterà un warning La classe Formatter sopra, definirebbe tutti i metodi richiesti dichiarati nei due protocolli che adotta, in aggiunta a qualunque potrebbe dichiarare lui stesso.

Una classe o categoria che adotta un protocollo deve importare il file header dove il protocollo è dichiarato. I metodi dichiarati nel protocollo adottato non sono dichiarati altrove nell'interfaccia di classe o categoria.

é possibile per una classe adottare semplicemente protocolli e dichiarare nessun altro metodo. Ad esempio, la seguente dichiarazione di classe adotta i protocolli Formatti e Prettyfying, ma di per se non dichiara variabili di istanza o metodi:

@interface Formatter : NSObject < Formatting, Prettifying >

@end

Conformarsi a un Protocollo

Si dice che una classe è conforme a un protocollo formale se adotta il protocollo o eredita da altre classi che lo adottano. Un'istanza della classe è detta conforme allo stesso insieme di protocolli a cui è conforme la sua classe.

Dato che una classe deve implementare tutti i metodi richiesti dichiarati nel protocollo che adotta, dicendo che una classe o un'istanza è conforme a un protocollo è equivalente a dire che ha nel suo repertorio tutti i metodi che il protocollo dichiara.

È possibile controllare se un oggetto è conforme ad un protocollo inviandogli il messaggio conformsToProtocol:

if ( ! [receiver conformsToProtocol:@protocol(MyXMLSupport)] ) {

// Object does not conform to MyXMLSupport protocol

// If you are expecting receiver to implement methods declared in the

// MyXMLSupport protocol, this is probably an error

}

(Nota che c'è anche un metodo di classe con lo stesso nome —conformsToProtocol: .)

Il test conformsToProtocol: è come il test respondsToSelector: per un singolo metodo, tranne che testa se un protocollo è stato adottato ( e presumibilmente tutti i metodi che dichiara sono implementati) piuttosto che solo se un particolare metodo è stato implementato. Poiché controlla tutti i metodi, conformsToProtocol: può essere più efficiente rispetto a respondsToSelector:.

Il test conformsToProtocol: è anche come il test isKindOfClass:, tranne per il fatto che testa su un tipo basato su un protocollo piuttosto che su un tipo basato su gerarchia ereditaria.

Controlli di Tipo

Le dichiarazioni di tipo per gli oggetti possono essere estese per includere protocolli formali. I protocolli così offrono la possibilità di un altro livello di controllo di tipi da parte del compilatore, uno che è più astratto dato che non è legato ad una particolare implementazione.
In una dichiarazione di tipo, i nomi dei protocolli sono elencati tra parentesi angolari dopo il nome del tipo:

- (id )formattingService;

id anObject;

Proprio come la tipatura satica permette al compilatore di testare su un tipo basato su gerarchia di classi, questa sintassi permette al compilatore di testare su un tipo basato sulla conformità ad un protocollo.

Ad esempio, se Formatter è una classe astratta, questa dichiarazione

Formatter *anObject;

raggruppa tutti gli oggetti che ereditano da Formatter in un tipo, e permette al compilatore di controllare gli assegnamenti contro quel tipo.

Analogamente, questa dichiarazione,

id anObject;

raggruppa tutti gli oggetti conformi al protocollo Formatting in un tipo, senza tener conto della loro posizione nella gerarchia delle classi. Il compilatore può accertarsi che solo gli oggetti conformi al protocollo siano assegnati al tipo.

In ogni caso, il tipo raggruppa oggetti simili - in ogni caso, perché condividono un'eredità comune, o perché convergono ad un comune insieme di metodi.

I due tipi possono essere combinati in una dichiarazione singola:

Formatter *anObject;

I protocolli non possono essere usati per tipare gli oggetti delle classi. Solo le istanze possono essere tipate staticamente ad un protocollo, proprio come ogni istanza può essere staticamente tipata ad una classe. (comunque, a runtime, sia le classi che le istanze risponderanno ai messaggi conformsToProtocol:).

Protocolli all'interno di Protocolli

Un protocollo può incorporare altri protocolli usando la stessa sintassi che le classi usano per adottare un protocollo:

@protocol ProtocolName < protocol list >

Tutti i protocolli elencati tra le parentesi angolari sono considerati parte del protocollo ProtocolName. Ad esempio se il protocollo Paging incorpora il protocollo Formatting,

@protocol Paging < Formatting >

qualsiasi oggetto conforme al protocollo Paging è conforme anche a Formatting. Dichiarazione di tipi

id someObject;

e messaggi conformsToProtocol:

if ( [anotherObject conformsToProtocol:@protocol(Paging)] )

...

hanno bisogno di menzionare solo il protocollo Paging per testare anche la conformità di Formatting.

Quando una classe adotta un protocollo, deve implementare i metodi richiesti che il protocollo dichiara, come abbiamo detto prima. In aggiunta, deve conformarsi a qualunque protocollo che il protocollo adottato incorpora. Se un protocollo incorporato incorpora ancora altri protocolli, la classe deve anche conformarsi a loro. Una classe può conformarsi ad un protocollo incorporato tramite o uno o l'altro di questi modi:

Implementando i metodi che il protocollo dichiara, o
ereditando da una classe che adotta il protocollo ed implementa i metodi.

Supponiamo, ad esempio, che la classe Pager adotti il protocollo Paging. Se Pager fosse una sottoclasse di NSObject,

@interface Pager : NSObject < Paging >

dovrebbe implementare tutti i metodi di Paging, inclusi quelli dichiarati nel protocollo incorporato Formatting. Adotta il protocollo Formatting insieme con Paging.

D'altro lato, se Pager è una sottoclasse di Formatter (una classe che indipendentemente adotta il protocollo Formatting),

@interface Pager : Formatter < Paging >

deve implementare adeguatamente tutti i metodi dichiarati nel protocollo Paging, ma non quelli dichiarati in Formatting. Pager eredita la conformità al protocollo Formatting da Formatter.

Nota che una classe può essere conforme a un protocollo senza adottarlo formalmente, semplicemente implementando i metodi dichiarati nel protocollo.

Referring to Other Protocols

Quando lavorando su applicazioni complesse, occasionalmente vi troverete a scrivere codice che assomiglia a questo:

#import "B.h"

@protocol A

- foo:(id <B>)anObject;

@end

dove il protocollo B è dichiarato così:

#import "A.h"

@protocol B

- bar:(id <A>)anObject;

@end

In una tale situazione, risulta la circolarità e nessun file compilerà correttamente. Per rompere questo ciclo ricorsivo, devi usare la direttiva @protocol per fare un riferimento anticipato al protocollo richiesto invece di importare il file interfaccia dove è definito il protocollo. Il seguente codice illustra come potresti farlo:

@protocol B;

@protocol A

- foo:(id <B>)anObject;

@end

Nota che usando la direttiva @protocol in questa maniera semplicemente si informa il compilatore che "B" è un protocollo che sarà definito successivamente. Non importa il file interfaccia dove è definito il protocollo B.

Fine quinta parte

E siamo alla fine del quinto articolo di questa Guida dedicato ai Protocolli del linguaggio di programmazione Objective-C. Spero col tempo di realizzare un'utile manuale disponibile a tutti. Il prossimo post di questa guida, tratterà la dichiarazione e l'implementazione di proprietà. Segnalatemi eventuali errori, o commentate l'articolo se l'avete trovato utile, anche per incentivarmi a continuare a pubblicare le mie traduzioni. Iscrivetevi ai feed del blog per essere sempre aggiornati automaticamente ogni volta che sono disponibili nuovi contenuti.

Guida Objective-C in Italiano - Allocare e Inizializzare Oggetti

noreply@blogger.com (Unknown) — Fri, 16 Apr 2010 15:31:00 +0000

Questo è il quarto articolo della serie Guida all'Objective-C, finora abbiamo introdotto i concetti base del linguaggio quali, gli Oggetti, le Classi, e la definizione di Classi e Interfacce. L'argomento trattato oggi è l'allocazione e l'inizializzazione degli Oggetti.

Questo post è una traduzione in italiano della Guida all'Objective C, presente sul sito developer.apple.com a questo link. L'Objective C è il linguaggio di programmazione per creare applicazioni per iPhone. Questa guida potrebbe interessare a tutti gli sviluppatori che vogliono imparare le basi di questo linguaggio che è il fondamento per programmare nuove applicazioni per Mac Os X, iPhone ed iPad.

Allocare e Inizializzare Oggetti

Ci vogliono due passi per creare un oggetto usando Objective-C. Bisogna:

Dinamicamente allocare memoria per il nuovo oggetto
Inizializzare la nuova memoria allocata a valori appropriati

Un oggetto non è pienamente funzionale finché entrambi i passi sono stati completati. Ogni passo è compiuto da un metodo separato ma si può anche fare tutto in una singola linea di codice:

id anObject = [[Rectangle alloc] init];

Separare l'allocazione dall'inizializzazione vi da il controllo individuale su ogni passo in modo che ognuno può essere modificato indipendentemente dall'altro. Le sezioni seguenti badano prima all'allocazione e poi all'inizializzazione, e discutono come sono controllate e modificate.

In Objective-C, la memoria per nuovi oggetti è allocata usando metodi di classe definiti nella classe NSObject. NSObject definisce due metodi principali per questo scopo, alloc e allocWithZone:.

Questi metodi allocano abbastanza memoria per tenere tutte le variabili di istanza per un oggetto che appartiene alla classe ricevente. Non hanno bisogno di essere sovrascritti e modificati in sottoclassi.

I metodi alloc ed allocWithZone: inizializzano una variabile di istanza isa di un oggetto nuovamente allocato, in modo che punta alla classe dell'oggetto (l'oggetto della classe). Tutte le altre variabili di istanza sono impostate a 0 Di solito un oggetto ha bisogno di essere inizializzato più specificatamente prima di poter essere usato in modo sicuro.

Questa inizializzazione è la responsabilità di metodi di istanza specifici di classe che, per convenzione, iniziano con l'abbreviazione "init". Se il metodo non prende argomenti, il nome del metodo è giusto queste quattro lettere "init". Se prende argomenti, etichettare gli argomenti con il prefisso init. Ad esempio un oggetto NSView può essere inizializzato con un metodo initWithFrame:.

Ogni classe che dichiara variabili di istanza dovrebbe fornire un metodo init per inizializzarle. La classe NSObject dichiara la variabile isa e definisce un metodo init. Comunque, dato che isa è inizializzata quando è allocata memoria per un oggetto, tutto il metodo init di NSObject, fa e restituisce self NSObject dichiara il metodo principale per stabilire la convenzione per i nomi descritta prima.

L'Oggetto Restituito

Un metodo init normalmente inizializza le variabili di istanza del ricevente, poi le restituisce. é responsabilità del metodo restituire un oggetto che può essere usato senza errori.

Comunque, in alcune classi, questa responsabilità può restituire un oggetto diverso dal ricevente. Per esempio, se una classe mantiene una lista di oggetti nominati, potrebbe fornire un metodo initWitnName: per inizializzare le nuove istanze. Se ci possono essere non più di un oggetto per nome, initWithName: potrebbe rifiutarsi di assegnare lo stesso nome a due oggetti. Quando chiesto di assegnare a una nuova istana, un nome già usato da un altro oggetto, potrebbe liberare la nuova istanza allocata e restituire l'altro oggetto - così da assicurare l'unicità del nome mentre allo stesso tempo fornire cosa era stato chiesto, un'istanza con il nome richiesto.

In pochi casi, potrebbe essere impossibile per un metodo init fare cosa gli viene chiesto di fare. Ad esempio, un metodo initFromFile: potrebbe prendere i data che gli servono da un file passato come argomento. Se il nome del file passato non corrisponde ad u file attuale, non sarebbe in grado di completare l'inizializzazione. In casi come questo, il metodo init, potrebbe liberare il ricevente e restituire nil, indicando che l'oggetto richiesto non può essere creato.

Dato che un metodo init potrebbe restituire un oggetto diverso dal nuovo ricevente allocato, o anche restituire nil, è importante che i programmi usino il valore restituito dal metodo inizializzazione, non solo quelli ritornati da alloc o allocWithZone:. Il codice seguente è molto pericoloso, dato che ignora il valore di ritorno di init.

id anObject = [SomeClass alloc];

[anObject init];

[anObject someOtherMessage];

Invece, per inizializzare in modo sicuro un oggetto, dovreste combinare messaggi di allocazione e inizializzazione in una linea di codice.

id anObject = [[SomeClass alloc] init];

[anObject someOtherMessage];

Se c'è una possibilità che il metodo init possa restituire nil, allora dovresti controllare il valore restituito prima di procedere:

id anObject = [[SomeClass alloc] init];

if ( anObject )

[anObject someOtherMessage];

else

...

Implementare un Inizializzatore

Quando un nuovo oggetto è creato, tutti i bit di memoria (tranne per l'isa) - e quindi i valori per tutte le variabili di istanza - sono impostati a 0. In alcune situazioni, questo potrebbe essere tutto ciò che ti serve quando un oggetto è inizializzato; in molte altre, vuoi fornire altri valori di default per una variabile di istanza di un oggetto, o vuoi passare valori come argomenti all'inizializzatore. In questi altri casi, ti servirà scrivere un inizializer personalizzato. In Objective-C, gli inizializzatori personalizzati sono soggetti a più vincoli e convenzioni rispetto alla maggior parte degli altri metodi.

Vincoli e Convenzioni

Ci sono molti vincoli e convenzioni che si applicano ai metodi inizializzatori e che non si applicano agli altri metodi:

Da convenzione, il nome di un inizializzatore personalizzato inizia con init. Esempi dal framework Foundation includono, initWithFormat:, initWithObjects:, e initWithObjectAndKeys:.
Il tipo restituito di un metodo inizializzatore dovrebbe essere id. Il motivo di questo è che id da un'indicazione che la classe ha uno scopo non considerato espressamente - che la classe è nonspecificata e il soggetto cambia, a seconda del contesto dell'invocazione. Ad esempio, NSString fornisce un metodo initWithFormat:. Quando è inviato a un'istanza di NSMutableString (una sottoclasse di NSString), il messaggio restituisce un'istanza di NSMutableString, non di NSString.
Nell'implementazione di un inizializzatore personalizzato, dovete invocare per ultimo un inizializzatore designato. Gli inizializzatori designati saranno descritti in seguito. In breve, se stai implementando un nuovo inizializzatore designato, lui deve invocare l'inizializzatore designato della superclasse. Se stai implementando in qualunque altro inizializzatore, lui dovrebbe invocare l'inizializzatore designato della sua propria classe, o un altro del suo proprio inizializzatore che in ultimo invoca l'inizializzatore designato. Da default (come con NSObject), l'inizializzatore designato è init.
Dovresti assegnare self al valore restituito dall'inizializzatore. Questo perchè l'inizializzatore potrebbe restituire un oggetto diverso dal ricevente originale.
Se imposti il valore di una variabile di istanza, lo fai tipicamente usando un assegnamento diretto piuttosto che un metodo accessorio. Questo evita la possibilità di innescare effetti collaterati indesiderati negli accessori.
Alla fine dell'inizializzatore, dovete restituire self, ameno che l'inizializzatore fallisce, nel qual caso restituirete nil. Gli inizializzatori falliti saranno discussi più in dettaglio in seguito.

Il seguente esempio illustra l'implementazione di un inizializzatore personalizzato per una classe che eredita da NSobject e ha una variabile di istanza creationDate, che rappresenta il momento quando un oggetto è stato creato:

- (id)init {

// Assign self to value returned by super's designated initializer

// Designated initializer for NSObject is init

if (self = [super init]) {

creationDate = [[NSDate alloc] init];

}

return self;

}

(Il motivo di usare il pattern if (self = [super init]) sarà discusso in seguito).

Un inizializzatore non ha bisogno di fornire un argomento per ogni variabile. Per esempio, se una classe richiede che le sue istanze abbiano un nome e una sorgente dati, potrebbe fornire un metodo initWithName:fromURL:, ma impostare variabili di istanza non essenziali a valori arbitrari o permettere loro di avere valori nulli impostati di default. Potrebbe allora affidarsi a metodi come setEnabled:, setFriend:, e setDimensions: per modificare i valori di default dopo che la fase di inizializzazione è stata completata.

L'esempio succesivo illustra l'implementazione di un inizializzatore personalizzato che prende un singolo argomento. In questo caso, la classe eredita da NSView. Mostra che puoi svolgere del lavoro prima di invocare l'inizializzatore designato della superclasse.

- (id)initWithImage:(NSImage *)anImage {

// Find the size for the new instance from the image

NSSize size = anImage.size;

NSRect frame = NSMakeRect(0.0, 0.0, size.width, size.height);

// Assign self to value returned by super's designated initializer

// Designated initializer for NSView is initWithFrame:

if (self = [super initWithFrame:frame]) {

image = [anImage retain];

}

return self;

}

Questo esempio non mostra cosa fare se ci sono problemi durante l'inizializzazione.

Gestire Fallimenti di inizializzazione

In generale, se c'è un problema durante un'inizializzazione di un metodo, dovresti chiamare [self release] e restituire nil.

Ci sono due conseguenze principali per questa politica:

Ogni oggetto, (che sia la tua propria classe, una sottoclasse, o un chiamante esterno) che riceve un nil da un metodo inizializzatore dovrebbe essere in grado di occuparsene. Nel caso spiacevole dove il chiamante ha stabilito una qualsiasi referenza esterna all'oggetto prima della chiamata,questo include annullare qualsiasi connessione.
Ti devi accertare che i metodi dealloc siano sicuri in presenza di oggetti parzialmente inizializzati.

Nota: puoi chiamare solo [self release] al punto di fallimento. Se ottieni nil dall'invocazione dell'inizializzatore della superclasse, non dovresti chiamare anche release. Dovresti semplicemente pulire ogni referenza impostata che non si occupa di deallocare e restituire nil. Questo è tipicamente gestito dal pattern di eseguire inizializzazioni dentro un blocco dipendente su un testo dei valori di ritorno dell'inizializzatore della superclasse - come visto negli esempi precedenti:

- (id)init {

if (self = [super init]) {

creationDate = [[NSDate alloc] init];

}

return self;

}

Il seguente esempio costruisce ciò che abbiamo mostrato in Vincoli e Convenzioni per mostrare come gestire valori inappropriati passati al paramtetro:

- (id)initWithImage:(NSImage *)anImage {

if (anImage == nil) {

[self release];

return nil;

}

// Find the size for the new instance from the image

NSSize size = anImage.size;

NSRect frame = NSMakeRect(0.0, 0.0, size.width, size.height);

// Assign self to value returned by super's designated initializer

// Designated initializer for NSView is initWithFrame:

if (self = [super initWithFrame:frame]) {

image = [anImage retain];

}

return self;

}

L'esempio successivo illustra la miglior pratica dove, nel caso di un problema, c'è la possibilità di restituire informazioni significative nella forma di oggetto NSError restituito da riferimento:

- (id)initWithURL:(NSURL *)aURL error:(NSError **)errorPtr {

if (self = [super init]) {

NSData *data = [[NSData alloc] initWithContentsOfURL:aURL

options:NSUncachedRead error:errorPtr];

if (data == nil) {

// In this case the error object is created in the NSData initializer

[self release];

return nil;

}

// implementation continues...

Tipicamente non dovresti usare eccezioni per significare errori di questo tipo.

Coordinare Classi

I metodi init... che una classe definisce tipicamente inizializzano solo quelle variabili dichiarate in quella classe. Le variabili di istanza ereditate sono inizializzate inviando un messaggio a super per eseguire un metodo inizializzatore definito da qualche parte più su nella gerarchia ereditaria:

- (id)initWithName:(NSString *)string {

if ( self = [super init] ) {

name = [string copy];

}

return self;

}

Il messaggio a super collega insieme i metodi inizializzatori in tutte le classi ereditate. Dato che lui viene prima, assicura che le variabili della superclasse siano inizializzate prima di quelle dichiarate nelle sottoclassi. Per esempio, un oggetto Rectangle deve essere inizializzato come NSObnect, un Graphic, e una Shape prima di essere inizializzato come un Rectangle.

La connessione tra il metodo initWithName:illustrato sopra e il metodo ereditato init che incorpora è illustrata nella Figura 3-1:

Figura 3-1 Incorporare un Metodo Inizializzatore Ereditato

Una classe deve anche assicurarsi che tutti i metodi inizializzatori ereditati funzionino. Ad esempio, se la classe A definisce un metodo init e la sua sottoclasse B definisce un initWithName:, come mostrato in figura 3-1, B deve anche accertarsi che un messaggio init inizializza con successo le istanze di B. Il modo più facile per farlo è sostituire il metodo ereditato init con una versione che invochi initWithName:, come segue:

- init {

return [self initWithName:"default"];

}

Il metodo initWithName:, vorrebbe, in cambio, invocare il metodo ereditato come mostrato prima. La Figura 3-2 include la versione di B di init.

Figura 3-2 Coprire un modello di inizializzazione ereditato

Coprire un modello di inizializzazione ereditato, rende la classe che definisci più portabile alle altre applicazioni. Se lasci scoperto un metodo ereditato, qualcun altro potrebbe usarlo per produrre istanze per la tua classe inizializzate non correttamente.

L'Inizializzatore Designato

Nell'esempio dato nel paragrafo "Coordinare Classi", initWithName: sarebbe il metodo inizializzatore designato per la sua classe (classe B). L'inizializzatore designato è il metodo in ogni classe che garantisce che le variabili di istanza designate siano inizializzate (inviando un messaggio a super per eseguire un metodo ereditato). è anche il metodo che effettua la maggior parte del lavoro, e quello che altri metodi inizializzatori invocano nella stessa classe. è una convenzione di Cocoa che l'inizializzatore designato sia sempre il metodo che permette la maggior libertà di determinare il carattere di una nuova istanza (solitamente questo è quello con più argomenti, ma non sempre).

È importante conoscere l'inizializzaore designato quando si definisce una sottoclasse. Ad esempio, supponiamo di definire una classe C, una sottoclasse di B, ed implementare un metodo initWithName:fromFile:. In aggiunta a questo metodo, dobbiamo anche accertarci che i metodi ereditati init ed initWithName: funzionino per le istanze di C. Questo può essere fatto coprendo initWithName: di B con una versione che invoca initWithName:fromFile:.

- initWithName:(char *)string {

return [self initWithName:string fromFile:NULL];

}

Per un istanza della classe C, il metodo init ereditato invoca questa nuova versione di initWithName: che invoca initWithName:fromFile:. La relazione tra questi metodi è mostrata in figura 3-3:

Figura 3-3 Coprire l'inizializzatore designato

Questa figura omette un dettaglio importante. Il metodo initWithName:fromFile:, essendo l'inizializzatore designato per la classe C, invia un messaggio a super per invocare un metodo d'inizializzazione ereditato. Ma quale dei metodi di B dovrebbe invocare, init o initWithName:? Non può invocare init, per due ragioni:

Circolarità risulterebbe (init invoca initWithName: di C, che invoca initWithName:fromFile:, che invoca dinuovo init).
Non sarà ingrado di prendere vantaggio dall'inizializzazione nella versione initWithName: di B:.

Quindi, initWithName:fromFile: deve invocare initWithName::

- initWithName:(char *)string fromFile:(char *)pathname {

if ( self = [super initWithName:string] )

...

}

Principio Generale: l'inizializzatore designato in una classe deve, tramite un messaggio a super, invocare l'iizializzatore designato nella superclasse.

Gli inizializzatori designati sono concatenati l'un l'altro tramite messaggi a super, mentre altri metodi di inizializzazione sono concatenati a inizializzatori designati tramite il messaggio self.

Figura 3-4 mostra come tutti i metodi inizializzatori nelle classi A, B e C sono collegati. Messaggi a self sono mostrati sulla sinistra e i messaggi a super sulla destra.

Figura 3-4 Initialization Chain

Nota che la versione init di B invia un messaggio a self per invocare il metodo initWithName. Quindi, quando il ricevente è un'istanza della classe B, invoca la versione initWithName: di B, e quando il ricevente è un'istanza della clase C, invoca la versione di C.

Combinare Allocazione e Inizializzazione

In Cocoa, alcune classi definiscono metodi di creazione che combinano i due passi di allocare e inizializzare per restituire nuove istanze della classe inizializzate. Questi metodi sono spesso chiamati come costruttori convenienti e tipicamente prendono la forma + nomeClasse. Ad esempio, NSStrin ha i seguenti metodi (tra gli altri):

+ (id)stringWithCString:(const char *)cString encoding:(NSStringEncoding)enc;

+ (id)stringWithFormat:(NSString *)format, ...;

In modo analogo, NSArray definisce i seguenti metodi di classe che combinano allocazione e inizializzazione:

+ (id)array;

+ (id)arrayWithObject:(id)anObject;

+ (id)arrayWithObjects:(id)firstObj, ...;

Nota che il tipo restituito da questi metodi è id. Per lo stesso motivo dei metodi inizializzatori, come discusso precedentemente.

I metodi che combinano allocazione ed inizializzazione sono particolarmente di valore se l'allocazione deve in qualche modo essere informata dall'inizializzazione. Per esempio, se i dati per l'inizializzazione sono presi da un file, e il file potrebbe contenere abbastanza dati per inizializzare più di un oggetto, sarebbe impossibile conoscere quanti oggetti sono allcoati finchè il file è aperto. in questo caso, potresti implementare un metodo listFromFile: che prende il nome del file come un argomento. Aprirebbe ilfile, vede quanti oggetti da allocare, e crea una lista di oggetti larga abbastanza da tenere tutti i nuovi oggetti. Allora allocherebbe ed inizializzerebbe gli oggetti dai dati nel file, mettendoli nella lista, e finalmente restituendo la lista.

Ha senso anche combinare allocazione ed inizializzazione in un singolo metodo se vuoi evitare il passo di allocare alla cieca la memoria per un nuovo oggetto che potresti non usare. Come detto prima, un metodo init... potrebbe sostituire a volte un altro oggetto per il ricevente. Ad esempio, quando a initWithName: è passato un nome che è già preso, potrebbe liberare il ricevente e al suo posto restituire l'oggetto a cui li nome era stato precedentemente assegnato. Questo significa, che un oggetto è allocato e liberato immediatamente senza mai essere usato.

Se il codice che determina se il ricevente dovrebbe essere inizializzato è posto nel metodo che esegue l'allocazione invece che dentro init..., puoi evitare il passo di allocare una nuova istanza quando non è necessaria.

Nel seguente esempio, il metodo soloist assicura che non c'è più di un'istanza della classe Soloist. Esso alloca ed inizializza una singola istanza condivisa:

+ (Soloist *)soloist {

static Soloist *instance = nil;

if ( instance == nil ) {

instance = [[self alloc] init];

}

return instance;

}

Nota che in questo caso il tipo restituito è Soloist *. Dato che il metodo restituisce una singola istanza condivisa, la tipatura forte è appropriata - Non ci sono aspettative che questo metodo sarà sovrascritto.

Fine quarta parte

Finisce così anche il quarto articolo di questa Guida dedicato all'allocazione e inizializzzione di oggetti nel linguaggio di programmazione Objective-C. Spero col tempo di realizzare un'utile manuale disponibile a tutti. Il prossimo post di questa guida, tratterà l'uso di protocolli. Segnalatemi eventuali errori, o commentate l'articolo se l'avete trovato utile, anche per incentivarmi a continuare a pubblicare le mie traduzioni.