Keeping classes loosely coupled is an important aspect of writing code that is easy to understand, modify, and debug--I get that. As a newbie, though, just about anytime I get beyond the most simple examples I struggle.
I understand, more or less, how I can encapsulate strings, integers, and simple data types in classes of their own. When I start dealing with information like rich text formatting, however, things get really complicated--unless I just use the various methods already present in a component. To continue this example, suppose I was writing something that included an RTF memo component in the UI. In Delphi, the component has built-in methods for doing things like saving formatted text. In addition, sometimes it seems like the only (or at least best) ways to work with the RTF text itself is via methods again built into the component.
How (or why) would I do all the work of saving, loading, and formatting text in another class when I already have a component that does all of this for me?
On my own I usually end up either (a) doing something that seems much more complicated than need be, reinventing methods already present, or (b) creating poorly done classes that are still tightly coupled to one another. As they say in informercials, "There has to be a better way!"
I'm just lost conceptually on how that 'better way' works. Any thoughts?
I believe you've missed on some basic concepts.
The idea behind OOP starts with discrete, reusable units of logic. With an emphasis on creating self-sufficient modules.
In the case of the RTF Memo component, it meets the above criteria by handling a given set of data (the memo) in such a way that your program and other objects within your program don't care how it does it's job. It's purpose is to show an interface, accept data, manipulate that specific data, and pass that data on to another part of your program.
The idea behind being loosely coupled is simply that you can replace that memo control with another control which meets the same interface specifications. Namely, that you can instantiate it, let the user interact with it, and pull the data out when necessary.
Being loosely coupled goes hand in hand with the idea of Separation of Concerns (SoC); which is the process of breaking a program into distinct features in order to reduce overlapping functionality and make easier to manage. But they are not the same thing. Incidentaly, this was also one of the main drivers behind moving away from the procedural style of programming into OOP. As OOP forces the programming to think in terms of related and discrete functionality.
It sounds like you are really asking about SoC.
There are many ways to achieve SoC. Sometimes it involves keeping the UI, processing logic, and persistance layers separated (consider the MVC design pattern for example). Sometimes it is simply keeping related functions together in order to reduce complexity; which the RTF control already does by containing all of the functions necessary to manipulate the data so that you don't have further dependencies.
I would suggest two concepts, interfaces and dependency injection, as a way to decouple your classes. Interfaces give you a way to define a contract or set of expected behaviors that is independent of any implementation. When you have a class depend on an interface rather than on a class, you get the freedom to substitute other classes that implement the interface without having to rewrite the class that is depending on it.
When you use interfaces with dependency injection, i.e., give the class the actual implementation that it is to work on rather than have it create a particular implementation on its own, you achieve even more decoupling in your application. Now the class only knows about the interface and doesn't even know how to create it, just use it. Dependency injection is often used with creational patterns such as Builder or Factory, where you localize the construction of objects in a single class so that only that class need change when you extend the application with additional classes.
Also, remember that coupling (and its twin, cohesion) is a relative measure. You can't eliminate all coupling or your objects wouldn't be able to interact. Having some level of dependence is necessary. You need to balance it with ease of use and implementation as well.
As for your particular example, it's hard to tell without actual code. I suspect that you are over-engineering the solution and violating the DRY principle (don't repeat yourself). You may need to look at ways to use interfaces and perhaps a lightweight wrapper to decouple your classes from the framework component rather than a complete reimplementation.
Well, I'm not completely clear on the question, but it almost seems like the strategy pattern would work here.
Build an object based on your parent RTF object but set the handling methods for storing, etc. as defined objects with their own methods.
This enables the power of composition without strictly inheriting all the parent methods and you don't have to build a huge custom object, just replace the methods you need to.
The example you picked is rather complex.
You are right when you say that the rtf memo component is very loosely coupled. So loosely, that it is practically not extendable, and can only be used as is, as it integrates presentation/view, controller and model.
If you want to see an example of a well designed, extensible rich text system, take a look at the documentation of the OS X text system (or Gnustep, if you want to read the code). It is complex, because there are a lot of design decisions that need to be made and need to be hidden from one module to the other. There you can directly work in a good structure.
The rtf memo component has a limited scope of use, which you might have to work around using well-designed classes:
- The loading and saving of the components data only make sense if you don't have to save other data in your program in the same file/db.
- It also doesn't handle large amounts of data well.
- And it only understands a small subset of rtf.
来源：https://stackoverflow.com/questions/690869/loose-coupling-and-oo-practices-for-beginners