SlideShare uma empresa Scribd logo
1 de 26
Stéphane Ducasse 1
Stéphane Ducasse
stephane.ducasse@inria.fr
http://stephane.ducasse.free.fr/
Abstract Classes
S.Ducasse 2
Goal
Abstract classes
Examples
S.Ducasse 3
Abstract Classes
• Should not be instantiated (abstract in Java)
• But can define complete methods.
• Defines a protocol common to a hierarchy of classes that
is independent from the representation choices.
• A class is considered as abstract as soon as one of the
methods to which it should respond to is not
implemented (can be a inherited one).
S.Ducasse 4
Abstract Classes in Smalltalk
• Depending of the situation, override new to produce an
error.
• No construct:Abstract methods send the message self
subclassResponsibility
• Tools check this situation and exploit it.
• Abstract classes are not syntactically different from
instantiable classes, but a common convention is to use
class comments: So look at the class comment and write
in the comment which methods are abstract and should
be specialized.
S.Ducasse 5
Example
Boolean>>not
"Negation. Answer true if the receiver is false, answer false
if the receiver is true."
self subclassResponsibility
S.Ducasse 6
Goal
Abstract classes
Examples
S.Ducasse 7
Boolean Objects
false and true are objects
described by classes
Boolean,True and False
S.Ducasse 8
Conditional: messages to booleans
• aBoolean ifTrue: aTrueBlock ifFalse: aFalseBlock
• aBoolean ifFalse: aFalseBlock ifTrue: aTrueBlock
• aBoolean ifTrue: aTrueBlock
• aBoolean ifFalse: aFalseBlock
(thePacket isAddressedTo: self)
ifTrue: [self print: thePacket]
ifFalse: [super accept: thePacket]
• Hint:Take care — true is the boolean value and True is the
class of true, its unique instance!
S.Ducasse
Boolean Hierarchy
• How to implement in OO true and false without
conditional?
• Late binding: Let the receiver
• decide!
• Same message on false and true
• produces different results
S.Ducasse 10
Example
“Class Boolean is an abstract class that implements
behavior common to true and false. Its subclasses are True
and False. Subclasses must implement methods for logical
operations &, not, controlling and:, or:, ifTrue:, ifFalse:,
ifTrue:ifFalse:, ifFalse:ifTrue:”
Boolean>>not
"Negation. Answer true if the receiver is false, answer false
if the receiver is true."
self subclassResponsibility
S.Ducasse 11
Not
false not -> true
true not -> false
Boolean>>not
"Negation. Answer true if the receiver is false, answer false if
the receiver is true.”
self subclassResponsibility
False>>not
"Negation -- answer true since the receiver is false."
^true
True>>not
"Negation--answer false since the receiver is true."
^false
S.Ducasse 12
| (Or)
• true | true -> true
• true | false -> true
• true | anything -> true
• false | true -> true
• false | false -> false
• false | anything -> anything
S.Ducasse 13
Boolean>> | aBoolean
Boolean>> | aBoolean
"Evaluating disjunction (OR). Evaluate the argument.
Answer true if either the receiver or the argument is
true."
self subclassResponsibility
S.Ducasse 14
False>> | aBoolean
false | true -> true
false | false -> false
false | anything -> anything
False>> | aBoolean
"Evaluating disjunction (OR) -- answer with the
argument, aBoolean."
^ aBoolean
S.Ducasse 15
True>> | aBoolean
true | true -> true
true | false -> true
true | anything -> true
True>> | aBoolean
"Evaluating disjunction (OR) -- answer true since the
receiver is true."
^ self
S.Ducasse 16
Boolean,True and False
S.Ducasse 17
Abstract/Concrete
Abstract method
Boolean>>not
"Negation. Answer true if the receiver is false, answer false if the
receiver is true."
self subclassResponsibility
Concrete method defined in terms of an abstract
method
Boolean>>xor: aBoolean
"Exclusive OR. Answer true if the receiver is not equivalent to
aBoolean."
^(self == aBoolean) not
When not is be defined in subclasses, xor: is
automatically defined
S.Ducasse 18
Block Use in Conditional?
• Why do conditional expressions use blocks?
• Because, when a message is sent, the receiver and the
arguments of the message are always evaluated. Blocks are
necessary to avoid evaluating both branches.
S.Ducasse 19
Implementation Note
Note that theVirtual Machine shortcuts calls to
boolean such as condition for speed reason.
Virtual machines such asVisualWorks introduced a
kind of macro expansion, an optimisation for
essential methods and Just In Time (JIT)
compilation.A method is executed once and
afterwards it is compiled into native code. So the
second time it is invoked, the native code will be
executed.
S.Ducasse 20
Magnitude
I'm abstract class that represents the objects that
can be compared between each other such as
numbers, dates, numbers.
My subclasses should implement
< aMagnitude
= aMagnitude
hash
Here are some example of my protocol:
3 > 4
5 = 6
100 max: 9
7 between: 5 and: 10
S.Ducasse 21
Magnitude
Magnitude>> < aMagnitude
^self subclassResponsibility
Magnitude>> = aMagnitude
^self subclassResponsibility
Magnitude>> hash
^self subclassResponsibility
S.Ducasse 22
Magnitude
Magnitude>> <= aMagnitude
^(self > aMagnitude) not
Magnitude>> > aMagnitude
^aMagnitude < self
Magnitude>> >= aMagnitude
^(self < aMagnitude) not
Magnitude>> between: min and: max
^self >= min and: [self <= max]
S.Ducasse 23
Date
Subclass of Magnitude
Date today < Date newDay: 15 month: 10 year:
1998
-> false
S.Ducasse 24
Date
Date>>< aDate
"Answer whether the argument, aDate, precedes
the date of the rec."
year = aDate year
ifTrue: [^day < aDate day]
ifFalse: [^year < aDate year]
S.Ducasse 25
Date
Date>>= aDate
"Answer whether the argument, aDate, is the
same day as the receiver. "
self species = aDate species
ifTrue: [^day = aDate day & (year = aDate year)]
ifFalse: [^false]
Date>>hash
^(year hash bitShift: 3) bitXor: day
S.Ducasse 26
What you should know
• What is an abstract class?
• What can we do with it?

