Aula 14 - Miscelânea

Prévia do material em texto

Projeto de Software / Programação 3 
Miscelânea 
Márcio Ribeiro 
marcio@ic.ufal.br 
twitter.com/marciomribeiro 
2 
Imagine	
  a	
  game	
  with	
  monsters…	
  
§  With	
  few	
  monsters,	
  they	
  do	
  not	
  a5ack	
  
3 
On	
  the	
  other	
  hand…	
  
§  With	
  more	
  than	
  4	
  monsters,	
  they	
  do	
  a5ack!	
  
4 
However…	
  
§  Each	
  monster	
  needs	
  to	
  know	
  how	
  many	
  monsters	
  exist	
  
§  Let’s	
  define	
  an	
  a5ribute	
  “numberOfMonsters”	
  
public class Monster {	
	
 private int numberOfMonsters;	
		
 //...	
		
}	
Each monster will 
have a copy 
New monster? 
We should update everyone! 
StaHc	
  members	
  
6 
StaHc	
  members	
  
§  Class	
  scope,	
  instead	
  of	
  instance	
  scope	
  
§  Only	
  one	
  staHc	
  copy	
  
	
  
§  Save	
  memory	
  
7 
StaHc	
  variables	
  and	
  methods	
  
public class Monster {	
	
 public static int numberOfMonsters;	
		
 //...	
		
}	
public class Utilities {	
	
 public static Product getCheapest(List products) {	
 …	
 }	
		
 public static Product getMostExpensive(List products) {	
 …	
 }	
}	
8 
No	
  instance	
  needed	
  to	
  access	
  them…	
  
int n = Monster.numberOfMonsters;	
	
	
Math.random();	
	
	
Product p = Utilities.getCheapest(list);	
§  Since	
   they	
   have	
   class	
   scope,	
   we	
   can	
   access	
   using	
   not	
   only	
  
and	
  object,	
  but	
  also	
  using	
  the	
  class	
  name	
  
Now	
  imagine	
  a	
  CreditCard	
  
10 
CreditCard	
  payment…	
  
public class CreditCard {	
	
 public CreditCard() {	
 }	
	
 public void applyPayment(ShoppingCart shoppingCart) {	
 double total = shoppingCart.getTotalPrice();	
	 		
 System.out.println("To be paid: " + total);	
	 		
 payment(total);	
 }	
		
 private void payment(double total) {	
 System.out.println("Processing payment...");	
 } 		
}	
11 
Let	
  us	
  create	
  a	
  fake	
  ShoppingCart	
  
public class FakeShoppingCart extends ShoppingCart {	
	
 public FakeShoppingCart(int customerID) {	
 super(customerID);	
 }	
	
 public double getTotalPrice() {	
 return 1.0;	
 }	
	
}	
Product samsungTV = new TV("Samsung", 3999.99, 42);	
Product consulFridge = new Refrigerator("Consul", 2999.99, 60);	
Product brastempStove = new Stove("Brastemp", 399.99, 4);	
	 	 	 		
ShoppingCart shoppingCart4 = new FakeShoppingCart(4);	
shoppingCart4.addProduct(samsungTV);	
shoppingCart4.addProduct(consulFridge);	
shoppingCart4.addProduct(brastempStove);	
	
new CreditCard().applyPayment(shoppingCart4);	
public void applyPayment(ShoppingCart shoppingCart) {	
 double total = shoppingCart.getTotalPrice();	
	 		
 System.out.println("To be paid: " + total);	
	 		
 payment(total);	
}	
versus 
SomeHmes	
  it	
  is	
  useful	
  to	
  
forbid	
  clients	
  overriding	
  
our	
  methods...	
  
14 
Final	
  method	
  
§  A	
  final	
  method	
  cannot	
  be	
  overridden	
  by	
  subclasses	
  
§  Prevent	
   unexpected	
   behavior	
   from	
   a	
   subclass	
   altering	
   a	
  
method	
  that	
  is	
  crucial	
  to	
  the	
  system	
  
public class FakeShoppingCart extends ShoppingCart {	
	
 public double getTotalPrice() {	
 return 1.0;	
 }	
}	
public class ShoppingCart {	
	
 public final double getTotalPrice() { … }	
	
}	
15 
Final	
  class	
  
§  A	
  final	
  class	
  cannot	
  be	
  subclassed	
  
§  Reasons:	
  security	
  (again)	
  and	
  efficiency	
  
public final class String { … }	
	
	
	
public class MyString extends String { … }	
16 
Final	
  variable	
  
§  Cannot	
  be	
  modified	
  
public final class Math {	
	
 public static final double E = 2.7182818284590452354;	
	
 public static final double PI = 3.14159265358979323846;	
	 	 	
 //...	
}	
SoWware	
  Modularity	
  
18 
No	
  modularity	
  at	
  all!	
  
19 
Modularity	
  benefits	
  
1.   Parallel	
  development	
  of	
  modules	
  (separate	
  groups)	
  
2.   DrasHc	
  changes	
  in	
  one	
  module	
  does	
  not	
  affect	
  others	
  
3.   Comprehensibility	
  
From	
  “On	
  the	
  Criteria	
  to	
  be	
  used	
  in	
  Decomposing	
  Systems	
  into	
  Modules”,	
  CACM	
  1972	
  
20 
Much	
  be5er!	
  
Persistence Model 
GUI 
21 
Three-­‐Her	
  architecture	
  
GUI 
Model 
Persistence