2 In-text link reassignment.
source | link

Think about what the open-closed principle entails: You have to write your methods in a way that you don't really know what the input is exactly, but you have to do something that depends on what exactly the input is.

Cf. a simple real-life example: You feel hungry (important abstraction: you don't directly care what you eat), so you go to a place where they serve food. Waiter shows up and asks you what you want. Consider the following two alternative algorithmic dialogs:

  • Is this a hamburger restaurant?
  • No.
  • Is this a seafood restaurant?
  • No.
  • Is this a pizza restaurant?
  • No.
  • Is this a bakery?
  • No
  • Is this a steak house?
  • Yes.
  • Great! I would like a prime-rib steak, medium rare please!

Over:

  • Would you please bring me something to eat?
  • Sure!

The problem with following the first logic is that... if you forget to ask for all types, you may end up not eating at all. So if that's the typical dialog, a new Chinese restaurant shows up, and you will never eat in there, until you "extend" your algorithmic dialog to include this possibility.

Regardless of the "artificiality" of the example, it shows that the open-closed principle has a very important consequence... You assign all tasks that are responsibilities of an object to the object itself. So your question boils down to:

How to abstract methods

Various languages have their own techniques. Because this is an extremely fundamental concept of OOP, OOP-tailored languages have this built-in. Abstractions are something like abstract classes / interfaces / etc. and implementations "fill-in" the details. In procedural languages, it comes down to "emulating" method calls.

As a result, the short answer to your question, regarding C, is, as suggested by Robert Harvey, the function pointeras suggested by Robert Harvey, the function pointer, which is the abstraction of a method that reveals what it does, but not how.

The long answer to your question is probably covered, in detail, in another answer regarding how to emulate OOP in C.

Think about what the open-closed principle entails: You have to write your methods in a way that you don't really know what the input is exactly, but you have to do something that depends on what exactly the input is.

Cf. a simple real-life example: You feel hungry (important abstraction: you don't directly care what you eat), so you go to a place where they serve food. Waiter shows up and asks you what you want. Consider the following two alternative algorithmic dialogs:

  • Is this a hamburger restaurant?
  • No.
  • Is this a seafood restaurant?
  • No.
  • Is this a pizza restaurant?
  • No.
  • Is this a bakery?
  • No
  • Is this a steak house?
  • Yes.
  • Great! I would like a prime-rib steak, medium rare please!

Over:

  • Would you please bring me something to eat?
  • Sure!

The problem with following the first logic is that... if you forget to ask for all types, you may end up not eating at all. So if that's the typical dialog, a new Chinese restaurant shows up, and you will never eat in there, until you "extend" your algorithmic dialog to include this possibility.

Regardless of the "artificiality" of the example, it shows that the open-closed principle has a very important consequence... You assign all tasks that are responsibilities of an object to the object itself. So your question boils down to:

How to abstract methods

Various languages have their own techniques. Because this is an extremely fundamental concept of OOP, OOP-tailored languages have this built-in. Abstractions are something like abstract classes / interfaces / etc. and implementations "fill-in" the details. In procedural languages, it comes down to "emulating" method calls.

As a result, the short answer to your question, regarding C, is, as suggested by Robert Harvey, the function pointer, which is the abstraction of a method that reveals what it does, but not how.

The long answer to your question is probably covered, in detail, in another answer regarding how to emulate OOP in C.

Think about what the open-closed principle entails: You have to write your methods in a way that you don't really know what the input is exactly, but you have to do something that depends on what exactly the input is.

Cf. a simple real-life example: You feel hungry (important abstraction: you don't directly care what you eat), so you go to a place where they serve food. Waiter shows up and asks you what you want. Consider the following two alternative algorithmic dialogs:

  • Is this a hamburger restaurant?
  • No.
  • Is this a seafood restaurant?
  • No.
  • Is this a pizza restaurant?
  • No.
  • Is this a bakery?
  • No
  • Is this a steak house?
  • Yes.
  • Great! I would like a prime-rib steak, medium rare please!

Over:

  • Would you please bring me something to eat?
  • Sure!

The problem with following the first logic is that... if you forget to ask for all types, you may end up not eating at all. So if that's the typical dialog, a new Chinese restaurant shows up, and you will never eat in there, until you "extend" your algorithmic dialog to include this possibility.

Regardless of the "artificiality" of the example, it shows that the open-closed principle has a very important consequence... You assign all tasks that are responsibilities of an object to the object itself. So your question boils down to:

How to abstract methods

Various languages have their own techniques. Because this is an extremely fundamental concept of OOP, OOP-tailored languages have this built-in. Abstractions are something like abstract classes / interfaces / etc. and implementations "fill-in" the details. In procedural languages, it comes down to "emulating" method calls.

As a result, the short answer to your question, regarding C, is, as suggested by Robert Harvey, the function pointer, which is the abstraction of a method that reveals what it does, but not how.

The long answer to your question is probably covered, in detail, in another answer regarding how to emulate OOP in C.

1
source | link

Think about what the open-closed principle entails: You have to write your methods in a way that you don't really know what the input is exactly, but you have to do something that depends on what exactly the input is.

Cf. a simple real-life example: You feel hungry (important abstraction: you don't directly care what you eat), so you go to a place where they serve food. Waiter shows up and asks you what you want. Consider the following two alternative algorithmic dialogs:

  • Is this a hamburger restaurant?
  • No.
  • Is this a seafood restaurant?
  • No.
  • Is this a pizza restaurant?
  • No.
  • Is this a bakery?
  • No
  • Is this a steak house?
  • Yes.
  • Great! I would like a prime-rib steak, medium rare please!

Over:

  • Would you please bring me something to eat?
  • Sure!

The problem with following the first logic is that... if you forget to ask for all types, you may end up not eating at all. So if that's the typical dialog, a new Chinese restaurant shows up, and you will never eat in there, until you "extend" your algorithmic dialog to include this possibility.

Regardless of the "artificiality" of the example, it shows that the open-closed principle has a very important consequence... You assign all tasks that are responsibilities of an object to the object itself. So your question boils down to:

How to abstract methods

Various languages have their own techniques. Because this is an extremely fundamental concept of OOP, OOP-tailored languages have this built-in. Abstractions are something like abstract classes / interfaces / etc. and implementations "fill-in" the details. In procedural languages, it comes down to "emulating" method calls.

As a result, the short answer to your question, regarding C, is, as suggested by Robert Harvey, the function pointer, which is the abstraction of a method that reveals what it does, but not how.

The long answer to your question is probably covered, in detail, in another answer regarding how to emulate OOP in C.