Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Organizing Actors and Project Libraries

Hi everyone,

 

Just doing some research and I came up with the following doubt.

 

Is there a right or standardized way of organizing actor in project libraries? 

An actor must be alone in its library with its messages? 

Is there performance issues with putting more actors in a library, loading time, etc? I.e. Abstract Actor together with its Concrete Implementations.

 

I tried to find something in the discussion forums, but I end up with more doubts. 

This is an interesting point for me and that may apply for these new interfaces.

 

I would appreciate your opinion on this matter.

 

Regards,

Felipe Pinheiro Silva


Follow my blog for LV content!

0 Kudos
Message 1 of 5
(2,387 Views)

I'm no AF wiz, but I typically put each actor class and its messages in a library alone. Occasionally I'll have free-standing actor classes if they're very light with no messages (for example they sub-class from an API or library). Rarely I'll put multiple actors in the same library, but they'll need to be extremely tightly coupled for me to want this.

 

Another thing I do, which is probably not kosher, is to name almost every single actor "Actor.lvclass". Then I give a useful name to the containing library. For example, MyFeature.lvlib::Actor.lvclass. I do this because it's WAY easier to rename and refactor actors during development. The only drawback I've found so far is when you edit the class inheritance properties. It only shows the file name not the project/namespace name, so you end up with dozens of "Actor.lvclass" to choose from. To me that's a reasonable price for all the other benefits it brings.

0 Kudos
Message 2 of 5
(2,371 Views)

I don't think there is a single right way to organize an AF project.  That said, there are certain things around project libraries I would avoid.

 

For instance, under (almost) no circumstances would I bundle an abstract class (including actors) with any of its children in the same library, as that seriously undermines decoupling.  You create abstract parent classes for the express purpose of decoupling and parameterizing that functionality, and the result is that the caller knows nothing about the implementation you are using today.  But bundling children into a common library with their parents destroys that; it means you pull those children into the project and any executables you may choose to build.  "That's fine" you say, since you know you're going to be using those children.  In today's application.  But tomorrow, you aren't, and you're stuck with them in that project.  And your new co-worker needs to make changes to the child class, so that whole library gets revised, and you have to accept the changes because they're bundled together in a common library.

 

My sole exception is for a set of state pattern actors where the states are predefined and always go together.  That set of actors is much more closely coupled together, and the children are often statically linked to each other.  (State actors are often linked along permitted lines of transition.)

 

Also, there can be performance hits for putting too many things in a library, especially when those things are other libraries - and remember that classes are a form of library.  Everything in the library gets loaded if anything in the library gets loaded.  And if anything links to something in another library, that library gets loaded, too.  And so on, and so on.  You can very quickly bog down load and deployment times in this fashion.

 

Really, since everything in a library loads together, you should limit what goes into a library only to things that must load together.  And if you have to call another class, it's usually better to call an abstract parent class.  That abstract class might be in the same library, but more often will be in its own library or not in a library at all.

 

Robert C Martin has a great discussion of these issues in Agile Software Development, in the section on packages.  Taking the time to read and really understand his thoughts on package management has really helped me avoid a lot of package/library dependency pain.

0 Kudos
Message 3 of 5
(2,305 Views)

@OneOfTheDans  escreveu:

I'm no AF wiz, but I typically put each actor class and its messages in a library alone. Occasionally I'll have free-standing actor classes if they're very light with no messages (for example they sub-class from an API or library). Rarely I'll put multiple actors in the same library, but they'll need to be extremely tightly coupled for me to want this.


Putting every actor in its own library corroborates what Allen said and definitely a practice that I should follow from now on to avoid decoupling.

 


Another thing I do, which is probably not kosher, is to name almost every single actor "Actor.lvclass". Then I give a useful name to the containing library. For example, MyFeature.lvlib::Actor.lvclass. I do this because it's WAY easier to rename and refactor actors during development. The only drawback I've found so far is when you edit the class inheritance properties. It only shows the file name not the project/namespace name, so you end up with dozens of "Actor.lvclass" to choose from. To me that's a reasonable price for all the other benefits it brings.


Never thought of it, but this practice is something that I don't see myself doing.

Felipe Pinheiro Silva


Follow my blog for LV content!

0 Kudos
Message 4 of 5
(2,285 Views)



@justACS  escreveu:

I don't think there is a single right way to organize an AF project.  That said, there are certain things around project libraries I would avoid.

 

For instance, under (almost) no circumstances would I bundle an abstract class (including actors) with any of its children in the same library, as that seriously undermines decoupling.  You create abstract parent classes for the express purpose of decoupling and parameterizing that functionality, and the result is that the caller knows nothing about the implementation you are using today.  But bundling children into a common library with their parents destroys that; it means you pull those children into the project and any executables you may choose to build.  "That's fine" you say, since you know you're going to be using those children.  In today's application.  But tomorrow, you aren't, and you're stuck with them in that project.  And your new co-worker needs to make changes to the child class, so that whole library gets revised, and you have to accept the changes because they're bundled together in a common library.


Good point. That is something I am intending to change in some projects, thinking more about decoupling.

 


Also, there can be performance hits for putting too many things in a library, especially when those things are other libraries - and remember that classes are a form of library.  Everything in the library gets loaded if anything in the library gets loaded.  And if anything links to something in another library, that library gets loaded, too.  And so on, and so on.  You can very quickly bog down load and deployment times in this fashion.


That was always my doubt. What is loaded and what is not. Considering that I must review some codes of mine.

 


Robert C Martin has a great discussion of these issues in Agile Software Development, in the section on packages.  Taking the time to read and really understand his thoughts on package management has really helped me avoid a lot of package/library dependency pain.


Thanks for the tip. Currently, I am reading "The Object-Oriented Thought Process", a very interesting one. I'll try to put this Robert Martin book in the queue.

 

Regards,

Felipe Pinheiro Silva


Follow my blog for LV content!

0 Kudos
Message 5 of 5
(2,282 Views)