Hi Lukas Looking at this I think you may have fallen or been pushed into the mistaken belief that OOP provides a way of designing applications. It don't! It is a means to producing class libraries of reusable software. In a half decent language, e.g. C++, Delphi, it also facilitates information hiding.
OOP design methodology - identify classes from the specification and try to fit them into hierarchies, identify dependencies (one class calls a method in another class), identify subsystems to reduce the length of dependency chains - gets you back to where you should have started in the first place. This is 100% bottom-up which is no way to design anything. The OOP approach results in long dependency chains that are hard work to modify and hell to debug. My tips are: Use a layered design: User interface / Functionality and operational rules / Access to persistent storage (i.e. files or database). This gets an initial structure and ensures scalability. See http://msdn2.microsoft.com/en-us/library/ms954595.aspx for example. For small to medium sized applications use component based design i.e. existing components are modified by changing property values. Inheritance to get a new component is a last resort. For large, unusual or multithreaded applications use a systems approach - Identify major subsystems within the three layers. Identify the subsystems they need to make them work, keeping an eye open for shared subsystems. Repeat until no more subsystems can be identified. Finally think about subsystems as classes and look at reuse of existing classes and components. Google search 'design patterns' e.g. http://dn.codegear.com/article/32049 et seq. and perhaps even get the GOF book. I hope this is useful. Otherwise, if you need to design class libraries or new sets of components, or your lecturer is an OOP believer, my article Scaleable Controls at http://www.thedelphimagazine.com/ might help. At least it has some pretty coloured diagrams. Martin On 12 Sep, 04:35, "Lukas Šalkauskas" <[EMAIL PROTECTED]> wrote: > Hi, > I'm interested in _thinking ways_ on designing OOP, Father->child->... > relations projection on big/small project. Maybe anyone can give a shot on > interesting books, articles in this area. Because for me is very difficult > to think that way, and I'm frequently lose a lot of time for designing > classes, relations and etc. :) > > Lukas. > > -- > You can contact me by : > Google Talk: [EMAIL PROTECTED] > Skype: halfas.online.now > IRC: HalFas` (irc2.omnitel.net) > Home page:http://www.revidev.com/halfas/ > One's leisure project:http://rvision.gamedev.lt/RVengine --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Algorithm Geeks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/algogeeks -~----------~----~----~----~------~----~------~--~---
