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.