DZone
Java Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Java Zone > Can Objects Be Friends?

Can Objects Be Friends?

Exchanging data while maintaining encapsulation is tricky. In theory, a decorator can help, but it won't compile in Java. Still, it's a concept worth exploring.

Yegor Bugayenko user avatar by
Yegor Bugayenko
·
Dec. 26, 16 · Java Zone · Opinion
Like (3)
Save
Tweet
6.56K Views

Join the DZone community and get the full member experience.

Join For Free

Proper encapsulation leads to a complete absence of "naked data." However, the question remains: How can objects interact if they can't exchange data? Eventually, we have to expose some data in order to let other objects use it, right? Yes, that's true. However, I guess I have a solution that 

Say that this is our object:

class Temperature 
{ private int t; public String toString() 
{ return String.format("%d C", this.t); } }


It represents a temperature. The only behavior it exposes is printing the temperature in Celsius. We don't want to expose t, because that will lead to the problem. We want to keep t secret, and that's a good desire.

Now, we want to have the ability to print temperatures in Fahrenheit. The most obvious approach would be to introduce another method, toFahrenheitString(), or add a Boolean flag to the object, which will change the behavior of the method toString(), right? Either one of these solutions is better than adding a method getT(), but neither one is perfect.

What if we create this decorator:

class TempFahrenheit implements Temperature 
{ private TempCelsius origin; public String toString() 
{ return String.format( "%d F", this.origin.t * 1.8 + 32 ); } }


It should work just great:

Temperature t = new TempFahrenheit( new TempCelsius(35) );


The only problem is that it won't compile in Java, because class TempFahrenheit is not allowed to access private t in class TempCelsius. And if we make t public, everybody will be able to read it directly, and we'll have that "naked data" problem — a severe violation of encapsulation.

However, if we allow that access only to one class, everything will be fine. Something like this (won't work in Java; it's just a concept):

class TempCelsius 
{ trust TempFahrenheit; 
    // here! 
    private int t; 
    public String toString() 
    { return String.format("%d C", this.t); } }


Since this trust keyword is placed into the class that allows access, we won't have the "naked data" problem — we will always know exactly which objects possess knowledge about t. When we change something about t, we know exactly where to update the code.

What do you think?

Object (computer science)

Published at DZone with permission of Yegor Bugayenko. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Introduction to JWT (Also JWS, JWE, JWA, JWK)
  • SQL GROUP BY and Functional Dependencies: a Very Useful Feature
  • Exhaustive JUNIT5 Testing with Combinations, Permutations, and Products
  • Java Microservices: Code Examples, Tutorials, and More

Comments

Java Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo