BorlandTalk.com Borland discussion newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Delphi OO design with Win32 API          BorlandTalk.com Forum Index -> Delphi OO design View previous topic :: View next topic   Author Message Charles Cooke Guest Posted: Tue Jun 06, 2006 8:53 pm    Post subject: Delphi OO design with Win32 API Hi, Having been working with D2005, and now D2006, for about 6 months, I continue to struggle with the difficulty of implementing 'good' OO-designed components in a system which utilizes a lot of Win32 API calls. For instance, I often find myself mixing Win32 message handlers in components that also handle business logic, and I just can't stand it! So, basically, what I'm asking is this: a) How do I cleanly separate my Win32 API calls from my business logic? I feel that the Delphi component paradigm wants me to implement bits of functionality on a per-component basis - does this mean that every individual business object should have a Win32 graphical portion and business logic portion? I don't like the idea of separating my business objects, but I see no way of presenting a consistent interface. The other 'solution' I've found is to use an inheritance hierarchy where each level of the hierarchy implements different functionality (one for the business logic, one for the graphical elements).. but this tight level of integration between completely separate functionality makes me go.. blech! b) Is it right to even create components at all when we're dealing with a business object? Ie. say I have a 'Widget' component that implements business logic without respect to any graphical views, etc. - is it proper to create this object as a component that can be installed in the IDE, or should it just be linked in as a regular class? Any thoughts? Back to top Jim Cooper Guest Posted: Tue Jun 06, 2006 9:36 pm    Post subject: Re: Delphi OO design with Win32 API Quote: For instance, I often find myself mixing Win32 message handlers in components that also handle business logic, and I just can't stand it! Fair enough too The two tings should be separate. Quote: does this mean that every individual business object should have a Win32 graphical portion and business logic portion? Definitely not. You should try to keep the two things separate (ie in different objects). Quote: b) Is it right to even create components at all when we're dealing with a business object? Not normally. An ordinary class is generally sufficient. Perhaps if you were a bit more specific in your questions we could provide more specific answers :-) Cheers, Jim Cooper _____________________________________________ Jim Cooper jcooper (AT) tabdee (DOT) ltd.uk Skype : jim.cooper Tabdee Ltd http://www.tabdee.ltd.uk TurboSync - Connecting Delphi to your Palm _____________________________________________ Back to top Charles Cooke Guest Posted: Tue Jun 06, 2006 10:39 pm    Post subject: Re: Delphi OO design with Win32 API Thanks for your response, Jim.. you're right, and I suppose I should bring the level of abstraction down a bit My 'slant' on this whole issue is that I'm trying to fit the MVC paradigm in here, and I'm not sure it's appropriate. Maybe by providing an example that illustrates my cognitive dissonance I might be a bit more helpful, based on a real life example with unnecessary detail removed: Business object X exists with properties (Height, Weight, Mass, Image).. (and many more) I wish to present this object graphically using the bitmap stored in the Image property, where it can be gleefully dragged around the screen from one window to another. At any point, I wish to have access to all the properties of the business object for display. However, the rub (for me) is that the object I'm using to provide graphical functionality (it does some funny stuff on drag/drop operations that uses the Win32 API directly) appears to also be the same place I need to store property values and other information regarding the object. Maybe the proper thing is to simply keep a reference to the business object in the graphical object? This still seems to strain encapsulation, in the sense that I think I have tied my GUI rather tightly to my domain layer, as I am now providing an interaction between a GUI element and a domain object without any centralized controller (or, if you will, with each element providing it's own controller).. easily devolves into chaos when I have many of these elements. So there's the problem.. how do I provide a clear separation between these GUI elements that need to know all my business object information, and my business objects? I appreciate any/all suggestions you can give.. been struggling with this one for quite a bit and my head is getting sore from banging it against the wall.. :) "Jim Cooper" <jcooper (AT) tabdee (DOT) ltd.uk> wrote in message news:4485aef5$1 (AT) newsgroups (DOT) borland.com... Quote: For instance, I often find myself mixing Win32 message handlers in components that also handle business logic, and I just can't stand it! Fair enough too The two tings should be separate. does this mean that every individual business object should have a Win32 graphical portion and business logic portion? Definitely not. You should try to keep the two things separate (ie in different objects). b) Is it right to even create components at all when we're dealing with a business object? Not normally. An ordinary class is generally sufficient. Perhaps if you were a bit more specific in your questions we could provide more specific answers :-) Cheers, Jim Cooper _____________________________________________ Jim Cooper jcooper (AT) tabdee (DOT) ltd.uk Skype : jim.cooper Tabdee Ltd http://www.tabdee.ltd.uk TurboSync - Connecting Delphi to your Palm _____________________________________________ Back to top Wayne Niddery [TeamB] Guest Posted: Tue Jun 06, 2006 11:23 pm    Post subject: Re: Delphi OO design with Win32 API Charles Cooke wrote: Quote: Business object X exists with properties (Height, Weight, Mass, Image).. (and many more) I wish to present this object graphically using the bitmap stored in the Image property, where it can be gleefully dragged around the screen from one window to another. By the *user* of your app, or by you during development? Quote: At any point, I wish to have access to all the properties of the business object for display. However, the rub (for me) is that the object I'm using to provide graphical functionality (it does some funny stuff on drag/drop operations that uses the Win32 API directly) appears to also be the same place I need to store property values and other information regarding the object. Again I'm not clear on whether you are trying to "componentize" you business objects so *you* can play with them visually during development or whether your users (who are not developers) need to move "objects" around on screen. Quote: Maybe the proper thing is to simply keep a reference to the business object in the graphical object? This still seems to strain encapsulation, in the sense that I think I have tied my GUI rather tightly to my domain layer, as I am now providing an interaction between a GUI element and a domain object without any centralized controller (or, if you will, with each element providing it's own controller).. easily devolves into chaos when I have many of these elements. So there's the problem.. how do I provide a clear separation between these GUI elements that need to know all my business object information, and my business objects? If this is for you as a develop then my answer would be that you should never try to make your business objects into components that you can drop on forms visually, always create them in code. If for your users, then... Is the image an inherent part of this business object, or is its sole purpose to provide a visual representation in the GUI? If the latter, then it should not be a property of the business object. Even if it is properly a part of the business object, the business object should take no part whatsoever in *displaying* that bitmap, it should just be a property the GUI is able to access. The GUI layer itself, or version of a View or Presenter class should be responsible for the GUI presentation of these objects. -- Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com) RADBooks: http://www.logicfundamentals.com/RADBooks.html "True peace is not the absence of tension, but the presence of justice." - Martin Luther King, Jr. Back to top Charles Cooke Guest Posted: Wed Jun 07, 2006 1:57 am    Post subject: Re: Delphi OO design with Win32 API "Wayne Niddery [TeamB]" <wniddery (AT) chaffaci (DOT) on.ca> wrote in message news:4485c811 (AT) newsgroups (DOT) borland.com... Quote: Charles Cooke wrote: Business object X exists with properties (Height, Weight, Mass, Image).. (and many more) I wish to present this object graphically using the bitmap stored in the Image property, where it can be gleefully dragged around the screen from one window to another. By the *user* of your app, or by you during development? At any point, I wish to have access to all the properties of the business object for display. However, the rub (for me) is that the object I'm using to provide graphical functionality (it does some funny stuff on drag/drop operations that uses the Win32 API directly) appears to also be the same place I need to store property values and other information regarding the object. Again I'm not clear on whether you are trying to "componentize" you business objects so *you* can play with them visually during development or whether your users (who are not developers) need to move "objects" around on screen. Maybe the proper thing is to simply keep a reference to the business object in the graphical object? This still seems to strain encapsulation, in the sense that I think I have tied my GUI rather tightly to my domain layer, as I am now providing an interaction between a GUI element and a domain object without any centralized controller (or, if you will, with each element providing it's own controller).. easily devolves into chaos when I have many of these elements. So there's the problem.. how do I provide a clear separation between these GUI elements that need to know all my business object information, and my business objects? If this is for you as a develop then my answer would be that you should never try to make your business objects into components that you can drop on forms visually, always create them in code. Good point.. this is purely from the users perspective. That is what I had suspected, and have been creating most of my objects as classes and not bothering with the design-time of the components, as it seems these are only worthwhile for static forms and nothing more than basic data manipulation. Quote: If for your users, then... Is the image an inherent part of this business object, or is its sole purpose to provide a visual representation in the GUI? If the latter, then it should not be a property of the business object. Even if it is properly a part of the business object, the business object should take no part whatsoever in *displaying* that bitmap, it should just be a property the GUI is able to access. The GUI layer itself, or version of a View or Presenter class should be responsible for the GUI presentation of these objects. Again, good point.. in fact, that's another issue that I had - the image is intended solely as a way to represent the object in the GUI. Totally reasonable that it should certainly be separate. Also, the View or Presenter class seems to be the way to go for me.. I'll try implementing that and seeing what happens. Thanks for your assistance. Quote: -- Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com) RADBooks: http://www.logicfundamentals.com/RADBooks.html "True peace is not the absence of tension, but the presence of justice." - Martin Luther King, Jr. Back to top Jim Cooper Guest Posted: Wed Jun 07, 2006 2:11 pm    Post subject: Re: Delphi OO design with Win32 API Quote: Maybe the proper thing is to simply keep a reference to the business object in the graphical object? As you say, you're missing the controller piece to hold things together. Normally you will have used the Observer pattern in the controller to make sure it reacts to changes in values in the business object, and then updates the relevant display objects. The controller ties everything together, so that there is no coupling between BO and display objects. There is coupling between the controller and the BOs, but that's necessary and OK. I have a simple example of the Observer and Mediator patterns from a talk last month at a conference in the Netherlands. If you want the slides and code drop me an email. Cheers, Jim Cooper _____________________________________________ Jim Cooper jcooper (AT) tabdee (DOT) ltd.uk Skype : jim.cooper Tabdee Ltd http://www.tabdee.ltd.uk TurboSync - Connecting Delphi to your Palm _____________________________________________ Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         BorlandTalk.com Forum Index -> Delphi OO design All times are GMT Page 1 of 1   Jump to: Select a forum C++ Builder Newsgroups----------------C++ BuilderC++ Builder (ActiveX)C++ Builder (Announcements)C++ Builder (Command Line Tools)C++ Builder DatabasesC++ Builder Databases (ADO)C++ Builder Databases (Desktop)C++ Builder Databases (InterBase Express)C++ Builder Databases (Multi-Tier)C++ Builder Databases (SQL Servers)C++ Builder (Graphics)C++ Builder (IDE)C++ Builder (Internet)C++ Builder (Internet Socket)C++ Builder (Internet Web)C++ Builder (Jobs)C++ Builder (Language)C++ Builder (Language C++)C++ Builder (Compatibility with MFC)C++ Builder (Native API)C++ Builder (Non-Technical)C++ Builder (Students)C++ Builder (Third Party Tools)C++ Builder (Upgrade)C++ Builder (VCL)C++ Builder (VCL Components Usage)C++ Builder (VCL Components Development)C++ Builder (VCL Usage)C++ Builder (WinAPI)C++ Builder Installation Delphi Newsgroups----------------Delphi (General)Delphi ActiveX Controls UsageDelphi ActiveX Controls DevelopmentDelphi As400Delphi DatabasesDelphi Databases (ADO)Delphi Databases (dbExpress)Delphi Databases (Desktop)Delphi Databases (InterBase Express)Delphi Databases (Multi-Tier)Delphi Databases (SQL Servers)Delphi DeploymentDelphi GraphicsDelphi IDEDelphi InternationalizationDelphi InternetDelphi Internet Isapi-WebBrokerDelphi Internet WebSnapDelphi Internet WinsockDelphi JobsDelphi Language BASMDelphi Language ObjectPascalDelphi Model Driven Architecture (General)Delphi Model Driven Architecture (Third Party)Delphi MultimediaDelphi Native APIDelphi Non-TechnicalDelphi ObjectPascalDelphi OLE AutomationDelphi OO designDelphi OpenToolsAPIDelphi Reporting-ChartingDelphi RTLDelphi StudentsDelphi TeamSourceDelphi Thirdparty ToolsDelphi Thirdparty Tools (General)Delphi Thirdparty Tools (IntraWeb)Delphi Thirdparty Tools (RaveReports)Delphi UpgradeDelphi VCLDelphi VCL ComponentsDelphi VCL Components UsingDelphi VCL Components WritingDelphi WebServices SOAPDelphi WinAPIDelphi XMLDelphi Installationcomp.lang.pascal.delphi.components.misccomp.lang.pascal.delphi.components.usagecomp.lang.pascal.delphi.components.writingcomp.lang.pascal.delphi.databasescomp.lang.pascal.delphi.misccomp.sources.delphi JBuilder Newsgroups----------------JBuilderJBuilder AnnouncementsJBuilder Applet IssuesJBuilder As400JBuilder CompilerJBuilder CORBA/RMIJBuilder DatabasesJBuilder DB SwingJBuilder DebuggerJBuilder DeploymentJBuilder DocumentationJBuilder EnterpriseJBuilder HandheldJBuilder IDEJBuilder JavaJBuilder JavaAPIJBuilder Java LanguageJBuilder Java SwingJBuilder Java BeansJBuilder Java Beans UsageJBuilder Java Beans DevelopmentJBuilder JBCLJBuilder JDataStoreJBuilder JobsJBuilder LinuxJBuilder MacintoshJBuilder & MobileSetJBuilder MultiLingual AppsJBuilder Non-TechnicalJBuilder OpenToolsJBuilder Servlets (JSP)JBuilder StudentsJBuilder Team DevelopmentJBuilder Thirdparty ToolsJBuilder UpgradeJBuilder Installation InterBase Newsgroups----------------InterBaseInterBase Bug DiscussionInterBase GeneralInterBase IBConsoleInterBase OpenSourceInterBase ReplicationInterBase SQLInterBase ThirdpartyInterBase Installation Miscellaneous Borland Newsgroups----------------AppCenterAppServerEnteraVisiBroker  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.