Polymorphism Vs. Encapsulation.

Question

0.00/5 (No votes)

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 16-Oct-11 2:52am

ShacharK

Add a Solution

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

Mehdi Gholam · Answer 1 · 2011-10-16T02:59:00

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.

Posted 16-Oct-11 2:59am

Mehdi Gholam

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...

Espen Harlinn · Answer 2 · 2011-10-16T03:04:00

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

Posted 16-Oct-11 3:04am

Espen Harlinn