I'm working on a poker analysis tool with the following use case:
User create Strategy class with one method: input GameState, output PokerAction
User runs Analysis script, which launches a PokerGame between various Strategy subclasses (i.e. various strategies)
PokerGame generates random deck
PokerGame sends GameState to Strategy
Strategy sends PokerAction to PokerGame
PokerGame updates GameState
When the game is done (managed by PokerGame), send GameResult to Analysis script
User reviews output of Analysis script
There's a third-party library that performs all of the PokerGame functionality. It doesn't match at all with my own modeling of the domain in some areas (e.g. card values, etc.) but performs much of the "hard-to-code" functionality that I need (i.e. the non-trivial steps 4 - 7).
General design question
When faced with a library like this (eliminates a lot of hard coding, but might constrain future design choices in related projects), do you tend to mold the rest of your project to the library? Do you refactor the key library to conform to your domain model? Or is it something else?
Thanks,
Mike
If I really felt my domain model better suited me going forward, I would try to create an abstraction layer to map between the 3rd party library and my own model. This would allow me to take advantage of the library now while providing me with the flexibility to replace it in the future with another 3rd party library or one I created.
Take a look a this list of design patterns, especially the Adapter Pattern.
I would not couple my project tightly to the library, but instead try to abstract functionality and couple both using one or more objects in between. The mediator and/or facade pattern come to my mind here.
Related
I have a lot of automated test cases with Robot Framework and, consequently, I have more and more keywords. It's a bit difficult for me to bring order.
My question is if I can include my keywords in a library. If this is possible, how can I do it?
Thank you.
Marta
This is how you create libraries - Creating test libraries.
However, moving keywords into a library will not bring order to your system. You will only move the disorder to another place.
Keeping your test scripts maintainable deals for the most part in having a certain structure to your work. This applies to Robot Framework as much as it does to any other language.
In Robot Framework we use Resource Files to store keywords that we want to reuse across multiple Test Case files. Thought these links you should be able to learn more on how to do this. You can import Resource Files in a Resource file, so chaining them.
As for what to put in these files that is often a personal preference. However, typically adhering to development principles like DRY, Separation of Concerns and most importantly Common Sense works best.
I'd advise adhering to principles instead of to fixed structure. Separate Data from Process logic, abstract the UI from your Process logic and model your process logic as close to Business Processes as possible.
As for converting keywords to Python Code. If the logic in your resource files means you use a lot of keywords for a specific feature automation, then perhaps this makes sense. But keep in mind that for maintainability you will then be more heavily dependent on the Python skills in your organisation.
I am going to write configuration tool for my Ubuntu based system. Next I would like to write frontends (text, GUI and web). But it is the most complicated project I wanted to write and I am not sure about general architecture I should use.
At the current I have functions and classes for changing system config. But these functions will probably grow & change. #Abki gave me advice how to write interface for frontends. I am going to make base classes for this interface but I don't know how to connect it with backend and next with frontends. Probably I should use design patterns like fasade, wrapper or something else.
It looks like (without interface_to_backend layer):
I don't care about UI and functions to change system config now. But I don't know how to write middle layer so It would be easy to connect it with the rest and extend functionality i the future.
I need general ideas, design patterns, advices how to implement this in Python.
I'm not sure this is entirely appropriate for SO but I'm intrigued and so I'll bite. As a rubyist I can't help much with the Python but here is some opinion on pattens from my experience.
My initial suggestion is you should review a few of the contenders out there. Specifically I'd be looking at cfengine, chef and bcfg2. They each tell a different story but if I'd summarise I'd say:
Chef has a lovely dsl syntax but is let down by a complicated architecture
bcfg2 is written in python but seems to have an annoying tendency to use XML :(
cfengine has the strongest theoretical underpinnings in promise theory (which is v.interesting BTW) but is C based.
Wikipedia also provides a pretty impressive list of configuration management tools that you will find useful.
In regard to designing your own tool I'd suggest there are three principles you want to pursue:
Simplicity, the simpler you make this the better. Simple in terms of scope, configuration and use are all important.
You'll need a single way to store data, you need to be able to trace the choices as they are made and not trample other people's changes (especially in a team environment).
Security, most configuration management tools need root privileges at some point. So you need to make sure that users can trust the code they're running.
You could use Fabric with Python as described in the article Ubuntu Server Setup with Python Fabric
The Wikipedia article at Comparison of open source configuration management software has several other tools that use Python to do this.
I like the approach taken by SALT.
If you write the GUI, text/CLI, and Web interfaces using Python, they can all use the same Python module. That way a change in one interface transparently affects the others. Plus all of those are in Python's area of strength.
I'm planning to do an Desktop application using Python, to learn some Desktop concepts. I'm going to use GTK or Qt, I still haven't decided which one.
Fact is: I would like to create an application with the possibility to be called from command line, AND using a GUI. So it would be useful for cmd fans, and GUI users as well.
It would be interesting to create a web interface too in the future, so it could be run in a server somewhere using an html interface created with a template language.
I'm thinking about two approaches:
- Creating a "model" (core module, where all the functionality resides) with a simple interface which is called from a desktop/web implementation;
- Creating a "model" with an html interface, and embeb a browser component so I could reuse all the code in both desktop/web scenarios.
My question is: which exactly concepts are involved in this project? What advantages/disadvantages each approach has? Are they possible?
By naming "interface", I'm planning to just do some interfaces.py files with def calls. Is this a bad approach?
I would like to know some book recommendations, or resources to both options - or source code from projects which share the same GUI/cmd/web goals I'm after.
Thanks in advance!
What about a link to the source?
Having a CLI command and a GUI front-end is really common on unix platforms... The TransmissionBT bit torrent client is a good example of what you plan to do.
Decoupling the presentation layer from application logic makes it possible!.
You can divide your application into layers, a layer is a reusable portion of code that performs a specific function.
For example, you can divide the application into two or more layers, one layer with the presentation of the application and the other with the model. This allows reuse of the entire model of the application with different implementations of the presentation layer.
The presentation layer contains the components that implement and display the user interface and manage user interaction. This layer includes controls for user input and display, in addition to components that organize user interaction. Can have multiple implementations of the presentation layer technologies such as PyQt4, PyGtk, Html, console, etc.
Why Separating Model Is Useful?
You may wonder why it is important to move as much logic outside the presentation layer and into the model layer. The biggest reason is reuse: logic placed in a model increases the reusability of an application. As applications grow, applications often grow into other realms. Applications may start out as a web application, but some of the functionality may later be moved to a smart client application. Portions of an application may be split between a web site and a web or windows service that runs on a server. In addition, keeping logic helps aid in developing a good design (sometimes code can get sloppier in the UI).
However, there are some caveats to this: it takes a little longer to develop applications when most of the logic resides in the business layer. The reason is this often involves creating several sets of objects (data layer and access code, plus business objects) rather than embedding it in the application. The extra time that it takes to do this can be a turnoff for some managers and project leads, especially because it often requires you to be knowledgeable about object-oriented programming, more than most people are comfortable with.
You can search about N-Layered architectural style on the Internet.
This is a sample application that implements several types of user interfaces, but based on. NET framework, for python is similar.
http://microsoftnlayerapp.codeplex.com/
I am working on a big project based on PyQt4 presentation framework. one of the styles of architecture applied is N-Layers. If you want a simple example based on PyQt4, send me a email.
I have some algorithms to do that are very similar in very aspects but are all different.
I'll try to give an example of what I mean.
Let's assume I have a Robot class. This class should be the "base" of all classes. It provides basic mechanisms to make the robot work in its environment. It might or not have to work by itself (with this I mean it can either be an abstract class, that is useless by itself, or if possible, to have basics mechanisms to be ready to work).
All robots have hands. But some robots will have human-like hands, other will have blades, other will have razors. I could do a base class called RobotBase and then create RobotHumandHand, RobotBladeHand and RobotRazorHand. But they also can have different heads, different eyes, different legs, different arms, etc. Is there any easy way I can address this? I'd like to put this in a way that is a bit like LEGO, so I could just define a robot and "add" the pieces I want. Maybe through interfaces? I am not even aware if those exist in python(that's the language I'll be using).
Any comments / suggestions are really appreciated! Thanks!
The design patterns I'd probably go with for such a problem are: Dependency Injection and a framework to go with it, the Composite pattern, and the Builder pattern. They should basically let you separate the creation of your Robots from their use.
I think your robot should have a list of ports i.e. a number of injected components each robot may have. Your Robot class will be a container of RobotParts. You can have specific parts to have specific interfaces. RobotHand extends RobotPart and Robot class has a field that holds a list of RobotHand implementations (you can limit it to 2 hands, but in general case there could be more). You can do the same with RobotHead that will inherit from RobotPart and also there will be a field in Robot class holding implementation of RobotHead. In its turn RobotHead may hold a list of RobotEye implementations and so on. Then your specific Robot implementations may inherit their behavior from base class or take advantage of configuration e.g. by using RobotBladeHands if available.
I'm not a Python guy, but a quick look indicates they support multiple inheritance which can be used like Java Interfaces (Python does not seem to support interfaces). So you can have essentially superclasses for RobotHand then RobotHumanHand, RobotBladeHand, etc, Same with eyes, feet what have you. This is a reasonable way to do what you want to do.
If you are seeking for a design pattern, then I suggest you strategy pattern.Because Implementing this pattern you can dynamically interchange the components of robot.
There comes a point where, in a relatively large sized project, one need to think about splitting the functionality into various functions, and then various modules, and then various packages. Sometimes across different source distributions (eg: extracting a common utility, such as optparser, into a separate project).
The question - how does one decide the parts to put in the same module, and the parts to put in a separate module? Same question for packages.
There's a classic paper by David Parnas called "On the criteria to be used in decomposing systems into modules". It's a classic (and has a certain age, so can be a little outdated).
Maybe you can start from there, a PDF is available here
http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf
Take out a pen and piece of paper. Try to draw how your software interacts on a high level. Draw the different layers of the software etc. Group items by functionality and purpose, maybe even by what sort of technology they use. If your software has multiple abstraction layers, I would say to group them by that. On a high level, the elements of a specific layer all share the same general purpose. Now that you have your software in layers, you can divide these layers into different projects based on specific functionality or specialization.
As for a certain stage that you reach in which you should do this? I'd say when you have multiple people working on the code base or if you want to keep your project as modular as possible. Hopefully your code is modular enough to do this with. If you are unable to break apart your software on a high level, then your software is probably spaghetti code and you should look at refactoring it.
Hopefully that will give you something to work with.
See How many Python classes should I put in one file?
Sketch your overall set of class definitions.
Partition these class definitions into "modules".
Implement and test the modules separately from each other.
Knit the modules together to create your final application.
Note. It's almost impossible to decompose a working application that evolved organically. So don't do that.
Decompose your design early and often. Build separate modules. Integrate to build an application.
IMHO this should probably one of the things you do earlier in the development process. I have never worked on a large-scale project, but it would make sense that you make a roadmap of what's going to be done and where. (Not trying to rib you for asking about it like you made a mistake :D )
Modules are generally grouped somehow, by purpose or functionality. You could try each implementation of an interface, or other connections.
I sympathize with you. You are suffering from self-doubt. Don't worry. If you can speak any language, including your mother tongue, you are qualified to do modularization on your own. For evidence, you may read "The Language Instinct," or "The Math Instinct."
Look around, but not too much. You can learn a lot from them, but you can learn many bad things from them too.
Some projects/framework get a lot fo hype. Yet, some of their groupings of functionality, even names given to modules are misleading. They don't "reveal intention" of the programmers. They fail the "high cohesiveness" test.
Books are no better. Please apply 80/20 rule in your book selection. Even a good, very complete, well-researched book like Capers Jones' 2010 "Software Engineering Best Practices" is clueless. It says 10-man Agile/XP team would take 12 years to do Windows Vista or 25 years to do an ERP package! It says there is no method till 2009 for segmentation, its term for modularization. I don't think it will help you.
My point is: You must pick your model/reference/source of examples very carefully. Don't over-estimate famous names and under-estimate yourself.
Here is my help, proven in my experience.
It is a lot like deciding what attributes go to which DB table, what properties/methods go to which class/object etc? On a deeper level, it is a lot like arranging furniture at home, or books in a shelf. You have done such things already. Software is the same, no big deal!
Worry about "cohesion" first. e.g. Books (Leo Tolstoy, James Joyce, DE Lawrence) is choesive .(HTML, CSS, John Keats. jQuery, tinymce) is not. And there are many ways to arrange things. Even taxonomists are still in serious feuds over this.
Then worry about "coupling." Be "shy". "Don't talk to strangers." Don't be over-friendly. Try to make your package/DB table/class/object/module/bookshelf as self-contained, as independent as possible. Joel has talked about his admiration for the Excel team that abhor all external dependencies and that even built their own compiler.
Actually it varies for each project you create but here is an example:
core package contains modules that are your project cant live without. this may contain the main functionality of your application.
ui package contains modules that deals with the user interface. that is if you split the UI from your console.
This is just an example. and it would really you that would be deciding which and what to go where.