I have a class Person. The application requirements now state additional information should be collected about Person. This information centers around driving history, such as the number of tickets, class of CDL, etc... I'm unsure how to design this.
Option 1 (Inheritance):
Option 2 (Composition):
I've read that data only classes are code smell. In this instance the only real need is store this driver information in a database. I'd very much appreciate any suggestions or insight anyone may offer.
I'm working on an application that allows a user to order computer hardware or software. My initial design goes something like this:
I'm noticing that since each class is really an OrderItem and not expected to behave as, say a computer or printer, the classes mainly serve as data holders for item specific attributes. (e.g. printer has laser | ink_jet enum as an attribute. ) That said, it appears the inheritance hierarchy isn't really providing the benefit of polymorphism since all order items really behave the same. I'm wondering if a better solution would be to implement something akin to what's described in the guitar store example in Heads First OOA&D. That being, in this case, a single OrderItem class with an associative array of item specific attributes.
Sorry, I'm having a bit of trouble articulating the design issue.
There isn't a FelonyQuestion class. There is only a generic, PrequalifyQuestion class which contains a customer defined question. Later in the development of this app I'm going to have to get more detailed information about the person. The prequalify questions may or may not contain part of a more detailed picture about the person, that I'll need to build into my object model.
Short of some type of natural language search, I'm not sure how to extract the answers from the prequalify questions and incorporate them into the more detailed object model. I'm not even sure if I should.
I may be over thinking this as it could very well qualify for YAGNI.
Stevi, thanks for responding. Currently I have a collection of prequalify question classes associated with the Person class. The text of the questions is pulled from a database. Each question has an ID that matches it to the answer given by the person. These are merged at run-time to become a PrequalifyQuestion object. This works fine, but effectively makes the questions and answers somewhat anonymous and unrelated to the Person object. If I later need to add a FelonyCollection class how will I relate the user defined, prequalify questions to the actual Felony objects? It's this disconnect between these dynamic questions and synchronizing them with my object model that I'm having difficulty wrapping my mind around.
// Classes Person PrequalifyQuestionCollection PrequalifyQuestion // Question text is free-handed in by customer.
I'm writing an app where the central object is a Person. The Person class is composed of attributes as well as other classes (e.g. a list of previous employers, etc... ). The customer uses this app to input information about the person while they have the person on the phone. The customer has requested a form with a list of prequalifer questions to ask this person. Examples might include: "Have you ever done illegal drugs?", "Have you ever been convicted of a felony?", "Date you can start work?". The question list should be customizable for each customer.
My question is one of design. How do I fit these questions into my OOD? If the questions were static I could create objects and map the answers into the objects.
Thanks for responding Frank. I think I understand what you're saying, but let me be sure. You're suggesting I take a behavior centric-view of systems as opposed to a data-centric view. Is this correct? I've been reading a couple books about this perspective.
Most of the systems I build are for business and are primarily concerned with moving data in and out of a database ( or maybe that's just my current perspective? ). To be honest, I'm having a challenge wrapping my mind around this behavioral-centric view. Any advice or articles you could point me to?
Best Regards, Andrew
[ December 13, 2007: Message edited by: Andrew Laughlin ] [ December 13, 2007: Message edited by: Andrew Laughlin ]
I'm creating an app that allows users to request services/hardware/software. The request can consist of anything from a phone line to a new machine to a virus scanner upgrade. The GUI isn't an issue, what I'm wondering about is the domain logic design. I'm not going to write all of this at once so I need an extensible design, something that follows the Open/Closed Principle.
Is this enough information to solicit design suggestions?
I'm developing software that manipulates all facets of ID3 tags in digital audio files (typically mp3s). I'm curious as to what good design in this domain entails. Here's a quick synopsis:
An ID3 tag is a small piece of information, in a specific format, embedded in an mp3 file. There are 2 major versions of ID3 tags v1 and v2. They are entirely different animals. Inside each major version are minor versions ( v2.3, v2.4, etc... ) which have many similarities. There are no constraints here - a client of this API should have complete flexibility to manipulate tags however it sees fit. The design, of course should adhere to the OCP as well as other basic OOD principles.
I already have a design which I purposely didn't post. I am hoping to harness the design knowledge of others who may see the domain entirely different than I do. All ideas are welcomed.
This is an interesting problem. I don't know that I have a solution, but sometimes a different set of eyes on an issue can point you in the right direction.
I see two classes, User and Project. The User class' access level in regard to a Project class is determined by some set of rules ( same dept, etc..). Adhereing to the "Single Responsibility Principle" (http://www.objectmentor.com/resources/articles/srp.pdf) it seems to follow that class User should know about users and class Project about projects. The relationship that defines the security between these two entities seems (at least in my mind) to exist outside both entities. Therefore a separate entity should mediate access control. This separate entity could be the service, as is currently, or another object. It seems a valuable design goal would be the ability to change the security requirements without affecting or having to change the User and/or Project classes. Are future requirements going to necessitate more granular control beyond a Project simply being �editable�?
It seems in your scenario, Projects are always editable, it just depends on who's asking. This lends itself to the ACL model implemented on various resources in most modern operating systems.