What is an object, and why does it matter?
Are you someone who writes code for a living? Do you write stateful applications with vast domains? Are objects part of the language you use to program these applications? If the answer to these questions is yes, then understanding and implementing Object Oriented programming promises to deliver flexible, robust and decoupled code that will serve its purpose long after it has been deployed.
Objects as Data Structures
At its most basic definition an object is a type of data structure like arrays and dictionaries. Objects are data structures that hold data and behaviour. Classes are a common construct associated to objects. Think of a class as an object whose sole purpose is to hold a mould and upon command using that mould to create other objects. Objects are capable of holding references, this is often referred to as the internal state of an object, and the references are called instance variables. They are prefixed with “instance” to make clear that this variable belong to the object in question , which is an instance of the class from which it was created. This data can be used from within the object and potentially exposed to the outside world.
Boundaries Are Key
It is difficult to think about objects without also talking about domains and boundaries. An object is the master of and inhabits a very small domain. But your software is not made up of only one object. Just like the domain of your software can be vast, so too can the number of object that make up the system. If you had a financial application one section of the domain would be the financial instruments your software deals with. The domain of financial instruments can be divided into the many different categories of financial instruments. In the same way a module of financial instruments objects can contain many objects each mastering one small section of the domain.
Because these “domain objects” have a clearly defined domain, the space between them can be described as a boundary. A domain object representing a stock has a clear boundary of any and all things that could be descriptive of a stock and a clear boundary to the domain of bonds.
Objects cannot do their work in isolation. They need to work in teams communicating across boundaries. Communication between the objects in your system is achieved by allowing one object to send a message to another.
Messages Across Boundaries
The messages that an object can receive are usually defined in the object’s mould. From it’s birth, an object knows what messages it can handle. The collection of messages that an object is capable of handling is referred to as its interface. The public interface is the collection of messages other objects can send, and the private interface is the collection of messages it can send itself. Think of the private interface as a set of instructions you write down to perform a task. These instructions are available to the receiving object but hidden from sender objects. Sender only know what to send, what the receiver does with that is all up to him because he is the master of it’s own domain, the boundaries are visible.
Object Oriented software is a collection of objects that are sending messages to one another to accomplish a task. The messages sent to one object might cause it to in turn message another object. Think of a graph were a system input causes a node to send a message to another node through the edge between them. The nodes are the objects, they are the entities who represent a well defined section of the overall domain. The edges are the boundaries between those domains that must be crossed to accomplish the task as a whole. An object is a cog, another object might be a screw or shaft. The sum of these parts creates your system.
Object Organization
Object Oriented software has been modelled by dividing the whole into parts, and structuring how those parts communicate with each other. There is no limit to what an object can do. Some objects will represent domain entities, others will perform orchestration, creation, or translation. These exist to facilitate the communication between other objects and respect their boundaries. The behaviour of your software as a whole is the sum of the behaviour of its objects. Different inputs will trigger different algorithms. These algorithms are made up of different combination of objects sending and receiving messages and performing some computation or “work”.
Code is Destined to change
Software is constantly evolving. Change is inevitable, we should not fight it but embrace it. The reasons for change are diverse, a company pivots, laws change what information can be stored, new features extend the functionality of an application. As systems grow and change entropy creeps in. Entropy causes domains to expand making objects masters of so much domain that boundaries become less visible. Entropy causes messages between objects to be lost in translation, or the same message being received multiple times. Entropy’s effects are compounded over time.
Object Oriented Design is the constant work of analyzing how a change affects a domain and its boundaries. Deciding weather to divide a domain and create new objects, or extend a domain and add to an interface of an existing object. Sometimes the change causes the communication patterns between the objects to change as well. Object oriented design accepts change as inevitable and provides a framework from which to manage change, minimizing it’s potential for entropy.
Benefits Of OOP
Object oriented design is flexible because the domain an object owns and the interface it exposes are well defined and respect boundaries. This means you can re-use these objects to form different combinations or algorithms for computation.
The boundaries between domain entities and the public interfaces defined by them allow objects to not depend on another object directly, but instead depend on being able to communicate with anyone through an interface. The receiver of the message does not matter because the details of what to do with the message are hidden. What matters is that the receiver accepts the message. The sender is decoupled from the receiver.
Objects are robust when they are decoupled from the other objects they depend on. A change in the internal mechanism of a receiver bears no effect on the sender. The sender can also change its own internal implementations and still depend on communicating with a receiver by using the interface the receiver exposes. Changes in one area of the domain do not bleed into others. Change is facilitated and entropy kept at bay.
Conclusion
If you use Object Oriented Design, defining domains and boundaries will get easier. Like any design discipline, it is done before construction begins. Object Oriented Design is something that can take time and practice to master. However acquiring these skills will not come overnight, and they will not come by only reading about it. Constant practise is needed, and good mentor ship will go a long way too.
