In-Reply-To: Danny's Object Oriented Programming Access Modifiers

Abstract

Danny van Heumen, my co-worker at GROUP9, has written a series of blog on his thoughts about Object Oriented Programming. In this blog I share my views on his ramblings ;-). The TL;DR version: I argue that his notion on access-modifiers and seemingly strange design choices are not caused by the design choices themselves but by not viewing OO design at the package level and the often seen way of defining packages in Enterprise applications where packages don't expose a clear, minimal API towards other packages.

On access-modifiers

At GROUP9, we've been discussing a
 bit about object oriented programming and designs and how to do it "right". In his post on access modifiers as part of a larger series of posts on OO, Danny argues a lacking access modifier and argues that the protected access modifier (the context is Java here) allows to wide access. I'm missing the actual explanation of which access modifier he's missing, however I'm presuming he's referring to the protected access modifier as defined by C#, which only allows access by subclasses.

I have to say I kinda disagree with him on this, as I think the designers of Java had specific thoughts on the definition of these access modifiers in the context of packages, which can be seen as a sort of mini-modules.

I've written this response before reading to the whole series, in the light of sparking the discussion, so I might have missed some of Danny's reasoning in further series.

The case for package level APIs

Danny's take on OO-design focusses on the design of the object itself, whereas I think what's lacking in this discussion is the design of the object in the context of a set of objects in a package. When thinking about Object Oriented design (this was somewhat way back), it occurred to me that in many Java EE projects I've come across a lot of Java developers hardly seem to think of packages as a way to really structure their code into various sub-modules.

The most clear example of this is the distinction between how you separate code into various packages, either based on common technical goals or based on the functionality they provide. A lot of projects I've seen separate their Objects into various technical packages, often called jpa, dao, service, etc. The result is that these packages don't offer a clear API, the packages are just used to group a set of classes which happen to share the same technical third-party dependency (JPA, Spring, etc) as a common denominator.

The other (in my opinion better approach) is to separate packages based on functionality. This implies objects with various technical goals can be present in the same package: they collaborate together to provide a specific functionality. From a development perspective, this seems more logical to me, as most of the time, I'm developing some specific functionality, extending the business value provided to the users of the system in some way. Changes to the system where you rip out a complete technical layer and replace it with another implementation are far more uncommon, therefore the separation into technical packages provide an organization I hardly even use.

Using access modifiers when thinking about package level APIs

If you take the notion of functionally separated packages one step further, one could argue that each package has a public API, which provides the functionality accessible by other parts of the system. The objects in the package collaborate (due to the SRP) together to achieve this functionality.

To test this way of developing an application (as opposed to just using packages which are functionally separated), I've created a plugin once for Atlasssian Confluence to see how it holds up in practice. This plugin was the NewCode macro, aptly named NewCode as there was also an old Code plugin ;-).

(This project has since been donated to Atlasssian where they are now using it in their own product and doing the development themselves, so the code publicly available may be in a somewhat abandoned state.)

Developing the project I had a few guidelines set-out for myself:
  • Each package should have a clear functional goal. The objects within a package collaborate to achieve that functional goal.
  • The default visibility of each method, or class within a package should be default (hey, that sounds logical, right :-))
  • Each package has a single or minimal set of Objects with public visibility, both at class and method level (i.e. they are the only ones who can be instantiated from the outside), that provide the API of that package.
Developing the project in this way forced me to really think of a clear separation between the various packages, the functionality they needed to expose and the API. In essence, it forced me to really think about High Cohesion, Low Coupling, at the package level. The end result I think was a codebase which was clearer to understand, as it was directly clear where there was impact when I needed to change any functionality.

In-reply-to: why protected may not be a bad idea

Given this setup, default visibility really makes sense to be the default. Within a package, Objects are closely bound to each other, and need low-level functionality provided by them to achieve their common goal. For the API, only a minimal set of methods and classes should be defined as public. Some part of the API may be exposed as base classes, which can be extended by other packages. However, the functionality provided in these methods may also often be needed by other Objects in the same package, warranting the choice to also expose protected methods to other objects within the same package.

