OOP
in [OOP]
|
Prev: EcmaScript 4
Next: Java enum model question
From: siddharthkhare on 10 Apr 2008 16:26 Hi, I have three main entities in system ............... report , sections , lineItem. Requirements : a section can be create by assembling some line items together. a report can be created by assembling some sections together. A administrator will have functionality to delete or add to a master list of sections and attributes. so in other word there are delete and add operations happening on sections and line items out side of a context of specific report. OK to model this.... i will have a report object. That will hold a collections of sections and each individual section will hold collection of line items. Something like this... Report.Sections[i].lineItems[j].LineItemName Now lets assume that there are two types of consumers that will using this object model. A web applications, A windows think client application ------------------------------------------------------------------------------------------ what I am trying to find out by this questions and discussion is ..What is the best way to model this and how your object model will change when you move from web app to windows app. Let's take example of web application .... Use case is delete first line item that is with in first section and sections is inside a specific report object.. so code in my web page will look like this... Report.Section[0].LineItem[0].Delete(); But this a web app. in most cases you will not keep your report object on postbacks. And obviously for performance reason you are not going to re-create the full report object again on post back and then call delete on that ...so here is my first question.. Where would you put the method to delete the line item from report? Would you put it as an instance method directly on report object..as shwon below? Report.DeleteLineItem(SectionID,LineITemId) If yes...... But another consumer form my object model is a windows app ...where It may be ok to keep object in memory unlike web app. so this call may be fine as i have a fully loaded report object in memory. Report.Section[0].LineItem[0].Delete(); so how would you come up with common object model that works for both ...it is possible without writing more service layers? -------------------------------------------------------------------------- Another use case.... Sections and line items can be deleted in the context of a report as i described above OR they can be deleted system wide by administrators .so if a section or line item is not in use by any report presently admin can delete them from the master list. now question is what is the best place to put these delete method.... if i put them in the same sections and line items objects that I used above then i can write code like this.... LineItems.LoadAll() LineItems[0].DeleteSystemWide() but down side of this is ....they will be available in this call as well... Report.Section[0].LineItem[0].DeleteFromSystem(); This does not make sense because i am trying to delete system wide but calling it on a specific report object.... So what are the solutions.... Should i use explicit interface implementation (c#)? shoud i create separate classes and put them in separate name spaces ..like admin.LineItem will have system wide delete function but other line item class will not......this also is ugly because i am creating two classes for same entity only because of this one behavior..... Any ideas and other ways to do it..? Thanks Siddharth
From: topmind on 11 Apr 2008 20:36 siddharthkh...(a)hotmail.com wrote: > Hi, > I have three main entities in system ............... report , > sections , lineItem. > > > Requirements : > a section can be create by assembling some line items together. > > a report can be created by assembling some sections together. > > A administrator will have functionality to delete or add to a master > list of sections and attributes. > so in other word there are delete and add operations happening on > sections and line items out side of a context of specific report. > > OK to model this.... > i will have a report object. That will hold a collections of sections > and each individual section will hold collection of line items. > > Something like this... > > > Report.Sections[i].lineItems[j].LineItemName > > > Now lets assume that there are two types of consumers that will using > this object model. A web applications, A windows think client > application Good luck. The behavior and conventions of web versus fat-client (or paper-oriented) reports are so different that making a generic anything that serves both of them without rewrite is a big challenge unless you pick a lowest common denominator, which limits things. > > ------------------------------------------------------------------------------------------ > what I am trying to find out by this questions and discussion > is ..What is the best way to model this and how your object model will > change when you move from web app to windows app. > > Let's take example of web application .... > > Use case is delete first line item that is with in first section and > sections is inside a specific report object.. > > so code in my web page will look like this... > Report.Section[0].LineItem[0].Delete(); > > But this a web app. in most cases you will not keep your report object > on postbacks. And obviously for performance reason you are not going > to re-create the full report object again on post back and then call > delete on that ...so here is my first question.. > > Where would you put the method to delete the line item from report? > > Would you put it as an instance method directly on report object..as > shwon below? > > Report.DeleteLineItem(SectionID,LineITemId) > > If yes...... > > But another consumer form my object model is a windows app ...where It > may be ok to keep object in memory unlike web app. > so this call may be fine as i have a fully loaded report object in > memory. > Report.Section[0].LineItem[0].Delete(); > > so how would you come up with common object model that works for > both ...it is possible without writing more service layers? > > -------------------------------------------------------------------------- > > Another use case.... > > Sections and line items can be deleted in the context of a report as i > described above > OR they can be deleted system wide by administrators .so if a section > or line item is not in use by any report presently admin can delete > them from the master list. > > now question is what is the best place to put these delete method.... > > if i put them in the same sections and line items objects that I used > above > then i can write code like this.... > > LineItems.LoadAll() > LineItems[0].DeleteSystemWide() > > > but down side of this is ....they will be available in this call as > well... > > Report.Section[0].LineItem[0].DeleteFromSystem(); > This does not make sense because i am trying to delete system wide but > calling it on a specific report object.... > > So what are the solutions.... > > Should i use explicit interface implementation (c#)? > shoud i create separate classes and put them in separate name > spaces ..like admin.LineItem will have system wide delete function but > other line item class will not......this also is ugly because i am > creating two classes for same entity only because of this one > behavior..... > > > Any ideas and other ways to do it..? If you have more than about 50 and they will be changing often by different people, consider tracking report configuration settings in a database. A "toy" example that sort of illustrates this can be found at: http://www.geocities.com/tablizer/chal06.htm > > Thanks > Siddharth -T-
From: frebe on 12 Apr 2008 06:31 On 10 Apr, 23:26, siddharthkh...(a)hotmail.com wrote: > Hi, > I have three main entities in system ............... report , > sections , lineItem. > > Requirements : > a section can be create by assembling some line items together. > > a report can be created by assembling some sections together. > > A administrator will have functionality to delete or add to a master > list of sections and attributes. > so in other word there are delete and add operations happening on > sections and line items out side of a context of specific report. > > OK to model this.... > i will have a report object. That will hold a collections of sections > and each individual section will hold collection of line items. > > Something like this... > > Report.Sections[i].lineItems[j].LineItemName > > Now lets assume that there are two types of consumers that will using > this object model. A web applications, A windows think client > application > > ------------------------------------------------------------------------------------------ > what I am trying to find out by this questions and discussion > is ..What is the best way to model this and how your object model will > change when you move from web app to windows app. > > Let's take example of web application .... > > Use case is delete first line item that is with in first section and > sections is inside a specific report object.. > > so code in my web page will look like this... > Report.Section[0].LineItem[0].Delete(); > > But this a web app. in most cases you will not keep your report object > on postbacks. And obviously for performance reason you are not going > to re-create the full report object again on post back and then call > delete on that ...so here is my first question.. > > Where would you put the method to delete the line item from report? > > Would you put it as an instance method directly on report object..as > shwon below? > > Report.DeleteLineItem(SectionID,LineITemId) > > If yes...... > > But another consumer form my object model is a windows app ...where It > may be ok to keep object in memory unlike web app. > so this call may be fine as i have a fully loaded report object in > memory. > Report.Section[0].LineItem[0].Delete(); > > so how would you come up with common object model that works for > both ...it is possible without writing more service layers? You have made a good job describing why report/section/lineitem should not be modelled as classes. Using relational algebra, your problem quickly disappears. Lets say we have relations as follow: report(reportid, ...) section(sectionid, ...) report_section(reportid, sectionid) lineitem(itemid, ....) section_lineitem(sectionid, itemid) Deleting a lineitem from a section, using relational algebra (using SQL language) would look like this: delete from section_lineitem where sectionid=? and itemid=? Problem solved. > -------------------------------------------------------------------------- > > Another use case.... > > Sections and line items can be deleted in the context of a report as i > described above > OR they can be deleted system wide by administrators .so if a section > or line item is not in use by any report presently admin can delete > them from the master list. delete from section where sectionid not in (select sectionid from report_section) > Should i use explicit interface implementation (c#)? > shoud i create separate classes and put them in separate name > spaces ..like admin.LineItem will have system wide delete function but > other line item class will not......this also is ugly because i am > creating two classes for same entity only because of this one > behavior..... Why do you need to create classes at all for these entities? //frebe
From: H. S. Lahman on 12 Apr 2008 10:16 Responding to siddharthkhare... Ignore Topmind and frebe. They are anti-OO P/R guys. > I have three main entities in system ............... report , > sections , lineItem. > > > Requirements : > a section can be create by assembling some line items together. > > a report can be created by assembling some sections together. > > A administrator will have functionality to delete or add to a master > list of sections and attributes. > so in other word there are delete and add operations happening on > sections and line items out side of a context of specific report. > > OK to model this.... > i will have a report object. That will hold a collections of sections > and each individual section will hold collection of line items. > > Something like this... > > > Report.Sections[i].lineItems[j].LineItemName Let's not confuse things with specific 3GL syntax. At the OOA/D level the model looks like: [Report] | 1 | | R1 | | contains | * [Section] | 1 | | R2 | | contains | * [LineItem] Since R1 and R2 are both 1:* associations, they will probably be implemented at the 3GL level with collection classes. > Now lets assume that there are two types of consumers that will using > this object model. A web applications, A windows think client > application Display is an entirely different subject matter from the semantics of reports. As such it is abstracted differently with its own unique suite of rules and policies. Thus the dominant object abstractions for a GUI would be Window/Control while the dominant abstractions for a browser would be Page/Section. So the display should be encapsulated in a subsystem or layer behind an interface. Then you can swap the subsystem for the appropriate display context while the subsystem that understands report semantics is completely unaffected because it uses the same interface to talk to both displays. <aside> You expressed a concern about not having objects for a browser UI. That should not matter. All display subsystems need to talk to the outside world somehow and that will vary with the display paradigm (e.g., the OS Window Manager for a GUI or a TCP/IP port for a browser). The display subsystem will have objects but when the display is actually rendered that will be done through sending messages to somebody outside the application using the protocols and conventions unique to the UI. IOW, the job of the UI subsystem is to convert the problem solution view to the view of the display paradigm de jour. To do that it has to abstract the display paradigm with objects properly. But those objects are essentially just data holders to facilitate formatting the control messages that must be issued to the hardware or OS. Also note that when one abstracts the display *paradigm* properly, it should be possible to reuse that subsystem in any application where that particular display paradigm is needed. All that changes are the data values and the initialization of the UI objects. The data comes from the user or the problem solution, so all one needs is identity mapping between the UI objects and the problem domain entities, which can be provided in external configuration data for the particular application. </aside> > > ------------------------------------------------------------------------------------------ > what I am trying to find out by this questions and discussion > is ..What is the best way to model this and how your object model will > change when you move from web app to windows app. The part of the application dealing with Report semantics would be unchanged. Each display paradigm would have its own subsystem that modeled that particular paradigm, as indicated above. > > Let's take example of web application .... > > Use case is delete first line item that is with in first section and > sections is inside a specific report object.. > > so code in my web page will look like this... > Report.Section[0].LineItem[0].Delete(); > > But this a web app. in most cases you will not keep your report object > on postbacks. And obviously for performance reason you are not going > to re-create the full report object again on post back and then call > delete on that ...so here is my first question.. > > Where would you put the method to delete the line item from report? The delete should be a method of the relevant collection object. However, whenever different subsystems operate on the same data, they need to be synchronized. That usually comes "for free" with UIs since the user is the one that will probably trigger the deletion by an action in the UI. So all the UI subsystem needs to do is notify the subsystem with the Report semantics about what the user did, which is its job in the first place. The subsystem with Report semantics would implement the response to that announcement in the relevant collection object, in this case for R2. IOW, the interface to the subsystem with the Report semantics will re-dispatch the UI's message to the appropriate collection class method. > > Would you put it as an instance method directly on report object..as > shwon below? > > Report.DeleteLineItem(SectionID,LineITemId) > > If yes...... > > But another consumer form my object model is a windows app ...where It > may be ok to keep object in memory unlike web app. > so this call may be fine as i have a fully loaded report object in > memory. > Report.Section[0].LineItem[0].Delete(); This is exactly why one should break up the application and modularize it around subject matters. The subsystem interfaces decouple the implementations so the Report semantics needs to know nothing about the actual UI implementation. > so how would you come up with common object model that works for > both ...it is possible without writing more service layers? The layered approach works for CRUD/USER applications so it is the way RAD IDEs work. However, for more complex problems one needs a 2D skeleton rather than a 1D skeleton. Modularization of the application is basic design to ensure maintainability. > > -------------------------------------------------------------------------- > > Another use case.... > > Sections and line items can be deleted in the context of a report as i > described above > OR they can be deleted system wide by administrators .so if a section > or line item is not in use by any report presently admin can delete > them from the master list. > > now question is what is the best place to put these delete method.... It goes in the same place. All you have added is the need to validate the user's privileges before actually invoking the deletion. That requires two things: (1) you have to know who the user is. (2) it needs to be done between the time the user triggers the action and before the collection delete method is invoked. Deciding where and how to validate privilege is a basic design issue that depends on a whole lot of different things. Unfortunately there may be conflicting considerations. For example, it is usually good practice to do user input checking as close to the user as possible (i.e., in the UI subsystem). OTOH, it is hard to rationalize that privilege validation is part of a specific display paradigm subject matter. (If privilege checking is fairly complicated, such as feature-based licensing, it might warrant its own subsystem.) Making such trade-offs will depend on a holistic view of the overall requirements and implementation technologies. So there is no "best" answer. -- There is nothing wrong with me that could not be cured by a capful of Drano. H. S. Lahman hsl(a)pathfindermda.com Pathfinder Solutions http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman "Model-Based Translation: The Next Step in Agile Development". Email info(a)pathfindermda.com for your copy. Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php. (888)OOA-PATH
From: topmind on 14 Apr 2008 00:36
On Apr 12, 8:16 am, "H. S. Lahman" <h...(a)pathfindermda.com> wrote: > Responding to siddharthkhare... > > Ignore Topmind and frebe. They are anti-OO P/R guys. > You say that like its a bad thing. > H. S. Lahman -T- |