2

I am trying to figure out a design pattern to use (if any exists) to a situation where I would be re-doing some functionality across a bunch of classes. Below is a (simplified) overview of the problem I am facing:

I have some Java code to CREATE, UPDATE, DELETE Student objects, Professor object, & Staff objects. And every time such object is either created, deleted, or updated, I want to extract some information about the affected object(such as name, age, id) and notify an external service. So something like:

class StudentDAO {
   public Student createStudent(Student studentToCreate) {
       jdbcTemplate.update(INSERT_SQL, .....);
       //===> extract some info of the student
       //let external service know a student was created....
   }
   public Student deleteStudent(Student studentToDelete) {
       jdbcTemplate.update(DELETE_SQL, .....);
       //===> extract some info of the student
       //let external service know a student was deleted....
   }
   //same thing for update
}

class ProfessortDAO {
   public Professor createProfessor(Professor professorToCreate) {
       jdbcTemplate.update(INSERT_SQL, .....);
       //===> extract some info of the professor
       //let external service know a Professor was created....
   }
   public Student deleteProfessor(Professor professorToDelete) {
       jdbcTemplate.update(DELETE_SQL, .....);
       //===> extract some info of the professor
       //let external service know a professor was deleted....
   }
   //same thing for update
}

//repeat for Staff

The example is bit contrived but assume that Student, Professor, Staff share no inheritance hierarchy. Is there a way to achieve this functionality without copying and pasting the logic for extracting the info and sending it in all the DAO classes for CREATE, DELETE, UPDATE methods ?

  • 1
    I would recommend to replace "design pattern" in your post with "design". Some people here are allergic to the term. And make it more clear that your primary goal is reduction of code duplication among create/update/delete operations. – Euphoric Jun 23 at 18:12
  • There's nothing wrong with the term "design pattern," so long as the OP isn't trying to browse through a "catalog of software patterns" to find one that fits his particular problem. That's not the way design patterns work. Further, the OP made their question specific enough to be answerable (see the last paragraph). – Robert Harvey Jun 23 at 19:32
  • 1
    I agree with Robert but I think I see Euphoric's point. The obvious technique for solving this sort of problem is to extract the common logic to a separate function. This is so basic to programming that OP's desire to find a design pattern is troubling, and suggests a more fundamental issue in their understanding of software design. – John Wu Jun 24 at 6:46
1

I really don't see how simpler can it get than this:

class StudentDAO {
   public Student createStudent(Student studentToCreate) {
       jdbcTemplate.update(INSERT_SQL, .....);
       auditService.Created(studenToCreate.AuditInfo()):
   }
   public Student deleteStudent(Student studentToDelete) {
       jdbcTemplate.update(DELETE_SQL, .....);
       auditService.Deleted(studentToDelete.AuditInfo()):
   }
   public Student updateStudent(Student studentToUpdate) {
       jdbcTemplate.update(UPDATE_SQL, .....);
       auditService.Updated(studentToUpdate.AuditInfo()):
   }
}

I can imagine this getting more complicated, but you haven't provided any detailed information about how the auditing happens and what information you want to extract.

  • Your code tightly-binds auditService to the DTO's. That's not necessarily a bad thing, if the design decision is made up front that every DTO shall either include an AuditService or inherit from a class that has one. If the design goal is to be audit technology-agnostic, this won't get it done. – Robert Harvey Jun 23 at 19:00
  • 1
    @RobertHarvey And really, as long as interfaces are used, then the tight-binding can be loosened. – Euphoric Jun 23 at 19:43
  • What if I have 200+ classes like Student, Professor, & Staff ? Is there a way to avoid having to go to all of them and make the auditService call ? – sham Jun 23 at 20:26
  • 2
    @sham: if you have 200+ classes like that, you should already have a code generator in place to generate those DAO classes from some meta description. So simply extend that code generator. If you have no such generator, this is a good time to add one for your CRUD code. – Doc Brown Jun 23 at 20:49
  • @sham I'm not sure about Java. But it might be possible to use reflection to create override for each class and each method. Each override would include the audit call. – Euphoric Jun 24 at 5:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.