An example design to illustrate this:


Package B provides an API in the form of a specific API class. It also provides a base classes needed by the API to do it's work. Therefore, it needs to access the protected methods of the base class, methods which we do not want to expose to any other object outside our package, as only the API class forms the outward facing API of our package. Package A has a subclass of said BaseClass, implementing logic specific to that package, but adhering to the contract as set out by the BaseClass. The Client classes uses these classes to provide it's own functionality, but doesn't need access to the protected methods. This class may even reside in a third package C, where the protected access level restricts access to these methods.

To make the example more concrete, we can use the already over-used example of Table classes, where the BaseClass is a base class for Tables, the API Class provides generic logic over tables (iterating, aggregating results, etc), and the SubClass provides the concrete implementation for a Table in the MySQL database.

In conclusion

Although I do understand where Danny's view on access modifiers comes from, I think his notion stems the way enterprise applications are designed at the package level. Granted, designing enterprise applications in the way I outlined above can be challenging given multiple tiers, large scale applications, etc. However, thinking about packages as mini-APIs allows for applications which are much easier to adapt, where each package provides a clear set of functionality and therefore changes to the functionality are often very local. In this sense, this way of package design can be viewed as a low-level form of MicroServices, where each service also provides a specific, small set of functionality. But that is food for thought for a whole different blog post :-).

Comments

Post a Comment

Popular posts from this blog

Validations across micro-services

Image
On my day-job as a consultant for GROUP9  we had an interesting discussion on how to handle validations across micro-services. Let's look at this in the context of a fictionalized example. Example: amazon selling for other companies The case we were discussing was the typical case of referential integrity between two objects. Imagine this: we're Amazon, and being a large e-commerce platform, we want to enable other sellers to use our platform to sell their products, while we handle all the logistics (and of course get a percentage on every sale 😁). To achieve this, we come to an agreement with a seller after some negotiations, e.g. agreeing on the commission percentage we receive on every sale. During these negations, we can add some of the products of that seller to our platform, show them the pricing, additional information etc, so the seller can have an idea what his products would look like when promoted on our platform. Being Amazon, we of course have a micro-services lan...
Read more

Bridging the world of Event Storming and BPMN

Image
In a recent post , Bernd Ruecker made a nice post on a pattern to transform events to commands in MicroServices and DDD. The post discusses the differences between Choreography and Orchestration as two major styles in which various micro-services can be connected and the pros and cons of these styles. Creating business process based systems using DDD is something I've been working on quite a bit. In this post, I would like to take this one step further and also show how the worlds of BPMN and DDD have a very nice fit, even b eyond than just this pattern. To do this, I'm going to make a connec tion between BP MN and a prominent style of analysis in the DDD world - Event Storming by Alberto Brandolini . Also, I'd like to dive into how the strategic design parts of DDD can help us in guiding us where we would like to apply these patterns. The latter will be subject of a later post. Event Storming First things first, lets look at Event Storming and how it is used in DD...
Read more

From Multi-Threaded applications to Multi-Time applications

Image
At the DDD Europe conference.. Recently, I visited the DDD Europe  conference, where Vaughn Vernon held a talk on using Akka an the Actor model to implement applications, based on the principles of Domain Driven Design. This talk, combined with some recent issues I've been facing at my customers site, inspired me to think about the design issues you face when developing multi-time applications. But let's start with what Vernon was talking about at his talk. Vernons talk His main premise: the Actor model is a more simplified model for application development, while at the same time providing a thread-safe environment to fully make use of the ever increasing number of cores processors have. While CPUs don't get any faster, in terms of pure clock speed, they do get more cores, and the we need to adapt our software to make use of these multiple cores. Traditional programming models don't scale nicely because of IO waits causing the software to block and the CPU being ...
Read more