Click here to Skip to main content
14,665,301 members
Rate this:
Please Sign up or sign in to vote.
See more:
I have a Command object-hierarchy that is being serialized and then deserialized (manually) in two sides of a connection, I'm assigning every Inherited object a different enum value (initializes the abstract Command in a different manner...) so I can know what I'm receiving.
Anyway... Now I'm working on a polymorphic handle of a command. I could just write a virtual method called "Handle", and every other Command would operate differently, but then I would have to supply some resources, like database connection, and the functionality to send a response to the sender, and that would of course be a major breach of encapsulation concept of OOP. On the other hand, My current design uses a switch statement on the enum value, and operates a handle method which is on the interpreter level, can talk to the Socket module, and the Database module.

Which one of the designs is better?
A. Virtual Handle method - possibly prettier polymorphic code, but with the need to provide access to the Socket and Database modules - bad encapsulation.
B. Ugly switch statement - semi-polymorphic code... Visual Studio Code Metrics doesn't seem to be very fond of it (<60 in maintainability and more cases will be added in the future...), but encapsulation is preserved...

Maybe there's a tweak that I'm missing? What would you guys recommend?
Posted

Rate this:
Please Sign up or sign in to vote.

Solution 1

Just use my fastJSON[^] code to serialize and deserialize, you won't need any kind of enum or switch statement as you will get the exact object at the other end.
   
Comments
ShacharK 16-Oct-11 9:10am
   
Nah, I'm satisfied with my own serialization... Its still not what I was asking.

My switch statement is applied when I'm willing to handle the received message within the handle thread. According to that design, my commands are nothing but structures that organize my data.

My question was whether I should be using virtual Handle methods, that would need some inputs that would contradict the program's logic, and its encapsulation, by giving the method access to many other modules. My "handler" is kind of a main module which operates the Socket modules and Database module. Don't you think that it would be weird?
Mehdi Gholam 16-Oct-11 9:24am
   
In a OO world create classes for each type of message and handle that specific type at the other end.
doMsg, saveMsg : Msg
doMsg -> handle(doMsg);
saveMsg -> handle(saveMsg);
ShacharK 16-Oct-11 9:43am
   
Of course, Every inherited Command builds the abstract Command base with different type, that's how I know what I'm building when deserializing them, and what are the values that I'm expecting.
The issue is the possible lack of Encapsulation, and not how to apply the Polymorphism. Whether I should just build an InheritedCommand and hide it behind a regular Command pointer. and then call command.Handle(All The Modules That Handle Might Require);
which of course would be much more aesthetic than a notorious switch-statement. A switch statement on the type would be followed by a cast to the actual command, and a set of operations in the module (Reply, Database Access, etc.) according to the specific properties of the message and state - decent encapsulation... but not very pretty.
Mehdi Gholam 16-Oct-11 10:00am
   
Any comment I make will probably be very hard for you to incorporate into your design as it would mean heavy re-engineering, so just go with the ugly switch statement :)
ShacharK 16-Oct-11 10:03am
   
Make them anyway, an extra opinion is always welcome...
Rate this:
Please Sign up or sign in to vote.

Solution 2

I think I would go for the "Ugly switch" statement, perhaps creating a DSL and a code generator to ease maintenance. xml, or even the assembly containing the enum, could also serve as the input to a small code generation tool.

Best regards
Espen Harlinn
   

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)




CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100