A basic object diagram?
-
Hello, I'm learning and trying to improve my object design skills, so please excuse my ignorance. I've got a very basic app I'm working on that involves house windows. Each Window is composed of various options (frames, glass, screens etc). Each option has a unit mulitplier used to calculate prices. The window itself has size parameters height & width. I don't know how to post a diagram, so here is a URL to a diagram of how I would typically design it. http://www.mxpreview.com/ClassDiagram.pdf[^] In my example, I would create three classes (window, windows, windowoptions). The window class represents a single window. The window class has an arraylist propery of windowoption objects. In the window object I have a function that rolls through the windowoptions to calculate the cost of the window. The New() constructor is overloaded to accept an ID, which will load up the individual properties. The windowoption object represent the various options a window might have. There is really no action done by the windowoption object. It is just used to calculate price. The windows object is what I'd use to generate the various window objects. QUESTION: Am I headed the right direction? Is this a typical way of doing things? Is there any reason to make this more complex? Any guidance will be greatly appreciated! Thanks, Wauna
-
Hello, I'm learning and trying to improve my object design skills, so please excuse my ignorance. I've got a very basic app I'm working on that involves house windows. Each Window is composed of various options (frames, glass, screens etc). Each option has a unit mulitplier used to calculate prices. The window itself has size parameters height & width. I don't know how to post a diagram, so here is a URL to a diagram of how I would typically design it. http://www.mxpreview.com/ClassDiagram.pdf[^] In my example, I would create three classes (window, windows, windowoptions). The window class represents a single window. The window class has an arraylist propery of windowoption objects. In the window object I have a function that rolls through the windowoptions to calculate the cost of the window. The New() constructor is overloaded to accept an ID, which will load up the individual properties. The windowoption object represent the various options a window might have. There is really no action done by the windowoption object. It is just used to calculate price. The windows object is what I'd use to generate the various window objects. QUESTION: Am I headed the right direction? Is this a typical way of doing things? Is there any reason to make this more complex? Any guidance will be greatly appreciated! Thanks, Wauna
The design seems to ok, if i can make 2 suggestions: 1. Have the Window object use a separate object for performing database interaction this could be based on an interface something like IWindowGateway that would have methods to Insert(), Update(), Delete(). A concrete implementation of this could be passed in by constructor or by setting a property (or could be set by using a DI framework). This provides benefits of being able to perform unit tests against Window without DB interaction and also makes a little easier if you need to use another type of storage type. 2. Windows would maybe be better called something like WindowFinder that provides methods that returns lists of Window objects based on Criteria such as FindWindowByQuote(int quoteID) or FindWindowByCost(decimal minCost, decimal maxCost) etc.. as and when needed. Hope this helps :)
-
The design seems to ok, if i can make 2 suggestions: 1. Have the Window object use a separate object for performing database interaction this could be based on an interface something like IWindowGateway that would have methods to Insert(), Update(), Delete(). A concrete implementation of this could be passed in by constructor or by setting a property (or could be set by using a DI framework). This provides benefits of being able to perform unit tests against Window without DB interaction and also makes a little easier if you need to use another type of storage type. 2. Windows would maybe be better called something like WindowFinder that provides methods that returns lists of Window objects based on Criteria such as FindWindowByQuote(int quoteID) or FindWindowByCost(decimal minCost, decimal maxCost) etc.. as and when needed. Hope this helps :)
Hi stavinski, Thanks for your input. I think I understood what you suggested. I reworked my class diagram. Here is the link. I'm not 100% certain that I've got the diagram relations correct, but I think I understand what you suggested. http://www.mxpreview.com/WindowClassDiagram2.jpg[^] So, to handle db operations I would create a concrete object, and pass it to the constructor as a parameter. Then I could call MyWindowDB.Insert() which would roll through the parameters and perform the update. The advantage to doing this is that a database change would not require me to modify the "Window" class. Does this seem correct? You mentioned testing, and I think I understood your logic on that. I wouldn't need to modify the database while testing validation and such. Are there any other reasons to use this type of structure? The CalculateCost() function would need to be in the interface. How would I keep that logic in one spot? I'm not sure if an interface can contain code like that function. I'm kind of new to this, so I apologize for the ignorance.
-
Hi stavinski, Thanks for your input. I think I understood what you suggested. I reworked my class diagram. Here is the link. I'm not 100% certain that I've got the diagram relations correct, but I think I understand what you suggested. http://www.mxpreview.com/WindowClassDiagram2.jpg[^] So, to handle db operations I would create a concrete object, and pass it to the constructor as a parameter. Then I could call MyWindowDB.Insert() which would roll through the parameters and perform the update. The advantage to doing this is that a database change would not require me to modify the "Window" class. Does this seem correct? You mentioned testing, and I think I understood your logic on that. I wouldn't need to modify the database while testing validation and such. Are there any other reasons to use this type of structure? The CalculateCost() function would need to be in the interface. How would I keep that logic in one spot? I'm not sure if an interface can contain code like that function. I'm kind of new to this, so I apologize for the ignorance.
-
Hi Wauna, I was thinking something like this Class Diagram[^]
Ahhh.. the Gateway is the interface, not the Window. That makes more sense. So SQLServerWindowGateway would contain the Stored Proc calls. An instance of iWindowGateway would reside in the Window object. Then I suppose some parameter would need to be set to determine which Gateway to use (SQL vs Memory). I think I'm seeing the idea....Clever! We will have abstracted the Data reading and writing away from the core objects. The extra layer provides the flexibility to modify the db without interfering with the core objects. It makes sense. Thanks Steve!
-
Ahhh.. the Gateway is the interface, not the Window. That makes more sense. So SQLServerWindowGateway would contain the Stored Proc calls. An instance of iWindowGateway would reside in the Window object. Then I suppose some parameter would need to be set to determine which Gateway to use (SQL vs Memory). I think I'm seeing the idea....Clever! We will have abstracted the Data reading and writing away from the core objects. The extra layer provides the flexibility to modify the db without interfering with the core objects. It makes sense. Thanks Steve!
-
Ahhh.. the Gateway is the interface, not the Window. That makes more sense. So SQLServerWindowGateway would contain the Stored Proc calls. An instance of iWindowGateway would reside in the Window object. Then I suppose some parameter would need to be set to determine which Gateway to use (SQL vs Memory). I think I'm seeing the idea....Clever! We will have abstracted the Data reading and writing away from the core objects. The extra layer provides the flexibility to modify the db without interfering with the core objects. It makes sense. Thanks Steve!
also the abstraction allows you to come up with new gateways. let's say you've got the window object on your machine in a SQL DB but you connect your laptop to head office. You can now pass the window SOAPServerWindowGatewayObject and the window is synchronized with Head Office. Equally that could be an IPartListPrintOutGateway etc I'm sure the potential list is almost limitless. Russ
