Punit Jain wrote:But if the memory is empty, which means there are on service orders droid has. That's what I am checking at line 13.
Punit Jain wrote:Agreed that my starting point should be focusing and writing the droid class. However, In the problem statement I am given to assume that there is already a droid which performs the task of maintaining and servicing vehicles. Nothing other than that.
Junilu Lacar wrote:
Punit Jain wrote:Agreed that my starting point should be focusing and writing the droid class. However, In the problem statement I am given to assume that there is already a droid which performs the task of maintaining and servicing vehicles. Nothing other than that.
Maybe you're working under more constraints than I'm assuming you have, I don't know. However, you're missing the point when you say there is already a droid that performs the task of maintaining and servicing vehicles. Even if there was already a droid, you're talking about a (hypothetical) physical device. This is a program you're trying to write and the Droid we're talking about designing is a (hypothetical) program entity that represents what the physical device does.
It's like how a physical Android phone has a software Android operating system that controls it. We're talking about Mechanic Droid (the program), not Mechanic Droid (the actual device).
The problem statement says "Create a program which helps the mechanic droid track each vehicle that has been serviced and store the information until it can be uploaded to a central repository." There are no constraints in that requirement that would prevent me from saying that the droid uses ServiceOrder objects that have information about the Vehicle being serviced and other things related to the service work. Even if we say we don't want to track any of the service work done but only track which vehicles have been serviced, I'd still go with a ServiceOrder that included Vehicle information on it. At most, I'd only replicate the Vehicle's unique identifier and perhaps a short description of the Vehicle in the Service Order. Then again, maybe it's just me and the heuristics that I employ when designing. I'm pretty sure that tracking Vehicles won't be the only thing this droid will be asked to do while its offline and working independently, so the Service Order is a hedge. I'm betting that since using a Service Order already makes sense to me now, it will still make sense later when more requirements come in to extend the capabilities of the Droid program.
Junilu Lacar wrote:
Punit Jain wrote:
1.) At line 47, the display name says about outstanding order but the method name is order received.
2.) At line 57, instead of using greater than I could have check for the exact number.
3.) Again the method name and display names are inconsistent at line 54 and 55.
This is only scratching the surface. On #2 above, your suggested mitigation would make the smell worse.
Try harder and look at the example of what I did to highlight the smells in my own tests.
Junilu Lacar wrote:No, I don't think you're getting it still. That doesn't look like an improvement to me at all. If anything, it's moving in the wrong direction. Sorry. ¯\_(ツ)_/¯
Program design is tough. Writing coherent code is tough. It takes a lot of practice, so I'll let you go and get in more reps. Check back again if you have more code you'd like me to comment on, if you don't mind taking my blunt critiques. I don't know what kind of books you use as references but here are some of the books that taught me most of what I know about design:
"Understanding the Four Rules of Simple Design" by Corey Haines
Books by Kent Beck on JUnit and Test-Driven Development
"Refactoring" by Martin Fowler. Also, books in Fowler's Signature Series about Enterprise Architecture Patterns
Books by Robert "Uncle Bob" Martin - Clean Code, Agile Software Development - Principles, Patterns, and Practices
Craig Larman - "Object-Oriented Analysis and Design"
Growing Object-Oriented Software Guided By Tests by Nat Pryce and Steve Freeman
The Pragmatic Programmer by Andrew Hunt and David Thomas.
Refactoring to Patterns by Joshua Kerievsky
and others by authors like Tom Gilb, Steve McConnell, Peter Coad, Alistair Cockburn, and many more
Junilu Lacar wrote:Check back again if you have more code you'd like me to comment on, if you don't mind taking my blunt critiques.
Everybody's invited. Except this tiny ad:
New web page for Paul's Rocket Mass Heaters movies
https://coderanch.com/t/785239/web-page-Paul-Rocket-Mass
|