Mais conteúdo relacionado

Destaque (20)

Stoop 423-some designpatterns
Stoop 423-some designpatternsStoop 423-some designpatterns
Stoop 423-some designpatterns
 
Stoop 423-smalltalk idioms
Stoop 423-smalltalk idiomsStoop 423-smalltalk idioms
Stoop 423-smalltalk idioms
 
Stoop 305-reflective programming5
Stoop 305-reflective programming5Stoop 305-reflective programming5
Stoop 305-reflective programming5
 
Stoop 400 o-metaclassonly
Stoop 400 o-metaclassonlyStoop 400 o-metaclassonly
Stoop 400 o-metaclassonly
 
08 refactoring
08 refactoring08 refactoring
08 refactoring
 
14 - Exceptions
14 - Exceptions14 - Exceptions
14 - Exceptions
 
5 - OOP - Smalltalk in a Nutshell (c)
5 - OOP - Smalltalk in a Nutshell (c)5 - OOP - Smalltalk in a Nutshell (c)
5 - OOP - Smalltalk in a Nutshell (c)
 
Stoop 421-design heuristics
Stoop 421-design heuristicsStoop 421-design heuristics
Stoop 421-design heuristics
 
Stoop ed-unit ofreuse
Stoop ed-unit ofreuseStoop ed-unit ofreuse
Stoop ed-unit ofreuse
 
Stoop ed-dual interface
Stoop ed-dual interfaceStoop ed-dual interface
Stoop ed-dual interface
 
7 - OOP - OO Concepts
7 - OOP - OO Concepts7 - OOP - OO Concepts
7 - OOP - OO Concepts
 
Stoop 430-design patternsintro
Stoop 430-design patternsintroStoop 430-design patternsintro
Stoop 430-design patternsintro
 
10 - OOP - Inheritance (b)
10 - OOP - Inheritance (b)10 - OOP - Inheritance (b)
10 - OOP - Inheritance (b)
 
Stoop sed-sharing ornot
Stoop sed-sharing ornotStoop sed-sharing ornot
Stoop sed-sharing ornot
 
9 - OOP - Smalltalk Classes (b)
9 - OOP - Smalltalk Classes (b)9 - OOP - Smalltalk Classes (b)
9 - OOP - Smalltalk Classes (b)
 
8 - OOP - Smalltalk Model
8 - OOP - Smalltalk Model8 - OOP - Smalltalk Model
8 - OOP - Smalltalk Model
 
Stoop 422-naming idioms
Stoop 422-naming idiomsStoop 422-naming idioms
Stoop 422-naming idioms
 
05 seaside
05 seaside05 seaside
05 seaside
 
10 - OOP - Inheritance (a)
10 - OOP - Inheritance (a)10 - OOP - Inheritance (a)
10 - OOP - Inheritance (a)
 
Double Dispatch
Double DispatchDouble Dispatch
Double Dispatch
 

Semelhante a Stoop 413-abstract classes (20)

Stoop 414-smalltalk elementsofdesign
Stoop 414-smalltalk elementsofdesignStoop 414-smalltalk elementsofdesign
Stoop 414-smalltalk elementsofdesign
 
4 - OOP - Taste of Smalltalk (Tamagoshi)
4 - OOP - Taste of Smalltalk (Tamagoshi)4 - OOP - Taste of Smalltalk (Tamagoshi)
4 - OOP - Taste of Smalltalk (Tamagoshi)
 
Stoop 450-s unit
Stoop 450-s unitStoop 450-s unit
Stoop 450-s unit
 
Stoop 304-metaclasses
Stoop 304-metaclassesStoop 304-metaclasses
Stoop 304-metaclasses
 
P J020
P J020P J020
P J020
 
8 - OOP - Syntax & Messages
8 - OOP - Syntax & Messages8 - OOP - Syntax & Messages
8 - OOP - Syntax & Messages
 
Divide and Conquer Approach.pptx
Divide and Conquer Approach.pptxDivide and Conquer Approach.pptx
Divide and Conquer Approach.pptx
 
Mutation Testing - Ruby Edition
Mutation Testing - Ruby EditionMutation Testing - Ruby Edition
Mutation Testing - Ruby Edition
 
Stoop ed-subtyping subclassing
Stoop ed-subtyping subclassingStoop ed-subtyping subclassing
Stoop ed-subtyping subclassing
 
11 - OOP - Numbers
11 - OOP - Numbers11 - OOP - Numbers
11 - OOP - Numbers
 
Calc ii complete
Calc ii completeCalc ii complete
Calc ii complete
 
9 - OOP - Smalltalk Classes (a)
9 - OOP - Smalltalk Classes (a)9 - OOP - Smalltalk Classes (a)
9 - OOP - Smalltalk Classes (a)
 
Utility Classes
Utility ClassesUtility Classes
Utility Classes
 
Another Tale of Two Patterns
Another Tale of Two PatternsAnother Tale of Two Patterns
Another Tale of Two Patterns
 
Java basics
Java basicsJava basics
Java basics
 
The Uniform Access Principle
The Uniform Access PrincipleThe Uniform Access Principle
The Uniform Access Principle
 
Sudoku Solver
Sudoku SolverSudoku Solver
Sudoku Solver
 
Process coordination
Process coordinationProcess coordination
Process coordination
 
