• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Frits Walraven
Bartenders:
  • Piet Souris
  • Himai Minh

Dan's mock exam (in OOP)

 
Ranch Hand
Posts: 168
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello All,
Could anyone tell me why no subclass of A is tightly encapsulated ?
The following statement come from Dan's mock exam.
"If a class A is not tightly encapsulated, then no subclass of A is tightly encapsulated".
Thanks in advance!
Jack
 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Any class that extends class A means that it implicitly inherits the variables and methods of class A. and these inherited methods and variables act as though they belong to subclass.
so if the inherited methods and variables are not encapsulated in class A then they are not encapsulated in subclasses as well because inherited methods have the same modifiers for them as declared in parent class.
I hope i am clear with this
 
Ranch Hand
Posts: 504
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The rules of encapsulation are:
** All instance variables (state) are private
** To access/modify the state selectors/modifiers methods are provided
** The naming convention follows JavaBean naming convention (setSomething() and getSomething())
Of these three, the mandatory are keeping state private and providing setters for modification. If class A is not tightly encapsulated, that usually means that some of its state or the variables it inherits are not private. Every class that subclasses A will have access to inherited public or protected fields of A, which undermines the encapsulation concept. In some cases though, it's hard to see unambiguously whether a subclass is encapsulated or not. Consider this example:

Class A is apparently not tightly encapsulated because name is marked default access. Any class inside pack1 can modify it directly. Class Child is not encapsulated either due to this flaw. But what if Child is defined in a separate package pack2? All of a sudden, it looks very much like complying with the concept. name is not directly accessible any more! I hope, I'm not introducing more confusion here, the questions on the exam were not as dubious as my example.
 
Jack Lau
Ranch Hand
Posts: 168
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks!
Jack
 
It sure was nice of your sister to lend us her car. Let's show our appreciation by sharing this tiny ad:
free, earth-friendly heat - a kickstarter for putting coin in your pocket while saving the earth
https://coderanch.com/t/751654/free-earth-friendly-heat-kickstarter
reply
    Bookmark Topic Watch Topic
  • New Topic