• 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:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Junilu Lacar
  • Liutauras Vilda
Sheriffs:
  • Paul Clapham
  • Jeanne Boyarsky
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Piet Souris
  • Carey Brown
Bartenders:
  • Jesse Duncan
  • Frits Walraven
  • Mikalai Zaikin

Part One questions

 
Ranch Hand
Posts: 132
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello

I'm preparing for the part 1 multiple choice test and I've just made yesterday the Total Tester mock tests. There were three questions/answers that I can't agree on.

1) There was a "right" solution that the Singleton pattern does not only create a single instance, but it can be also used to create a variable number of instances of a class. Really?

2) Another statement was that a subclass can inherit from one and only one superclass. Well for me it is clear that a subclass A can directly inherit only from one superclass B, but it is of course also possible that this superclass B inherits behavior from another superclass C, therefor I would say in the end this statement is not necassary right.

3) The definition of encapsulation (Hide implementation details behind a set of non-private methods) is something that I really like, because for me means encapsulation that we make the class attributes private and only provide (non-private) getter- and setter-methods where needed. Hiding implementation details is more something that I see for classes that implement an interface and the parts of this implementation code can be put in private methods to well structure the (clean) code.

I'm open for any comments.

Regards,
Christian
 
Bartender
Posts: 3648
16
Android Mac OS X Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Christian Nicoll wrote:
1) There was a "right" solution that the Singleton pattern does not only create a single instance, but it can be also used to create a variable number of instances of a class. Really?



The first part is correct. The latter part isn't. Unless my English interpretation is wrong, "create a variable number of instances" means multiple surely not a singleton.


Christian Nicoll wrote:
2) Another statement was that a subclass can inherit from one and only one superclass. Well for me it is clear that a subclass A can directly inherit only from one superclass B, but it is of course also possible that this superclass B inherits behavior from another superclass C, therefor I would say in the end this statement is not necassary right.



You can only inherit or extend a class once eg public ClassA extends ClassB. If ClassB in turn inherits another class, this ClassB is only inheriting one class.
So your concept of multiple inheritance for class is incorrect. You are basically the classes are in a "chain" when you put them in a hierarchy or diagram. But that's not inheritance.

In Java there is no such thing as public ClassA extends ClassB, ClassC. However, interfaces can have multiple inheritance eg public InterfaceA extends InterfaceB, InterfaceC


Christian Nicoll wrote:
3) The definition of encapsulation (Hide implementation details behind a set of non-private methods) is something that I really like, because for me means encapsulation that we make the class attributes private and only provide (non-private) getter- and setter-methods where needed. Hiding implementation details is more something that I see for classes that implement an interface and the parts of this implementation code can be put in private methods to well structure the (clean) code.



Your latter sentence "Hiding implementation details ...." is somewhat wrong. Encapsulation can apply to simple classes (POJO) as well as implementation classes (those implement an interface).

POJO follow the standard JavaBean convention when there are getters and setters to interact with the "private" attributes.

Implementation classes equally can have private attributes that are common for the task. For example, such attribute can be a DateFormat for the entire class. Instead of having to new SimpleDateFormat("yyyy-MM-dd") in every method, this can become an instance/class variable.

Clean code depends on how you organize the code into packages and class/purpose. Having all "utility" methods in a utility class won't be clean. This somewhat is segregation of concerns.
 
Christian Nicoll
Ranch Hand
Posts: 132
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello K.Tsang

I'm absolutly agreeing with you. Thanks for your input.

Regards,
Christian
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic