Skip to main content

Object-Oriented Trinity - Part 3

I currently make a living as a Software Engineer, and I am also an ordained Anglican priest. In seminary, one assignment was to write a letter to a fictional friend, explaining the Trinity in some creative imagery.  My paper sought to use Object-Oriented concepts to shed light on this great mystery of faith. This is third in a 3-part series of posts that somewhat adapts that 2005 paper to the different medium of a Blog, and to refine with my understanding as it stands now of both the Trinity and Object-Oriented programming and design.

The first part is HERE.
The second part is HERE.

Hey Christian, I'm glad to hear that you are dazzling your new company with your brilliance.

So you think something is incomplete in our discussion so far about the Trinity and Object-Oriented design? You're right. The doctrine of the Trinity says that God Almighty is both One and Three, at the same time, and we have left a third out completely so far.

The Trinity's third Person is the “Holy Spirit.” This is not the divine “soul” or a euphemism for God’s actions, or thoughts, or inner being; if that were the case, it would not make sense to call this a Person. Christians claim that the Holy Spirit is sent forth from God. It is a personal, knowable, active agent, not an impersonal cosmic force like in Star Wars, and therefore is a Person in its own right. Some of the actions of this third Person are to speak, prompt, and teach us, and to unite us with God. The Spirit must be divine, as the Father and the Son are divine, and not just a creation or an abstraction – how else would it be able to join us to God?


Since the Spirit operates in a personal, active way, maybe I can compare it to Methods of a Class. Through class methods, actions are performed and state is changed. It is the methods, after all, that are most present to the rest of the system, with which other Objects interface. But the divine nature of the Spirit means it is also an instance of our “divine Being” Class in its own right.

But let's be careful! With three instances of our Class, we’re now in danger of saying we have three gods. Remember my first point: God is still One.

The three Persons – Father, Son and Spirit – all share the same nature. Each of the three is divine, in that they all consist of “God-stuff.” But there still is only one God. One of our Creeds says that they are “of one Being.” That is, the three Persons of the Trinity are distinct and unique, but not separate.

That description might call to mind the Composite design pattern, where a God Class consists of and contains the separate Father, Son and Spirit Objects.

But do you see the problem in that? It treats the Persons as separate gods. The doctrine of the Trinity says the three are united in communion – a church buzzword for harmony and unity. Love between the three is what binds them into one. They are related to one another in eternal love, and act in union with one another.

You might also read this and think of the Façade pattern. Remember that it is a Design Pattern which presents a different, simplified interface for a related bunch of complex classes. The Facade hides the complexities and simplifies interacting with objects of those classes, revealing only some of their Methods and attributes, perhaps varying them based on context.

I like the possibilities that concept presents for helping us humans to interact with the complexity of the divine. Could our finite brains really grasp the fullness and other-ness of God Almighty?

But when it comes to understanding the doctrine of the Trinity, by applying the Facade pattern to our understanding, I'm afraid that it, too, falls short. Doesn't it collapse the differences between Father, Son and Spirit? The Father is not another name for the Son, ditto for all their relationships. They differ, and those things that set them apart are both intrinsic to who they are, and eternal.

So where does that leave us? The triune God of Christianity is somewhat like a Singleton Class, but with three specific, inter-related instances that somehow do not produce a compile-time or runtime error.

Or how about this? Maybe God the Father is the Class definition, that establishes what it means to Be God. And maybe God the Son is the constructed Instance - after all, this divine Person is the one who became a physical human being. But let's leave the doctrine of the Incarnation for another day! And maybe God the Spirit is the set of Methods acting on our data and state.

In the end, the analogies can only take us so far, since God is not a computer program, but is far more complex and mysterious than we (even you, O brilliant Christian!) can understand.

Peace,
Steve

Popular posts from this blog

Git Reset in Eclipse

Using Git and the Eclipse IDE, you have a series of commits in your branch history, but need to back up to an earlier version. The Git Reset feature is a powerful tool with just a whiff of danger, and is accessible with just a couple clicks in Eclipse. In Eclipse, switch to the History view. In my example it shows a series of 3 changes, 3 separate committed versions of the Person file. After commit 6d5ef3e, the HEAD (shown), Index, and Working Directory all have the same version, Person 3.0.

Scala Collections: A Group of groupBy() Examples

Scala provides a rich Collections API. Let's look at the useful groupBy() function. What does groupBy() do? It takes a collection, assesses each item in that collection against a discriminator function, and returns a Map data structure. Each key in the returned map is a distinct result of the discriminator function, and the key's corresponding value is another collection which contains all elements of the original one that evaluate the same way against the discriminator function. So, for example, here is a collection of Strings: val sports = Seq ("baseball", "ice hockey", "football", "basketball", "110m hurdles", "field hockey") Running it through the Scala interpreter produces this output showing our value's definition: sports: Seq[String] = List(baseball, ice hockey, football, basketball, 110m hurdles, field hockey) We can group those sports names by, say, their first letter. To do so, we need a disc

Java 8: Rewrite For-loops using Stream API

Java 8 Tip: Anytime you write a Java For-loop, ask yourself if you can rewrite it with the Streams API. Now that I have moved to Java 8 in my work and home development, whenever I want to use a For-loop, I write it and then see if I can rewrite it using the Stream API. For example: I have an object called myThing, some Collection-like data structure which contains an arbitrary number of Fields. Something has happened, and I want to set all of the fields to some common state, in my case "Hidden"

How to do Git Rebase in Eclipse

This is an abbreviated version of a fuller post about Git Rebase in Eclipse. See the longer one here : One side-effect of merging Git branches is that it leaves a Merge commit. This can create a history view something like: The clutter of parallel lines shows the life spans of those local branches, and extra commits (nine in the above screen-shot, marked by the green arrows icon). Check out this extreme-case history:  http://agentdero.cachefly.net/unethicalblogger.com/images/branch_madness.jpeg Merge Commits show all the gory details of how the code base evolved. For some teams, that’s what they want or need, all the time. Others may find it unnecessarily long and cluttered. They prefer the history to tell the bigger story, and not dwell on tiny details like every trivial Merge-commit. Git Rebase offers us 2 benefits over Git Merge: First, Rebase allows us to clean up a set of local commits before pushing them to the shared, central repository. For this

Code Coverage in C#.NET Unit Tests - Setting up OpenCover

The purpose of this post is to be a brain-dump for how we set up and used OpenCover and ReportGenerator command-line tools for code coverage analysis and reporting in our projects. The documentation made some assumptions that took some digging to fully understand, so to save my (and maybe others') time and effort in the future, here are my notes. Our project, which I will call CEP for short, includes a handful of sub-projects within the same solution. They are a mix of Web APIs, ASP MVC applications and Class libraries. For Unit Tests, we chose to write them using the MSTest framework, along with the Moq mocking framework. As the various sub-projects evolved, we needed to know more about the coverage of our automated tests. What classes, methods and instructions had tests exercising them, and what ones did not? Code Coverage tools are conveniently built-in for Visual Studio 2017 Enterprise Edition, but not for our Professional Edition installations. Much less for any Commun