Chapter 6:

Objects and Data Structures

DaiLQ4

1
 Static Structure
Java

General Object-Oriented
Concurrent
Purpose Programming

Inheritance Object Polymorphism …

To day we will discuss about ‘Object’ in Java

2
 Dynamic Action
• Java is a high-level programming language.

interpreting/
implementing compiling
running
Requirements Source code Java bytecode Execution
1 2 3

By Java Compiler By Java Virtual Machine

• As a developer, our concern is (1): How to implement REQs correctly.

 In technical manner, we need to understand
o Java Language Specification
o Java Platform API Specification
o Java Virtual Machine Specification
• We also need some best practices and guidelines
such as Clean Code (a Handbook of Agile Software Craftsmanship).
3
Objectives
By the end of this seminar, you will be able to

Understand what is Object.

[ToDo] Understand how Object can be represented and used by JVM.
Know some best practices for working Object in Java.

4
Introduction
There is a reason that we keep our variables private. We don’t want
anyone else to depend on them. We want to keep the freedom to change
their type or implementation on a whim or an impulse.

Why, then, do so many programmers automatically add getters and

setters to their objects, exposing their private variables as if they were
public?

5
Contents
Data Abstraction
Data/Object Anti-Symmetry
The Law of Demeter
Train Wrecks
Hybrids
Hiding Structure
Data Transfer Objects
Active Record
Conclusion

6
Contents
Data Abstraction
Data/Object Anti-Symmetry
The Law of Demeter
Train Wrecks
Hybrids
Hiding Structure
Data Transfer Objects
Active Record
Conclusion

7
Data Abstraction
Example#1: Two following lists represent data of a point on the
Cartesian plane

8
Data Abstraction
• About list 6-2

• Not clear which type of point representing Not Good!

It can be rectangular or polar coordinates or neither!
• Access policy
• Each coordinate can be get independently.
Not Good!
• All coordinates must be set together. 9
Data Abstraction
• About list 6-1

• Pretty clear it is rectangular coordinates.

• Access policy
• Expose it’s implementation through public fields. Not Good!
• All coordinates must be set independently.

10
Data Abstraction

Sample code & short demo

11
Data Abstraction
Example#1:

 Two implementation should be “mixed” together

Conclusion:
• Keep variables as private and expose abstract interfaces to manipulate the
essence of the data, without having to know its implementation.
• Not simply push variable’s value out through getters and setters.
12
Contents
Data Abstraction
Data/Object Anti-Symmetry
The Law of Demeter
Train Wrecks
Hybrids
Hiding Structure
Data Transfer Objects
Active Record
Conclusion

13
Data/Object Anti-Symmetry
Differences between Object and Data Structure

Object Data Structure

• Hide data behind abstraction. • Expose their data.
• Expose functions to operate on • No meaningful functions.
data.

14
 Data/Object Anti-Symmetry
Example#2 (continue example#1)
Listing 6-5 Procedural Shape

Not need to
update existing Need to update this function
shapes adding a and all other similar functions
new function, when adding a new shape.
for example,
perimeter().

15
 Data/Object Anti-Symmetry
Example#2
Listing 6-6 Polymorphic Shapes

Not need to update

function area() of
existing shapes when
adding a new shape.

However, need to update all existing

shapes when adding a new function,
for example, perimeter().
16
Data/Object Anti-Symmetry
Example#2
Conclusion
Procedural code makes it hard to add new data structures because all the functions
must change.
OO code makes it hard to add new functions because all the classes must change.
The idea that everything is an object is a myth. Sometimes you really do
want simple data structures with procedures operating on them.

17
Contents
Data Abstraction
Data/Object Anti-Symmetry
The Law of Demeter
Train Wrecks
Hybrids
Hiding Structure
Data Transfer Objects
Active Record
Conclusion

18
The Law of Demeter
The Law of Demeter (LoD) or principle of least knowledge (*)
Is a design guideline for developing software, particularly object-
oriented programs.
Can be summarized as following:
Each unit should have only limited knowledge about other units: only
units "closely" related to the current unit.
Each unit should only talk to its friends; don't talk to strangers.
Only talk to your immediate friends.

(*) https://en.wikipedia.org/wiki/Law_of_Demeter
19
The Law of Demeter
Method f of a class C should only call the
methods of these:
Class C
An object created by f
An object passed as an argument to f
An object held in an instance variable of C
Only talk to your immediate friends.
The method should not invoke methods on objects that are
returned by any of the allowed functions (talk to friends, not to strangers).
An example found somewhere in Apache framework seems to violate LoD

20
Contents
Data Abstraction
Data/Object Anti-Symmetry
The Law of Demeter
Train Wrecks
Hybrids
Hiding Structure
Data Transfer Objects
Active Record
Conclusion

21
Train Wrecks – better but not enough
Continue with previous example

It is usually best to split them up as follows:

 It seems to be better but is OK?

Whether or not it is violation of LoD depends on
ctxt, opts, and scratchDir are objects or data structures.
If they are object  clear violation of LoD.
If they are data structure  Demeter does not apply.
22
Contents
Data Abstraction
Data/Object Anti-Symmetry
The Law of Demeter
Train Wrecks
Hybrids
Hiding Structure
Data Transfer Objects
Active Record
Conclusion

23
Hybrids – worse, should avoid
Is “mixed” by object and data structure.
Has functions that do significant things.
Also have either public variables or public getters and setters.
Should avoid as it hard to add both new functions and new data
structures.

24
Contents
Data Abstraction
Data/Object Anti-Symmetry
The Law of Demeter
Train Wrecks
Hybrids
Hiding Structure
Data Transfer Objects
Active Record
Conclusion

25
Hiding Structure – best solution
Continue with previous example

What about two following solutions:

1

 Neither option feels good!

If ctxt is an object

 tell it to do something; not ask about its internals.

 That seems like a reasonable thing for an object to do! 26

Contents
Data Abstraction
Data/Object Anti-Symmetry
The Law of Demeter
Train Wrecks
Hybrids
Hiding Structure
Data Transfer Objects
Active Record
Conclusion

27
Data Transfer Objects
Is a data structure represented by a class with public variables and no
functions (DTO).
Is very useful when communicating with databases or
parsing messages from sockets.
Somewhat more common is the “bean” form
in Listing 6-7 address.java

Address.java

28
Contents
Data Abstraction
Data/Object Anti-Symmetry
The Law of Demeter
Train Wrecks
Hybrids
Hiding Structure
Data Transfer Objects
Active Record
Conclusion

29
Active Record
Are special forms of DTOs.
Have navigational methods like save and find.
Are direct translations from database tables, or other data
sources.
Should not be treat as object by putting business rule methods in them.

30
Contents
Data Abstraction
Data/Object Anti-Symmetry
The Law of Demeter
Train Wrecks
Hybrids
Hiding Structure
Data Transfer Objects
Active Record
Conclusion

31
Conclusion
Object vs. Data Structure
Pros Cons
Object • Easy to add new kinds of • Hard to add new behaviors to
(expose behavior and hide objects existing objects.
data) without changing existing
behaviors.
Data Structure • Easy to add new behaviors to • Hard to add
(expose data and have no existing data structures. new data structures to existing
significant behavior) functions.

As a developer, we need to choose an appropriate approach for each

concrete job.
32
Proposal to update coding convention

NONE

33
THE END !

34