COBOL Encapsulation
Encapsulation is a fundamental principle of software design that bundles data and the procedures that operate on that data together, while hiding internal implementation details from other parts of the system. In COBOL, encapsulation is achieved through subprograms, program boundaries, and careful interface design. Understanding encapsulation helps you write maintainable, reliable, and professional mainframe applications.
This comprehensive guide will teach you how encapsulation works in COBOL, how to achieve it using subprograms and data hiding, and best practices for designing well-encapsulated programs. You'll learn how program boundaries create natural encapsulation, how WORKING-STORAGE provides data hiding, and how LINKAGE SECTION creates controlled interfaces that support modular, maintainable code.
What is Encapsulation?
Encapsulation is the practice of combining data and the operations that work on that data into a single unit, while restricting access to the internal details of that unit. Think of it like a vending machine: you put money in and press a button (the interface), and you get a snack. You don't need to know how the machine's internal mechanisms work - the gears, motors, and sensors are hidden inside. You only interact with the public interface (coin slot, buttons, product dispenser).
In programming, encapsulation provides several key benefits:
- Data Protection: Internal data structures are hidden and cannot be accidentally modified by other parts of the program.
- Implementation Hiding: How something works (the algorithm) is hidden, while what it does (the interface) is visible. This allows you to change the implementation without affecting code that uses it.
- Reduced Coupling: Programs depend only on interfaces, not on internal implementations, making the system more flexible and maintainable.
- Improved Maintainability: Changes to internal implementation don't affect other programs, making maintenance easier and safer.
- Better Organization: Related data and procedures are grouped together, making code easier to understand and navigate.
Encapsulation in COBOL
COBOL achieves encapsulation primarily through program boundaries. Each COBOL program is a self-contained unit with its own DATA DIVISION and PROCEDURE DIVISION. This natural boundary creates encapsulation because:
- Each program has its own WORKING-STORAGE that is completely private and inaccessible to other programs.
- Programs communicate only through controlled interfaces defined by the LINKAGE SECTION.
- Internal algorithms and data structures are hidden within each program.
- Changes to one program's internals don't affect other programs, as long as the interface remains compatible.
The Two Faces of a COBOL Program
Every COBOL program has two faces: the private, internal face and the public, interface face.
Private Face: WORKING-STORAGE SECTION
The WORKING-STORAGE SECTION contains data that is private to the program - it's encapsulated and hidden from other programs. This is where you store:
- Internal data structures used only within this program
- Temporary variables for calculations
- Flags and control variables
- Counters and accumulators
- Any data that other programs don't need to know about
This data is completely inaccessible to other programs. They cannot read it, modify it, or even know it exists. This is true encapsulation - the data is hidden.
Public Face: LINKAGE SECTION
The LINKAGE SECTION defines the public interface - the parameters that other programs can pass to and receive from this program. This is the controlled, limited way that programs communicate. The LINKAGE SECTION exposes only what is necessary for the program to do its job, hiding everything else.
This separation creates a clear boundary: WORKING-STORAGE is internal/private (encapsulated), while LINKAGE SECTION is external/public (the interface). This allows programs to change their internal implementation (WORKING-STORAGE) without affecting calling programs, as long as the interface (LINKAGE SECTION) remains the same.
Example: Encapsulated Account Management
Let's see encapsulation in action with an account management system. We'll create a subprogram that manages account balances, hiding the internal logic while exposing a simple interface.
Calling Program (Uses the Interface)
1234567891011121314151617181920212223242526272829303132333435363738IDENTIFICATION DIVISION. PROGRAM-ID. ACCOUNT-CLIENT. *> This program uses the account manager but doesn't know *> how it works internally - that's encapsulation! DATA DIVISION. WORKING-STORAGE SECTION. 01 ACCOUNT-INFO. 05 ACCOUNT-NUMBER PIC 9(8) VALUE 12345678. 05 ACCOUNT-BALANCE PIC S9(9)V99 VALUE 1000.00. 01 TRANSACTION-AMOUNT PIC S9(9)V99 VALUE 250.00. 01 RETURN-CODE PIC 9(2) VALUE 0. 88 SUCCESS VALUE 00. PROCEDURE DIVISION. MAIN-LOGIC. DISPLAY '=== Account Client Program ===' DISPLAY 'Account: ' ACCOUNT-NUMBER DISPLAY 'Balance: $' ACCOUNT-BALANCE *> Call the account manager - we only know the interface, *> not how it works internally CALL 'ACCOUNT-MANAGER' USING ACCOUNT-INFO TRANSACTION-AMOUNT RETURN-CODE ON EXCEPTION DISPLAY 'Error: Account manager not available' STOP RUN END-CALL IF SUCCESS DISPLAY 'Transaction processed' DISPLAY 'New Balance: $' ACCOUNT-BALANCE ELSE DISPLAY 'Transaction failed' END-IF STOP RUN.
Notice that the calling program:
- Knows what parameters to pass (the interface)
- Knows what to expect back (return code, modified balance)
- Does NOT know how the account manager works internally
- Cannot access any internal data in the account manager
Account Manager (Encapsulated Implementation)
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107IDENTIFICATION DIVISION. PROGRAM-ID. ACCOUNT-MANAGER. *> This program encapsulates account management logic. *> Internal details are hidden - only the interface is visible. DATA DIVISION. WORKING-STORAGE SECTION. *> ======================================== *> PRIVATE DATA - Hidden from other programs *> ======================================== 01 WS-MINIMUM-BALANCE PIC S9(9)V99 VALUE 100.00. 01 WS-MAXIMUM-BALANCE PIC S9(9)V99 VALUE 999999.99. 01 WS-TRANSACTION-FEE PIC S9(9)V99 VALUE 1.50. 01 WS-ACCOUNT-STATUS PIC X(1). 88 ACCOUNT-ACTIVE VALUE 'A'. 88 ACCOUNT-FROZEN VALUE 'F'. 01 WS-TEMP-CALCULATION PIC S9(9)V99. 01 WS-VALIDATION-FLAG PIC X(1). 88 VALID-TRANSACTION VALUE 'Y'. 88 INVALID-TRANSACTION VALUE 'N'. *> Internal counters and flags - completely hidden 01 WS-TRANSACTION-COUNT PIC 9(6) VALUE 0. 01 WS-ERROR-COUNT PIC 9(6) VALUE 0. LINKAGE SECTION. *> ======================================== *> PUBLIC INTERFACE - What callers can access *> ======================================== 01 LK-ACCOUNT-INFO. 05 LK-ACCOUNT-NUMBER PIC 9(8). 05 LK-ACCOUNT-BALANCE PIC S9(9)V99. 01 LK-TRANSACTION-AMOUNT PIC S9(9)V99. 01 LK-RETURN-CODE PIC 9(2). PROCEDURE DIVISION USING LK-ACCOUNT-INFO LK-TRANSACTION-AMOUNT LK-RETURN-CODE. MAIN-PROCESSING. *> Initialize MOVE 0 TO LK-RETURN-CODE SET INVALID-TRANSACTION TO TRUE *> Validate account (using private data) PERFORM VALIDATE-ACCOUNT IF VALID-TRANSACTION *> Process transaction (using private logic) PERFORM PROCESS-TRANSACTION *> Apply business rules (using private data) PERFORM APPLY-BUSINESS-RULES *> Update internal statistics (private) ADD 1 TO WS-TRANSACTION-COUNT MOVE 0 TO LK-RETURN-CODE ELSE *> Transaction failed ADD 1 TO WS-ERROR-COUNT MOVE 1 TO LK-RETURN-CODE END-IF EXIT PROGRAM. VALIDATE-ACCOUNT. *> Private procedure - callers don't know this exists IF LK-ACCOUNT-NUMBER = ZERO SET INVALID-TRANSACTION TO TRUE END-IF IF LK-ACCOUNT-BALANCE < WS-MINIMUM-BALANCE SET INVALID-TRANSACTION TO TRUE END-IF IF LK-TRANSACTION-AMOUNT <= ZERO SET INVALID-TRANSACTION TO TRUE END-IF IF VALID-TRANSACTION SET ACCOUNT-ACTIVE TO TRUE END-IF. PROCESS-TRANSACTION. *> Private procedure - internal implementation hidden COMPUTE WS-TEMP-CALCULATION = LK-ACCOUNT-BALANCE + LK-TRANSACTION-AMOUNT *> Check against maximum (using private constant) IF WS-TEMP-CALCULATION <= WS-MAXIMUM-BALANCE COMPUTE LK-ACCOUNT-BALANCE = LK-ACCOUNT-BALANCE + LK-TRANSACTION-AMOUNT ELSE SET INVALID-TRANSACTION TO TRUE END-IF. APPLY-BUSINESS-RULES. *> Private procedure - business logic is encapsulated *> Apply transaction fee (using private constant) IF LK-TRANSACTION-AMOUNT > 0 COMPUTE LK-ACCOUNT-BALANCE = LK-ACCOUNT-BALANCE - WS-TRANSACTION-FEE END-IF. *> All internal data (WS- variables) and procedures *> are completely hidden from calling programs. *> They can only interact through the LINKAGE interface.
Key encapsulation features in this example:
- Private Data (WORKING-STORAGE): Minimum balance, maximum balance, transaction fee, status flags, counters - all hidden from callers. The calling program cannot access or modify these values.
- Private Procedures: VALIDATE-ACCOUNT, PROCESS-TRANSACTION, APPLY-BUSINESS-RULES - these are internal implementation details that callers don't know about.
- Public Interface (LINKAGE): Only account info, transaction amount, and return code are exposed. This is the minimal interface needed.
- Implementation Freedom: We could change the validation logic, add new business rules, or modify internal calculations without affecting the calling program, as long as the interface (LINKAGE) remains the same.
Information Hiding
Information hiding is closely related to encapsulation. It means hiding the "how" (implementation) while exposing the "what" (interface). In our account manager example:
- What is exposed: "Process a transaction on an account" - callers know what the program does.
- What is hidden: How validation works, what business rules are applied, what fees are charged, what limits exist - callers don't need to know these details.
This separation allows you to:
- Change the implementation (how it works) without affecting callers
- Optimize internal algorithms without breaking existing code
- Fix bugs or improve logic in isolation
- Maintain different versions or implementations that share the same interface
Copy Books and Encapsulation
Copy books are shared source code files that contain data definitions. They support encapsulation in an interesting way:
- Shared Definitions: Multiple programs can use the same copy book to define data structures, ensuring consistency.
- Separate Instances: Each program still has its own private instance of the data - they share the "shape" but not the actual storage.
- Interface Consistency: When programs communicate, they can use copy books to ensure their LINKAGE definitions match, maintaining interface compatibility.
Example: Using Copy Books for Interface Definition
Here's how copy books can define shared interfaces while maintaining encapsulation:
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647*> ======================================== *> COPY BOOK: ACCOUNT-INTERFACE.cpy *> ======================================== *> This defines the interface structure that multiple *> programs can use, ensuring consistency 01 ACCOUNT-INTERFACE. 05 ACCOUNT-NUMBER PIC 9(8). 05 ACCOUNT-BALANCE PIC S9(9)V99. 05 ACCOUNT-TYPE PIC X(1). 05 ACCOUNT-STATUS PIC X(1). *> ======================================== *> CALLING PROGRAM *> ======================================== IDENTIFICATION DIVISION. PROGRAM-ID. CLIENT-PROGRAM. DATA DIVISION. WORKING-STORAGE SECTION. COPY ACCOUNT-INTERFACE. *> This creates a private instance of ACCOUNT-INTERFACE *> in this program's WORKING-STORAGE PROCEDURE DIVISION. MAIN-LOGIC. MOVE 12345678 TO ACCOUNT-NUMBER MOVE 1000.00 TO ACCOUNT-BALANCE *> ... use the data ... STOP RUN. *> ======================================== *> CALLED PROGRAM *> ======================================== IDENTIFICATION DIVISION. PROGRAM-ID. SERVER-PROGRAM. DATA DIVISION. LINKAGE SECTION. COPY ACCOUNT-INTERFACE. *> This creates the interface definition in LINKAGE *> It matches the structure but is a separate instance PROCEDURE DIVISION USING ACCOUNT-INTERFACE. PROCESS-LOGIC. *> Receive and process the account data *> ... processing ... EXIT PROGRAM.
The copy book ensures both programs use the same structure definition, but each program maintains its own separate instance of the data. This provides:
- Consistency: Both programs use identical structure definitions
- Encapsulation: Each program's instance is private to that program
- Maintainability: Change the copy book once, and all programs using it get the updated definition
Designing Encapsulated Interfaces
A well-designed encapsulated interface follows these principles:
1. Minimize the Interface
Expose only what callers absolutely need. Every parameter in LINKAGE SECTION is part of the public interface and creates a dependency. The smaller the interface, the more flexible and maintainable your program becomes.
Bad Example (Too Much Exposed):
12345678*> Exposing too many internal details LINKAGE SECTION. 01 LK-INTERNAL-FLAG-1 PIC X(1). *> Should be private 01 LK-INTERNAL-FLAG-2 PIC X(1). *> Should be private 01 LK-TEMP-VARIABLE PIC 9(5). *> Should be private 01 LK-COUNTER PIC 9(6). *> Should be private 01 LK-INPUT-DATA PIC X(50). *> OK - needed 01 LK-OUTPUT-RESULT PIC X(50). *> OK - needed
Good Example (Minimal Interface):
12345678*> Only expose what's necessary LINKAGE SECTION. 01 LK-PROCESSING-DATA. 05 LK-INPUT-DATA PIC X(50). 05 LK-OUTPUT-RESULT PIC X(50). 01 LK-RETURN-CODE PIC 9(2). *> Internal flags, temp variables, counters all stay *> in WORKING-STORAGE where they belong
2. Group Related Parameters
Instead of passing many individual parameters, group related ones into structures. This makes the interface cleaner and easier to understand.
12345678910*> Better: Grouped structure LINKAGE SECTION. 01 LK-CUSTOMER-DATA. 05 LK-CUSTOMER-ID PIC 9(8). 05 LK-CUSTOMER-NAME PIC X(30). 05 LK-CUSTOMER-ADDRESS PIC X(50). 01 LK-RETURN-CODE PIC 9(2). *> Instead of three separate parameters, we have one *> logical group that's easier to understand and maintain
3. Use Meaningful Names
Parameter names should clearly indicate their purpose. This makes the interface self-documenting and reduces the need for external documentation.
12345678910*> Good: Clear, meaningful names LINKAGE SECTION. 01 LK-ACCOUNT-BALANCE PIC S9(9)V99. 01 LK-TRANSACTION-AMOUNT PIC S9(9)V99. 01 LK-PROCESSING-RESULT PIC X(1). *> Bad: Unclear names 01 LK-DATA1 PIC S9(9)V99. 01 LK-DATA2 PIC S9(9)V99. 01 LK-FLAG PIC X(1).
4. Use Appropriate Parameter Passing
Use BY CONTENT for input-only parameters (protects them) and BY REFERENCE for output parameters (allows modification). This makes the interface's intent clear.
1234*> Clear intent through parameter passing CALL 'PROCESS-DATA' USING BY CONTENT INPUT-VALUE *> Input only BY REFERENCE OUTPUT-RESULT *> Output BY REFERENCE RETURN-CODE *> Output
Benefits of Encapsulation
Encapsulation provides numerous benefits that make your COBOL applications more professional and maintainable:
1. Reduced Coupling
Programs depend only on interfaces, not implementations. This means:
- Programs are less tightly connected
- Changes to one program don't cascade to others
- The system is more flexible and adaptable
2. Increased Cohesion
Related data and procedures are grouped together within each program:
- Each program has a clear, focused purpose
- Code is easier to understand and navigate
- Maintenance is localized to specific programs
3. Easier Maintenance
When you need to fix a bug or improve performance:
- Changes are isolated to one program
- You don't need to worry about breaking other programs
- Testing can focus on the changed program
4. Better Testing
Encapsulated programs can be tested in isolation:
- Test each program independently
- Mock or stub interfaces for testing
- Easier to identify and fix problems
5. Team Development
Multiple programmers can work simultaneously:
- Different programmers work on different programs
- They only need to agree on interfaces
- No conflicts over shared code
6. Code Reuse
Well-encapsulated programs can be reused:
- Use the same program in different contexts
- Share programs across projects
- Build libraries of reusable components
Encapsulation Within a Single Program
While true encapsulation with enforced boundaries requires subprograms, you can apply encapsulation principles within a single program through careful design:
- Group Related Data: Keep related data items together in WORKING-STORAGE, using group items to show relationships.
- Organize Procedures: Group related procedures together, using meaningful paragraph names that indicate their purpose and scope.
- Use Naming Conventions: Prefixes or naming patterns can indicate which data belongs to which logical component.
- Limit Scope: Design procedures to operate on specific data groups, avoiding procedures that access everything.
However, remember that within a single program, all WORKING-STORAGE is accessible throughout the program. True encapsulation with enforced data hiding requires program boundaries that only subprograms provide.
Common Encapsulation Mistakes
Understanding common mistakes helps you write better encapsulated code:
1. Exposing Too Much
Mistake: Putting internal data in LINKAGE SECTION that callers don't need.
Solution: Keep internal data in WORKING-STORAGE. Only put in LINKAGE what callers need to pass or receive.
2. Breaking Encapsulation
Mistake: Using global data or shared storage that bypasses the interface.
Solution: Always communicate through the LINKAGE interface. Don't use external storage or global variables to share data.
3. Unstable Interfaces
Mistake: Frequently changing the LINKAGE interface, breaking calling programs.
Solution: Design interfaces carefully from the start. Once other programs depend on an interface, keep it stable. Add new parameters rather than changing existing ones.
4. Mixing Concerns
Mistake: One program doing too many unrelated things.
Solution: Each program should have a single, well-defined responsibility. Split programs that do multiple things.
Complete Example: Encapsulated Calculator
Let's see a complete example that demonstrates good encapsulation:
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126IDENTIFICATION DIVISION. PROGRAM-ID. CALCULATOR-ENGINE. *> Encapsulated calculator - hides implementation details DATA DIVISION. WORKING-STORAGE SECTION. *> ======================================== *> PRIVATE: Internal calculation data *> ======================================== 01 WS-PRECISION PIC 9(2) VALUE 15. 01 WS-ROUNDING-MODE PIC X(1) VALUE 'N'. 88 ROUND-NEAREST VALUE 'N'. 88 ROUND-UP VALUE 'U'. 88 ROUND-DOWN VALUE 'D'. 01 WS-INTERNAL-RESULT PIC S9(15)V9(6). 01 WS-VALIDATION-FLAG PIC X(1). 88 VALID-OPERATION VALUE 'Y'. 01 WS-ERROR-COUNT PIC 9(6) VALUE 0. *> Internal operation codes - hidden from callers 01 WS-OP-ADD PIC X(1) VALUE 'A'. 01 WS-OP-SUBTRACT PIC X(1) VALUE 'S'. 01 WS-OP-MULTIPLY PIC X(1) VALUE 'M'. 01 WS-OP-DIVIDE PIC X(1) VALUE 'D'. LINKAGE SECTION. *> ======================================== *> PUBLIC: Minimal interface *> ======================================== 01 LK-CALCULATION-REQUEST. 05 LK-OPERAND-1 PIC S9(9)V99. 05 LK-OPERAND-2 PIC S9(9)V99. 05 LK-OPERATION PIC X(1). 01 LK-CALCULATION-RESULT PIC S9(9)V99. 01 LK-RETURN-CODE PIC 9(2). 88 SUCCESS VALUE 00. 88 ERROR-INVALID-OP VALUE 01. 88 ERROR-DIVIDE-ZERO VALUE 02. PROCEDURE DIVISION USING LK-CALCULATION-REQUEST LK-CALCULATION-RESULT LK-RETURN-CODE. MAIN-CALCULATE. *> Initialize MOVE 0 TO LK-RETURN-CODE MOVE 0 TO LK-CALCULATION-RESULT *> Validate (using private logic) PERFORM VALIDATE-REQUEST IF VALID-OPERATION *> Perform calculation (using private method) PERFORM EXECUTE-CALCULATION *> Format result (using private precision/rounding) PERFORM FORMAT-RESULT MOVE 0 TO LK-RETURN-CODE ELSE *> Validation failed ADD 1 TO WS-ERROR-COUNT MOVE 1 TO LK-RETURN-CODE END-IF EXIT PROGRAM. VALIDATE-REQUEST. *> Private: Callers don't know about this validation SET VALID-OPERATION TO TRUE *> Check operation code EVALUATE LK-OPERATION WHEN WS-OP-ADD WHEN WS-OP-SUBTRACT WHEN WS-OP-MULTIPLY WHEN WS-OP-DIVIDE CONTINUE WHEN OTHER SET INVALID-OPERATION TO TRUE END-EVALUATE *> Check for divide by zero IF LK-OPERATION = WS-OP-DIVIDE IF LK-OPERAND-2 = ZERO SET INVALID-OPERATION TO TRUE MOVE 2 TO LK-RETURN-CODE END-IF END-IF. EXECUTE-CALCULATION. *> Private: Internal calculation logic is hidden EVALUATE LK-OPERATION WHEN WS-OP-ADD COMPUTE WS-INTERNAL-RESULT = LK-OPERAND-1 + LK-OPERAND-2 WHEN WS-OP-SUBTRACT COMPUTE WS-INTERNAL-RESULT = LK-OPERAND-1 - LK-OPERAND-2 WHEN WS-OP-MULTIPLY COMPUTE WS-INTERNAL-RESULT = LK-OPERAND-1 * LK-OPERAND-2 WHEN WS-OP-DIVIDE COMPUTE WS-INTERNAL-RESULT = LK-OPERAND-1 / LK-OPERAND-2 END-EVALUATE. FORMAT-RESULT. *> Private: Formatting logic is hidden *> Apply precision and rounding (using private settings) IF ROUND-NEAREST COMPUTE LK-CALCULATION-RESULT ROUNDED = WS-INTERNAL-RESULT ELSE IF ROUND-UP COMPUTE LK-CALCULATION-RESULT = FUNCTION CEIL(WS-INTERNAL-RESULT) ELSE COMPUTE LK-CALCULATION-RESULT = FUNCTION FLOOR(WS-INTERNAL-RESULT) END-IF END-IF. *> All internal details (precision, rounding, validation, *> error counting, operation codes) are hidden. *> Callers only see: operands, operation, result, return code.
This calculator demonstrates excellent encapsulation:
- Private Implementation: Precision settings, rounding modes, validation logic, operation codes, error counting - all hidden in WORKING-STORAGE.
- Public Interface: Only operands, operation, result, and return code - the minimum needed.
- Flexibility: We could change the rounding algorithm, add new validation rules, or modify precision handling without affecting any calling programs.
Best Practices for Encapsulation
Follow these best practices to achieve good encapsulation:
- Keep Interfaces Minimal: Only expose what callers need. Every parameter in LINKAGE creates a dependency.
- Hide Implementation Details: Keep algorithms, internal data structures, and temporary variables in WORKING-STORAGE.
- Use Clear Naming: Interface names should clearly indicate purpose. Use prefixes (like LK- for linkage) to distinguish interface from internal data.
- Document Interfaces: Clearly document what each parameter represents, expected values, and return codes.
- Keep Interfaces Stable: Once other programs depend on an interface, avoid changing it. Add new parameters rather than modifying existing ones.
- One Responsibility: Each program should have a single, well-defined purpose.
- Use Copy Books for Interfaces: Share interface definitions through copy books to ensure consistency.
Explain Like I'm Five
Imagine you have a toy box with a special lid. You can put toys in through a slot (that's like passing parameters), and toys come out through another slot (that's like getting results back). But you can't see inside the box, and you can't reach in to grab things - you can only use the slots.
That's encapsulation! The toy box is like a COBOL program. Inside the box (WORKING-STORAGE), there might be all sorts of things - sorting mechanisms, counters, special tools - but you don't need to know about them. You just put toys in one slot and get them back from another slot (the LINKAGE interface).
The person who made the box (the programmer) can change what's inside - maybe they improve the sorting mechanism or add new tools - but as long as the slots work the same way, you (the calling program) don't notice any difference. That's why encapsulation is powerful - the inside can change, but the outside (the interface) stays the same!
Summary
Encapsulation is a fundamental principle that makes COBOL programs more maintainable, reliable, and professional. By using subprograms with clear boundaries, keeping internal data in WORKING-STORAGE, and exposing minimal interfaces through LINKAGE SECTION, you create programs that are easier to understand, test, and maintain.
The key is separation: private implementation (WORKING-STORAGE) is hidden, while public interface (LINKAGE SECTION) is controlled and minimal. This allows you to change how programs work internally without affecting other programs, as long as the interface remains compatible. By following encapsulation principles, you build systems that are flexible, maintainable, and ready for long-term evolution.
Test Your Knowledge
1. What is the primary mechanism for achieving encapsulation in COBOL?
- Using large WORKING-STORAGE sections
- Creating subprograms with controlled interfaces
- Using many PERFORM statements
- Putting all code in one program
2. Which section contains encapsulated (private) data in a COBOL program?
- LINKAGE SECTION
- FILE SECTION
- WORKING-STORAGE SECTION
- LOCAL-STORAGE SECTION
3. What does the LINKAGE SECTION represent in terms of encapsulation?
- Private internal data
- The public interface of the program
- File definitions
- Temporary storage
4. How do copy books support encapsulation?
- They share actual data storage between programs
- They share data structure definitions while maintaining separate data instances
- They eliminate the need for subprograms
- They make all data public
5. What is information hiding in COBOL?
- Hiding program names
- Hiding implementation details while exposing interfaces
- Hiding error messages
- Hiding file names
6. Why is encapsulation important for program maintenance?
- It makes programs run faster
- It allows internal changes without affecting other programs
- It reduces program size
- It eliminates the need for testing
7. What is a good practice for designing encapsulated interfaces?
- Expose as many parameters as possible
- Minimize the interface to only what callers need
- Put all data in LINKAGE SECTION
- Avoid using parameters
8. Can you achieve true encapsulation within a single COBOL program?
- Yes, through careful naming
- Limited - true encapsulation requires subprograms
- Yes, using PERFORM statements
- No, encapsulation is not possible in COBOL