I've searched for a number of articles on refactoring a large switch statement.
But they don't do what I want to do. The problem I'm going to to run in to is having a gigantic switch statement which calls a different method depending on two different values, lets say a type and a code.
Currently, I would handle the situation like this:
switch (type)
{
case Types.Type1:
handleType1(code);
break;
case Types.Type2:
handleType2(code);
break;
}
void handleTypeN(code)
{
switch (code)
{
...
}
}
Maybe something which combines the factory and command pattern would help me out? I must be missing something obvious.
How would you refactor this code?
I might need to get a little more specific as to what scenario I'm facing.
I'm receiving packets from a server. A packet contains a type and a code and some specific information.
As soon as data arrives I retrieve the type and the code of the packet and it goes in to the switch statement for the type, after figuring out the type a specific method is called to perform a switch on the code of the packet.
The method that handles the code now decodes the packet further and the process is done.
+----------+ +----------+
| | Packet | |
| Server | -------------> | Client |
| | | |
+----------+ +----------+
|
|
(Switch on the type of the packet and call a specific method)
|
|
(Switch on the code of the packet and call a specific method)
|
|
(Respond to the server or not)
2 pattern comes in mind : command and visitor :
http://en.wikipedia.org/wiki/Command_pattern
http://en.wikipedia.org/wiki/Visitor_pattern
Abstract Class Command {
executeSomething();
}
Class typeN extends command {
executeSomething() {
//...
}
}
Class typeM extends command {
executeSomething() {
//...
}
}
replace your switch by :
//my old switch
class commandManager {
processCommand() {
for listOf command in a command buffer
{
onCommand(listOfcommand.command)
}
}
onCommandPoped(command type) {
type.executeSomething()
}
}
you can pass parameters to executeSomething, and you can pass another command
the client code :
{
commandN = new CommandN()
commandManager.postCommand( commandN)
}
After reading your packet server use case, I think you can use a variant of strategy pattern
http://www.oodesign.com/strategy-pattern.html
where you choose the strategy to call when the packet arrive
you can build this with a factory.
but you will not kill your switch case
Keep in mind, that a server can serve many client. If it's maybe your switch cases are faster than object instanciation.
I think it depends what kind of code improvement you're trying to do.
If you have the luxury of actually making big design changes, then I'd suggest polymorphism:
Create an abstract Packet class.
Create a class for each packet type.
Create a factory method, that receives a raw server packet, and creates the right packet class object.
Each packet class type will have its own implementation of the job it needs to do.
If you don't have the luxury of doing large design changes (which is often the case):
If you want to improve readability :
Keep the switch, each switch case will call a properly named function that will do what it needs to.
If you want to increase performance:
Create a matrix, that for each cell [T,C] will hold a reference to a function that will handle a Packet with Type T and Code C.
The matrix should be initiated once (hard-coded, no way around that) at startup of program or class.
This will give you better performance than a long switch block (direct access to code, no logical comparisons)
I'd build a table with types which points to tables with codes, which in turn points to the implementing function to call for that type/code pair.
lookup_type_table[type_low .. type_high] = { lookup_code_table_type_1, lookup_code_table_type_2, ...};
lookup_code_table_type_1[type_1_code_low .. type_1_code_high] = { type1_code1_func_pointer, ... };
int processPacket(int type, int code, paket_t data) {
/* apply boundary checks on the lookup tables here! */
return lookup_type_table[type][code](data);
}
The tables could be implemented as linked lists, or with some other fancier container implementation to make them more dynamic, if needed.
This might not be as object-oriented as some other patterns, but I'm coming from a C-background :)
Having the mappings in tables adds the possibility to generate them from some other DSL spec though, boosting your DRY stats...
You can replace your switches with a dictionary of dictionaries which points to the actual methods or better classes to handle the packets. The first dictionary using type as index and the second using code as index.
But then you will have replaced the switch statements by the creating of the dictionaries, so in the end there isn't much difference.
You should have a look to the state pattern too, this kind of stuff is what its actually made for.
Related
Extensible records were one of the most amazing Elm's features, but since v0.16 adding and removing fields is no longer available. And this puts me in an awkward position.
Consider an example. I want to give a name to a random thing t, and extensible records provide me a perfect tool for this:
type alias Named t = { t | name: String }
„Okay,“ says the complier. Now I need a constructor, i.e. a function that equips a thing with specified name:
equip : String -> t -> Named t
equip name thing = { thing | name = name } -- Oops! Type mismatch
Compilation fails, because { thing | name = ... } syntax assumes thing to be a record with name field, but type system can't assure this. In fact, with Named t I've tried to express something opposite: t should be a record type without its own name field, and the function adds this field to a record. Anyway, field addition is necessary to implement equip function.
So, it seems impossible to write equip in polymorphic manner, but it's probably not a such big deal. After all, any time I'm going to give a name to some concrete thing I can do this by hands. Much worse, inverse function extract : Named t -> t (which erases name of a named thing) requires field removal mechanism, and thus is not implementable too:
extract : Named t -> t
extract thing = thing -- Error: No implicit upcast
It would be extremely important function, because I have tons of routines those accept old-fashioned unnamed things, and I need a way to use them for named things. Of course, massive refactoring of those functions is ineligible solution.
At last, after this long introduction, let me state my questions:
Does modern Elm provides some substitute for old deprecated field addition/removal syntax?
If not, is there some built-in function like equip and extract above? For every custom extensible record type I would like to have a polymorphic analyzer (a function that extracts its base part) and a polymorphic constructor (a function that combines base part with additive and produces the record).
Negative answers for both (1) and (2) would force me to implement Named t in a more traditional way:
type Named t = Named String t
In this case, I can't catch the purpose of extensible records. Is there a positive use case, a scenario in which extensible records play critical role?
Type { t | name : String } means a record that has a name field. It does not extend the t type but, rather, extends the compiler’s knowledge about t itself.
So in fact the type of equip is String -> { t | name : String } -> { t | name : String }.
What is more, as you noticed, Elm no longer supports adding fields to records so even if the type system allowed what you want, you still could not do it. { thing | name = name } syntax only supports updating the records of type { t | name : String }.
Similarly, there is no support for deleting fields from record.
If you really need to have types from which you can add or remove fields you can use Dict. The other options are either writing the transformers manually, or creating and using a code generator (this was recommended solution for JSON decoding boilerplate for a while).
And regarding the extensible records, Elm does not really support the “extensible” part much any more – the only remaining part is the { t | name : u } -> u projection so perhaps it should be called just scoped records. Elm docs itself acknowledge the extensibility is not very useful at the moment.
You could just wrap the t type with name but it wouldn't make a big difference compared to approach with custom type:
type alias Named t = { val: t, name: String }
equip : String -> t -> Named t
equip name thing = { val = thing, name = name }
extract : Named t -> t
extract thing = thing.val
Is there a positive use case, a scenario in which extensible records play critical role?
Yes, they are useful when your application Model grows too large and you face the question of how to scale out your application. Extensible records let you slice up the model in arbitrary ways, without committing to particular slices long term. If you sliced it up by splitting it into several smaller nested records, you would be committed to that particular arrangement - which might tend to lead to nested TEA and the 'out message' pattern; usually a bad design choice.
Instead, use extensible records to describe slices of the model, and group functions that operate over particular slices into their own modules. If you later need to work accross different areas of the model, you can create a new extensible record for that.
Its described by Richard Feldman in his Scaling Elm Apps talk:
https://www.youtube.com/watch?v=DoA4Txr4GUs&ab_channel=ElmEurope
I agree that extensible records can seem a bit useless in Elm, but it is a very good thing they are there to solve the scaling issue in the best way.
I am working on a distributed algorithm and decided to use a Akka to scale it across machines. The machines need to exchange messages very frequently and these messages reference some immutable objects that exist on every machine. Hence, it seems sensible to "compress" the messages in the sense that the shared, replicated objects should not be serialized in the messages. Not only would this save on network bandwidth but it also would avoid creating duplicate objects in the receiver side whenever a message is deserialized.
Now, my question is how to do this properly. So far, I could think of two options:
Handle this on the "business layer", i.e., converting my original message objects to some reference objects that replace references to the shared, replicated objects by some symbolic references. Then, I would send those reference objects rather than the original messages. Think of it as replacing some actual web resource with a URL. Doing this seems rather straight-forward in terms of coding but it also drags serialization concerns into the actual business logic.
Write custom serializers that are aware of the shared, replicated objects. In my case, it would be okay that this solution would introduce the replicated, shared objects as global state to the actor systems via the serializers. However, the Akka documentation does not describe how to programmatically add custom serializers, which would be necessary to weave in the shared objects with the serializer. Also, I could imagine that there are a couple of reasons, why such a solution would be discouraged. So, I am asking here.
Thanks a lot!
It's possible to write your own, custom serializers and let them do all sorts of weird things, then you can bind them at the config level as usual:
class MyOwnSerializer extends Serializer {
// If you need logging here, introduce a constructor that takes an ExtendedActorSystem.
// class MyOwnSerializer(actorSystem: ExtendedActorSystem) extends Serializer
// Get a logger using:
// private val logger = Logging(actorSystem, this)
// This is whether "fromBinary" requires a "clazz" or not
def includeManifest: Boolean = true
// Pick a unique identifier for your Serializer,
// you've got a couple of billions to choose from,
// 0 - 40 is reserved by Akka itself
def identifier = 1234567
// "toBinary" serializes the given object to an Array of Bytes
def toBinary(obj: AnyRef): Array[Byte] = {
// Put the code that serializes the object here
//#...
Array[Byte]()
//#...
}
// "fromBinary" deserializes the given array,
// using the type hint (if any, see "includeManifest" above)
def fromBinary(
bytes: Array[Byte],
clazz: Option[Class[_]]): AnyRef = {
// Put your code that deserializes here
//#...
null
//#...
}
}
But this raises an important question: if your messages all references data that is shared on the machines already, why would you want to put in the message the pointer to the object (very bad! messages should be immutable, and a pointer isn't!), rather than some sort of immutable, string objectId (kinda your option 1) ? This is a much better option when it comes to preserving the immutability of the messages, and there is little change in your business logic (just put a wrapper over the shared state storage)
for more info, see the documentation
I finally went with the solution proposed by Diego and want to share some more details on my reasoning and solution.
First of all, I am also in favor of option 1 (handling the "compaction" of messages in the business layer) for those reasons:
Serializers are global to the actor system. Making them stateful is actually a most severe violation of Akka's very philosophy as it goes against the encapsulation of behavior and state in actors.
Serializers have to be created upfront, anyway (even when adding them "programatically").
Design-wise, one can argue that "message compaction is not a responsibility of the serializer, either. In a strict sense, serialization is merely the transformation of runtime-specific data into a compact, exchangable representation. Changing what to serialize, is not a task of a serializer, though.
Having settled upon this, I still strived for a clear separation of "message compaction" and the actual business logic in the actors. I came up with a neat way to do this in Scala, which I want to share here. The basic idea is to make the message itself look like a normal case class but still allow these messages to "compactify" themselves. Here is an abstract example:
class Sender extends ActorRef {
def context: SharedContext = ... // This is the shared data present on every node.
// ...
def someBusinessLogic(receiver: ActorRef) {
val someData = computeData
receiver ! MyMessage(someData)
}
}
class Receiver extends ActorRef {
implicit def context: SharedContext = ... // This is the shared data present on every node.
def receiver = {
case MyMessage(someData) =>
// ...
}
}
object Receiver {
object MyMessage {
def apply(someData: SomeData) = MyCompactMessage(someData: SomeData)
def unapply(myCompactMessage: MyCompactMessage)(implicit context: SharedContext)
: Option[SomeData] =
Some(myCompactMessage.someData(context))
}
}
As you can see, the sender and receiver code feels just like using a case class and in fact, MyMessage could be a case class.
However, by implementing apply and unapply manually, one can insert its own "compactification" logic and also implicitly inject the shared data necessary to do the "uncompactification", without touching the sender and receiver. For defining MyCompactMessage, I found Protocol Buffers to be especially suited, as it is already a dependency of Akka and efficient in terms of space and computation, but any other solution would do.
What is the best practice regarding returning error codes?
Sometimes we meet situations where a class method operation is unsuccessful, but it is not exceptional. If the reason why it fails are varied, then we need a way to tell the caller why it has failed.
For example, I have Actor::equipItem() method that equips an item to an RPG character object. The reasons for failure could be:
Character level is not high enough.
Character class cannot equip that item.
Character attribute is not sufficient (e.g. not enough strength).
The item is already broken.
The item is a two handed weapon and the character is already wielding a dagger.
etc.
The way I see it, the situations above are not exceptional. I can implement Actor::equipItem() in two ways.
First is returning int codes, like 0 for success and 1 for the level is not enough, 2 for wrong character class and so on.
The second is returning boolean TRUE or FALSE, and implementing Actor::getLastErrorCode() that the caller can inspect if it needs to provide a feedback to the user.
Which of the two is the best practice in terms of OOP and API design? Are there alternatives? Is there a best practice for handling error codes that are not exceptional situations?
Like I said, I agree with cHao that throwing exceptions is the right way to handle this. However, I wanted to comment on how you might decide to process all of those rules. This scenario is a perfect situation for a rules engine, using good ol' polymorphism. (Checking out the chain of responsibility (CoR) design pattern would be good for this.)
You could use a bunch of if statements in your method. Or, better yet, have each if check be its own class that implements something like IEquipItemRule:
public interface IEquipItemRule
{
bool CanEquip();
}
Then, instead of an if statement, your consuming code can process all of the rules like this:
List<IEquipItemRule> equipRules = GetEquipRules(); // This is where the CoR pattern comes in
foreach (IEquipItemRule rule in equipRules)
{
// Note: Instead of throwing immediately, you could collect all of the
// messages and return all of the failure reasons.
if (!rule.CanEquip()) { throw new AppropriateException(rule.Message); }
}
The nice thing about this is that this check can be in its own method. So, if you want to check first to see if this method will succeed, the consumer can call the above code. And when the actual method runs, it can call this checking code as well.
Note: An example of an equipment rule might be something like this:
public class CharacterLevelRule : IEquipItemRule
{
public bool CanEquip()
{
if (characterLevel <= necessaryLevel) { return false; }
return true;
}
}
I have slightly peculiar program which deals with cases very similar to this
(in C#-like pseudo code):
class CDataSet
{
int m_nID;
string m_sTag;
float m_fValue;
void PrintData()
{
//Blah Blah
}
};
class CDataItem
{
int m_nID;
string m_sTag;
CDataSet m_refData;
CDataSet m_refParent;
void Print()
{
if(null == m_refData)
{
m_refParent.PrintData();
}
else
{
m_refData.PrintData();
}
}
};
Members m_refData and m_refParent are initialized to null and used as follows:
m_refData -> Used when a new data set is added
m_refParent -> Used to point to an existing data set.
A new data set is added only if the field m_nID doesn't match an existing one.
Currently this code is managing around 500 objects with around 21 fields per object and the format of choice as of now is XML, which at 100k+ lines and 5MB+ is very unwieldy.
I am planning to modify the whole shebang to use ProtoBuf, but currently I'm not sure as to how I can handle the reference semantics. Any thoughts would be much appreciated
Out of the box, protocol buffers does not have any reference semantics. You would need to cross-reference them manually, typically using an artificial key. Essentially on the DTO layer you would a key to CDataSet (that you simply invent, perhaps just an increasing integer), storing the key instead of the item in m_refData/m_refParent, and running fixup manually during serialization/deserialization. You can also just store the index into the set of CDataSet, but that may make insertion etc more difficult. Up to you; since this is serialization you could argue that you won't insert (etc) outside of initial population and hence the raw index is fine and reliable.
This is, however, a very common scenario - so as an implementation-specific feature I've added optional (opt-in) reference tracking to my implementation (protobuf-net), which essentially automates the above under the covers (so you don't need to change your objects or expose the key outside of the binary stream).
Say if I am parsing readings from a handheld device of some sort via an input stream. There are readings of different types, and each need parsing differently.
Currently I have a class "handheld" that handles all parsing and creates reading objects of the appropriate type as required. It parses the reading and populates each reading via their "set" methods.
I'm wondering though if the readings themselves should know how to parse the input stream. For instance, when the next reading comes along, should I instantiate the appropriate reading object and call a "parse" method on it, passing it in the input stream?
The main thing I don't like about this is the parsing code is all over the place rather than kept neatly in one place. It does however get rid of the need for all those set methods and the reading can just apply itself to the server/database/whatever when required via the "apply" method I have.
So which would be considered the "nicer" (or more OO) way?
I would go by creating a Factory design pattern.
Create a base class to represent GeneralParser and make a child class for each parser and if there was something common in the parsing method, let it be in the base GeneralParser's Parse method and call base.parse method in child.parse method.
I am sure you have a way to determine which parser to use, and I think currently you're using control statements (if, switch...) and do the parsing. Well now instead of that let the specialized (child) parser class handle it for you.
Pseudo class diagram:
GeneralParser
|
|
->XMLParser
->JsonParser
Here is some implementation in C#.Net
public static class ParserFactory
{
public static GeneralParser CreateXMLParser()
{
return new XMLParser();
}
public static GeneralParser CreateJsonParser()
{
return new JSONParser();
}
}
In your program code, you may write something like this (pseudo-code) because it depends on the way that you're deciding which parser to use.
// ...
GeneralParser parser;
if( to_be_parsed_as_xml)
{
parser = ParserFactory.CreateXMLParser();
parser.Parse(stream);
}
else if( to_be_parsed_as_json )
{
parser = ParserFactory.CreateJsonParser();
parser.Parse(stream);
}
// ...
You can create a parser on the fly (without keeping its reference) if you only need parsers to parse and nothing more.