This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
In the real test, does the multiple correct answer questions tell how many are corerct? -------------------------- 1) Which one of the following is a good strategy for resolving class name collisions that occur during OO analysis?
a) Allow each team member to choose a preferred name.
b) Create a class for each domain name, passing on requests to the one class that implements the behavior for all of them to share.
c) Discover better names for different concepts that are referred by the same term. ----------------------------------------------------------- 2) In design #1, the Catalog object has a getProducts() method, which returns a collection object, such as a Dictionary or array, containing all the Products the company sells. In design #2, the Catalog object has a getProductNumbered(anIdentifier) method, which returns the Product with the specified unique identifier. Considering the objects returned, which of the following BEST characterizes the two designs?
a) Both designs maintain the objects' encapsulation and reduce coupling by accessing state data via methods only and not directly.
b) Both designs break the objects' encapsulation, adding brittle coupling.
c) Design #1 breaks the encapsulation of the Catalog, adding brittle coupling. Design #2 maintains the encapsulation of the Catalog, making future design changes easier. --------------------------------------------------- 3) A non-object oriented legacy application which interacts with back end systems exists. It is now required to redesign this application into an object oriented system, that caters to high volume of requests. Which of the following need to be considered while modeling the system?
a) It is not necessary to define classes, such that they represent the data fields in the back end. The object model should capture the behavior of the legacy system.
b) The object model should consist of classes which match the back end data fields. This aids the persistence of classes.
c) Draw activity diagrams to understand the behavior of the existing legacy system.
d) The GUI client objects need to be behavioral driven and they directly communicate with the database.
------------------ 4) Which of the following are true about implementing a system based on existing OOAD assets?
a) Due to constraints introduced by the target language, such as C++, Smalltalk, or Java, as well as physical packaging, the OO analysis model does not carry forward into detailed design and implementation.
b) The classes, methods, attributes, and relationships identified during the OO analysis carry forward into detailed design and implementation.
c) The OO analysis model is usually refactored later in the project.
d) The classes from the OO analysis are expanded to add private methods and collaborations with helper classes. -------------------- 5) Which of the following are good practices to use while designing for reuse?
a) Define a persistence framework that provides services for persisting objects.
b) Use design patterns, wherein complete solutions are already defined.
c) Use controller objects to control the flow of processes in the system.
d) Assign responsibilities to classes such that coupling between them remains low.
I'm taking stab, I often overthink problems like this, and you'll see that in my comments below.
1) c 2) I'd say (a), Assuming everything extends class Product, neither return type has any other serious dependencies. 3) (a) and (b) seem subjective, sometimes maybe you can get away with that. (c) seems good, but it assumes the legacy systems was designed correctly. It also depends whether you are modeling extermal behavior of the system or internal (i.e. code) behavior. As for (d), who said anythng about a GUI? I'd probably have to go with b, although no where does it say you can't rework the back-end data fields. Sometimes that might be good, othertimes not. 4)(b) and (c), although (d) often happens, too. I'm not sure if "expected" means commonly happens, or the OO process specifically thnks it should happen. 5) I'd say (c) and (d)
(3) I'd say b,c. (4) a is absolutely right. As to (b), some of the relationships identified during the analysis phase are intended to help with communication. They are not necessary carried into the design and implementation phase. ( Reference: Applying UML And Patterns, Author: Craig Larman). I am not sure about (c).
1). b). To me c). is just not making sence. What's a better name? 2). I would choose c). Why? See how the question asked. "Considering the objects returned ..." To me it seems the design #1 just give you all the objects, including these you do not needed. Remember you can only choose one from the designs. In reality, what we see the design including both methods. 3). I am not sure for this one. I would choose a) and c). 4). I would choose b). c). and d). 5). Iwould say a). b). and d). Framework itself is designed for reuse and so is the design patterns. The controller object gives feeling of centralized system control. However most of time you could not avoid its existence. So I am not sure if it should be excluded.