Anna Greene wrote:I'm not at all sure where to go from there though. I don't even know how I should mark an accountant as engaged. My first instinct is to create an extra attribute for the class of type boolean isEngaged, but I don't think that's what's expected of me since it isn't specified in the accountant class.
Just to be clear, I'm not asking for any actual solutions to my problem. All I want is a nudge in the right direction.
K. Tsang CEng MBCS PMP PMI-ACP OCMJEA OCPJP
Anna Greene wrote:I'm not at all sure where to go from there though. I don't even know how I should mark an accountant as engaged. My first instinct is to create an extra attribute for the class of type boolean isEngaged, but I don't think that's what's expected of me since it isn't specified in the accountant class.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:4. (The most OO in my view) Create a new class CompanyAccountant that wraps or extends an Accountant, and adds an 'engaged' attribute.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Anna Greene wrote:3. Process a contract request....
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:
Winston Gutkowski wrote:4. (The most OO in my view) Create a new class CompanyAccountant that wraps or extends an Accountant, and adds an 'engaged' attribute.
Actually, looking at your requirements, you might think about creating a Contract class instead, and use that to do your "engaged" check.
Anna Greene wrote:Contract is one of the classes. Here's what it looks like as it was handed out.
If I use Contract for the engaged "attribute", how would I link it to accountant though? From my understanding of OO philosophy having either one of those classes "extend" the other would make no sense, so I gather that's not what you mean.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
You're welcome . I had thought you were going to tell me off for being hard on you.Anna Greene wrote:That is an absolutely fantastic reply Campbell. . . .
Anybody else like to reply about this, in case I am mistaken?However, the people teaching me actually recommended calling booleans isX or isY, so I'm surprised to hear that isn't standard practice.
Anna Greene wrote:However, the people teaching me actually recommended calling booleans isX or isY, so I'm surprised to hear that isn't standard practice.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Campbell Ritchie wrote:
Anybody else like to reply about this, in case I am mistaken?However, the people teaching me actually recommended calling booleans isX or isY, so I'm surprised to hear that isn't standard practice.
Steve McConnell wrote:Some programmers like to put Is in front of their boolean names. Then the variable name becomes a question: isDone?, isError?, isFound?, isProcessingComplete? Answering the question with true or false provides the value of the variable. A benefit of this approach is that it won't work with vague names: isStatus? makes no sense at all. A drawback is that it makes simple logical expressions less readable: if ( isFound ) is slightly less readable than if ( found ).
Tim Driven Development | Test until the fear goes away
I was thinking the same sort of thing when I suggested enums. If you have an enum element which has embedded data. then subtyping Contract may become redundant.Winston Gutkowski wrote: . . . and dispatch code is often symptomatic of something that could be solved with polymorphism (ie, with subtypes of Contract), rather than if...else (or switch). . . .
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |