Loose Coupling and OO Practices for Beginners

Question

Keeping classes loosely coupled is an important aspect of writing code that is easy to understand, modify, and debug — I get this. However, as a beginner, almost every time I go beyond the simplest examples, I am afraid.

I understand, more or less, how I can encapsulate strings, integers and simple data types in my own classes. However, when I start dealing with information, such as formatting formatted text, everything becomes very complex - unless I use the various methods already present in the component. To continue this example, suppose I wrote something that included the RTF notes component in the user interface. In Delphi, the component has built-in methods for performing actions such as saving formatted text. In addition, sometimes it seems that the only (or at least the best) ways to work with RTF text are methods that are again built into the component.

How (or why) will I do all the work of saving, loading and formatting text in another class when I already have a component that does all this for me?

By myself, I usually end up either (a) doing something that seems much more complicated than necessary, reusing existing methods, or (b) creating poorly executed classes that are still closely related to each other. As the commercials say: "There must be a better way!"

I just lost conceptually on how this “best way” works. Any thoughts?

Answer 1

I believe that you have missed some basic concepts.

The idea of OOP begins with discrete, reusable units of logic. With a focus on creating self-contained modules.

In the case of the RTF Memo component, it meets the above criteria, processing this data set (memo) in such a way that your program and other objects in your program do not care how it works. The goal is to show the interface, accept data, manage these specific data and transfer that data to another part of your program.

The loosely coupled idea is that you can replace this recording control with another control that matches the same interface specifications. Namely, that you can create an instance of it, allow the user to interact with it and retrieve data when necessary.

Being loosely connected, it goes hand in hand with the idea of Separation of Problems (SoC); which is the process of breaking down a program into individual functions in order to reduce overlapping functionality and simplify management. But this is not the same thing. By the way, this was also one of the main factors pushing away from the procedural style of programming in OOP. Because OOP makes programming think in terms of connected and discrete functionality.

Sounds like you're really asking about SoC.

There are many ways to achieve SoC. Sometimes this is due to the fact that the user interface, processing logic, and strength layers are separated from each other (for example, the MVC design pattern). Sometimes it simply connects related functions to reduce complexity; which RTF control already performs, using all the functions necessary to manage the data so that you do not have other dependencies.

Answer 2

I would suggest two concepts, interfaces and dependency injections, as a way to separate your classes. Interfaces give you the opportunity to define a contract or a set of expected actions that are not dependent on any implementation. When your class depends on the interface, and not on the class, you get the opportunity to replace other classes that implement the interface without overwriting the class that depends on it.

When you use interfaces with dependency injection, that is, you provide the class with the actual implementation that it should work on, instead of creating a specific implementation yourself, you achieve even greater resolution in your application. Now the class knows about the interface and does not even know how to create it, just use it. Dependency injection is often used with creation templates such as Builder or Factory, where you localize the construction of objects in one class so that only this class changes when the application is expanded with additional classes.

Also, remember that communication (and its double, cohesion) is a relative measure. You cannot remove all couplings, or your objects will not be able to interact. A certain level of dependence is needed. You need to balance it with ease of use and implementation.

As for your specific example, it's hard to say without actual code. I suspect that you overestimate the decision and violate the DRY principle (do not repeat yourself). You may need to look at how to use interfaces and, possibly, a lightweight shell to separate your classes from the framework component, and not from a complete reevaluation.

Answer 3

Well, I'm not completely clear on this, but it looks like the strategy template will work here.

Create an object based on the parent RTF, but set processing methods for storage, etc. as defined objects using their own methods.

This allows you to use the composition without strict inheritance of all the parent methods, and you do not need to create a huge custom object, just replace the methods you need.

Answer 4

The example you have chosen is quite complex.

You are right when you say that the rtf memo component is very loosely coupled. It is so loose that it practically does not expand and can be used only as it is, since it combines the view / view, controller and model.

If you want to see an example of a well-designed extensible text system, check out the OS X text system documentation (or Gnustep if you want to read the code). This is difficult because there are many design decisions that need to be made and they need to be hidden from one module to another. There you can work directly in a good structure.

The rtf memo component has a limited scope that you may have to get around using well-designed classes:

• Downloading and saving component data makes sense if you do not need to save other data in your program in the same / db file.
• It also does not process large amounts of data.
• And he only understands a small subset of rtf.