Abstraction in java [abstract classes and Interfaces
Abstraction in java [abstract classes and InterfacesAbstraction in java [abstract classes and Interfaces
Abstraction in java [abstract classes and Interfaces
 
QULITIES OF A GOOD ALGORITHM
QULITIES OF A GOOD ALGORITHMQULITIES OF A GOOD ALGORITHM
QULITIES OF A GOOD ALGORITHM
 

Mais de The World of Smalltalk (17)

05 seaside canvas
05 seaside canvas05 seaside canvas
05 seaside canvas
 
99 questions
99 questions99 questions
99 questions
 
13 traits
13 traits13 traits
13 traits
 
12 virtualmachine
12 virtualmachine12 virtualmachine
12 virtualmachine
 
11 bytecode
11 bytecode11 bytecode
11 bytecode
 
10 reflection
10 reflection10 reflection
10 reflection
 
06 debugging
06 debugging06 debugging
06 debugging
 
04 idioms
04 idioms04 idioms
04 idioms
 
02 basics
02 basics02 basics
02 basics
 
01 intro
01 intro01 intro
01 intro
 
Stoop sed-smells
Stoop sed-smellsStoop sed-smells
Stoop sed-smells
 
Stoop sed-class initialization
Stoop sed-class initializationStoop sed-class initialization
Stoop sed-class initialization
 
Stoop sed-class initialization
Stoop sed-class initializationStoop sed-class initialization
Stoop sed-class initialization
 
Stoop metaclasses
Stoop metaclassesStoop metaclasses
Stoop metaclasses
 
Stoop ed-inheritance composition
Stoop ed-inheritance compositionStoop ed-inheritance composition
Stoop ed-inheritance composition
 
Stoop ed-class forreuse
Stoop ed-class forreuseStoop ed-class forreuse
Stoop ed-class forreuse
 
Stoop 440-adaptor
Stoop 440-adaptorStoop 440-adaptor
Stoop 440-adaptor
 

Stoop 413-abstract classes

  • 1. Stéphane Ducasse 1 Stéphane Ducasse stephane.ducasse@inria.fr http://stephane.ducasse.free.fr/ Abstract Classes
  • 3. S.Ducasse 3 Abstract Classes • Should not be instantiated (abstract in Java) • But can define complete methods. • Defines a protocol common to a hierarchy of classes that is independent from the representation choices. • A class is considered as abstract as soon as one of the methods to which it should respond to is not implemented (can be a inherited one).
  • 4. S.Ducasse 4 Abstract Classes in Smalltalk • Depending of the situation, override new to produce an error. • No construct:Abstract methods send the message self subclassResponsibility • Tools check this situation and exploit it. • Abstract classes are not syntactically different from instantiable classes, but a common convention is to use class comments: So look at the class comment and write in the comment which methods are abstract and should be specialized.
  • 5. S.Ducasse 5 Example Boolean>>not "Negation. Answer true if the receiver is false, answer false if the receiver is true." self subclassResponsibility
  • 7. S.Ducasse 7 Boolean Objects false and true are objects described by classes Boolean,True and False
  • 8. S.Ducasse 8 Conditional: messages to booleans • aBoolean ifTrue: aTrueBlock ifFalse: aFalseBlock • aBoolean ifFalse: aFalseBlock ifTrue: aTrueBlock • aBoolean ifTrue: aTrueBlock • aBoolean ifFalse: aFalseBlock (thePacket isAddressedTo: self) ifTrue: [self print: thePacket] ifFalse: [super accept: thePacket] • Hint:Take care — true is the boolean value and True is the class of true, its unique instance!
  • 9. S.Ducasse Boolean Hierarchy • How to implement in OO true and false without conditional? • Late binding: Let the receiver • decide! • Same message on false and true • produces different results
  • 10. S.Ducasse 10 Example “Class Boolean is an abstract class that implements behavior common to true and false. Its subclasses are True and False. Subclasses must implement methods for logical operations &, not, controlling and:, or:, ifTrue:, ifFalse:, ifTrue:ifFalse:, ifFalse:ifTrue:” Boolean>>not "Negation. Answer true if the receiver is false, answer false if the receiver is true." self subclassResponsibility
  • 11. S.Ducasse 11 Not false not -> true true not -> false Boolean>>not "Negation. Answer true if the receiver is false, answer false if the receiver is true.” self subclassResponsibility False>>not "Negation -- answer true since the receiver is false." ^true True>>not "Negation--answer false since the receiver is true." ^false
  • 12. S.Ducasse 12 | (Or) • true | true -> true • true | false -> true • true | anything -> true • false | true -> true • false | false -> false • false | anything -> anything
  • 13. S.Ducasse 13 Boolean>> | aBoolean Boolean>> | aBoolean "Evaluating disjunction (OR). Evaluate the argument. Answer true if either the receiver or the argument is true." self subclassResponsibility
  • 14. S.Ducasse 14 False>> | aBoolean false | true -> true false | false -> false false | anything -> anything False>> | aBoolean "Evaluating disjunction (OR) -- answer with the argument, aBoolean." ^ aBoolean
  • 15. S.Ducasse 15 True>> | aBoolean true | true -> true true | false -> true true | anything -> true True>> | aBoolean "Evaluating disjunction (OR) -- answer true since the receiver is true." ^ self
  • 17. S.Ducasse 17 Abstract/Concrete Abstract method Boolean>>not "Negation. Answer true if the receiver is false, answer false if the receiver is true." self subclassResponsibility Concrete method defined in terms of an abstract method Boolean>>xor: aBoolean "Exclusive OR. Answer true if the receiver is not equivalent to aBoolean." ^(self == aBoolean) not When not is be defined in subclasses, xor: is automatically defined
  • 18. S.Ducasse 18 Block Use in Conditional? • Why do conditional expressions use blocks? • Because, when a message is sent, the receiver and the arguments of the message are always evaluated. Blocks are necessary to avoid evaluating both branches.
  • 19. S.Ducasse 19 Implementation Note Note that theVirtual Machine shortcuts calls to boolean such as condition for speed reason. Virtual machines such asVisualWorks introduced a kind of macro expansion, an optimisation for essential methods and Just In Time (JIT) compilation.A method is executed once and afterwards it is compiled into native code. So the second time it is invoked, the native code will be executed.
  • 20. S.Ducasse 20 Magnitude I'm abstract class that represents the objects that can be compared between each other such as numbers, dates, numbers. My subclasses should implement < aMagnitude = aMagnitude hash Here are some example of my protocol: 3 > 4 5 = 6 100 max: 9 7 between: 5 and: 10
  • 21. S.Ducasse 21 Magnitude Magnitude>> < aMagnitude ^self subclassResponsibility Magnitude>> = aMagnitude ^self subclassResponsibility Magnitude>> hash ^self subclassResponsibility
  • 22. S.Ducasse 22 Magnitude Magnitude>> <= aMagnitude ^(self > aMagnitude) not Magnitude>> > aMagnitude ^aMagnitude < self Magnitude>> >= aMagnitude ^(self < aMagnitude) not Magnitude>> between: min and: max ^self >= min and: [self <= max]
  • 23. S.Ducasse 23 Date Subclass of Magnitude Date today < Date newDay: 15 month: 10 year: 1998 -> false
  • 24. S.Ducasse 24 Date Date>>< aDate "Answer whether the argument, aDate, precedes the date of the rec." year = aDate year ifTrue: [^day < aDate day] ifFalse: [^year < aDate year]
  • 25. S.Ducasse 25 Date Date>>= aDate "Answer whether the argument, aDate, is the same day as the receiver. " self species = aDate species ifTrue: [^day = aDate day & (year = aDate year)] ifFalse: [^false] Date>>hash ^(year hash bitShift: 3) bitXor: day
  • 26. S.Ducasse 26 What you should know • What is an abstract class? • What can we do with it?