Our clients get to choose when to upgrade. So, my team literally has to maintain and support dozens of versions of our software product. As you can imagine that results in a lot of branching and merging as hot fixes and service packs have to be propagated across all these flavors. I'm not happy with the situation. The obvious solution is simply not to maintain so many different versions of our product, but that obvious solution is not available to me. So, I'm exploring creative options to lower the team's maintenance work. I'm considering using a mix of Feature Toggling and IoC as a way to implement n-number of versions of our software product. The idea is that I could use a single code base for my product and manage behaviors and features via configuration management. This would be in lieu of having to propagate code across multiple branches. Is this a reasonable approach or am I just trading off one problem for another?
That sounds reasonable, in that this would be the way I'd address such a problem in a greenfield environment.
Let's not call it a Feature Toggle, though. As the name implies, a Feature Toggle is an on/off switch, which may not be what you need.
Sometimes, an upgrade also involves changed behaviour in existing features. That implies that you're probably going to need something more sophisticated than an on/off switch.
The Strategy pattern is a more flexible way of modelling variation in behaviour. Each Strategy can represent a particular version of a particular behaviour, and if you don't want the behaviour at all, you can provide a Null Object implementation. In other words, Feature Toggle can be implemented with a Strategy.
You can inject the Strategies into your application kernel using Dependency Injection, and you could make the choice of Strategies configurable via a configuration system. Most DI Containers I've heard about (on .NET and Java) support file-based configuration.
This essentially describes an add-in architecture.
Now, even for a greenfield application, this is no easy feat to pull off. If you have a headless system, it's not that hard, but once you have UI involved, you start to realise that you're going to need to componentise the UI architecture as well, so that you can plug in UI elements via Strategies.
On a decade-old code base, this would be what I'd call an 'interesting challenge', to say the least.
Related
In web development there is a lot of focus on REST-style architectures, with the objectives of minimizing (or eliminating) state. The web frameworks that I have seen all emphasize this style (Django, Rails, flask, etc.).
While I agree that this is a good fit for the web in general, there are also many cases where this is inadequate. In particular I am thinking of the case where you want the user to follow a process, i.e. you want to offer a number of steps and these steps should be completed in a certain order (possibly with optional steps, deviating paths, etc.)
A good example of this might be a shopping cart: First you have to make your selection, then enter your address, choose shipment type, enter your payment details, finish. You don't want the user to skip any of these steps and the process can become a lot more complex. Ideally I would want this process to be defined in a separate place to separate this logic from the rest of the implementation.
Now my questions:
Are finite state machines the way to go here? Do they still work well if these processes become complex and need to change a lot (e.g. this step should go here, this step should go into this process instead, etc)?
What options are offered by/for web frameworks (not any in particular I am interested in the best solutions)?
What are interesting / good examples of where such processes occur? Shopping carts are an obvious example but I am sure there are lots more.
Yes, they are. Using state machines (workflows) is an appropriate solution for the problem you described. If designed well it can make your code more cleaner, remove mess from the code. Logic of each state and transition logic are incapsulated within a State class object so the code looks cleaner and more maintainable . Implementations may vary (say, the place you keep your transition logic - within state or create a separate transition manager) and don't match canonical description of state machine in discrete math so you'd better try what works for you better.
For Ruby you can check workflow: https://github.com/geekq/workflow or stonepath: https://github.com/bokmann/stonepath. State machine pattern is also can be found in javascript frameworks (SpoutCore). It's not difficult to implement your own small state machine engine.
Interesting examples? Lots of them. Processing orders, banking operations, games. I used state machine when created behaviour correction module which includes phychological tests, games, video. The transitions from state to state depended there on if tests are answered correctly, if game played successfully etc.
PS. I used the terms of state machine and workflow as synonyms but they are not the same; it was discussed here: http://jmettraux.wordpress.com/2009/07/03/state-machine-workflow-engine/ . You can also find some Ruby code and links there.
I've seen it in the context of classes. I suspect it means that the class could use being broken down into logical subunits, but I can't find a good definition. Could you give some examples?
Thanks for the help.
Edit: I love the smart replies, but I'm obviously referring to "monolithic" within a software context. I know about monoliths, megaliths, dolmens, and all the stone-related contexts. Gee, I have enough of them in my country...
Interesting question. I don't think there are any formal definitions of what a monolithic class is, but you've got the idea. A class that contains multiple components that are logically unconnected, or pointlessly coupled, is a monolithic class.
If you've read The Pragmatic Programmer, which I strongly recommend, you can define a monolithic class as an anti-pattern that goes against almost everything from that book.
As for examples, you'll find more in the realm of chip and OS design, where there are formal definitions of monolithic chips/kernels, which are similar to a monolithic class. Here are some examples, although each of them can be argued against being on this list:
JOGL - Java bindings for OpenGL. This could be arguable, and with good reason.
Most academic projects - For obvious reasons.
If you started programming alone, rather than joining a team, then chances are you can open one of your first projects, and there will be a class that is monolithic.
If you look up the etymology of the word you'll see it comes from the Greek monos (single) and lithos (stone). In the context of software as you mention it, it describes a single-tiered application in which the code for the user interface and the data access are combined into a single program from a single platform.
"Monolithic" is a term that has been used to flame succesful software. This link exposes the assumptions inherent in the term, and their limited usefulness.
The basic assumption is that a system works better if it is built from software components that each have an individual, well-defined task. Intuitively, this seems right. If each component works, the entire system must work, right?
In reality, it's not that easy. A larger, compositional (non-monolithic) system can miss a critical function, even when there is no single component to blame. This happens when the architectural design fails to allocate a function to any specific component. This can happen especially if it's a function which doesn't map cleanly to a single component.
Now Linux (to continue with the linked example) in reality is not monolithic. It has a modular userspace on top of a monolithic kernel, a userspace that comes with many separate utilities. Except when it doesn't.
My definition of a Monolithic design in software development, is a design which requires additional functionality to be added to a single indivisible block of code.
PRO:
Everything is in one place, and therefore easy to find
Can be simpler, given there less relations to consider (can also be more complex see cons)
CONS:
Over time as functionality is added the complexity of the system may exponentially increase, to the point new features are extremely hard or impossible to implement
Can make it difficult for multiple developers to work with e.g Entity Framework EDMX files have the entire database in a single file which can be extremely difficult for multiple developers to work on.
Reduced re-usability, by definition it does not have smaller components which can be then reused and re-purposed to solve other problems, unless a complete copy of the code is made and then modified.
A monolithic architecture is a model of software structure which is created as one piece where all Rails tools (ActionMailer, ActiveJob, ActionCable, etc.) can be gathered together with the code that these tools applies. The tools are not connected with each other but they are also not autonomous.
If one feature needs changes, it will influence the work of the whole process and other features because they are parts of one process.
Let’s recall what Ruby on Rails is, what it can offer, its pros and cons. Its most important benefit is that it is easy to work with.
If you write rails new you immediately get a new application at once, then you can create any REST API you want and use Rails helpers and generators, which makes development even easier.
If you need to send emails in your Rails app, then use Rails ActionMailer. When you need to do some hard processing, ActiveJob will help you. With Rails 5 you will also be able to use websockets out of the box. Thus, it will be easy to create chats or make your application more interactive.
In case you use correct DSL syntax, you can use all that and even more immediately. Moreover, you don’t have to know everything about the internal implementation of these tools, consider it’s DSL, and receive the expected result.
It means something is the opposite of modular. A modular application can have parts, referred to as modules, replaced without requiring replacement of the entire application. Whereas a monolithic application, after having a part fixed or upgraded, must be replaced in it's entirety.
From Wikipedia: "Modularity is desirable, in general, as it supports reuse of parts of the application logic and also facilitates maintenance by allowing repair or replacement of parts of the application without requiring wholesale replacement."
So in the context of a monolithic class, all its features are self-contained and if you want to add or alter a feature to the class you would need to alter/add code in the class and recompile it. Conversely a modular class exposes access to functionality which is implemented externally. For example a "Calculator" class may use a separate "Add" class for actually adding numbers; call a "Multiply" function from a separate library; or even call an "Amortize" function from a web service. As long as the each of these functional parts can be altered externally from the class, it is modular.
My company needs to rewrite a large monolithic program, and I would want it written using a plugin type architecture. Currently the best solution appears to be MEF, but as it is a fairly 'new' thing I am warey of betting the future of my company (and my reputation) on it.
Does anyone have a feeling on how mature a solution MEF is ?
Thanks
Visual Studio's entire extension system is now built on MEF.
That is to say that Microsoft is Dog-fooding it (like they are doing with WPF).
Given that the framework developers themselves will be working with it, you can feel pretty confident that it is here to stay. However, as with any first release, you are almost guaranteed to have some growing pains when the next release comes around.
Personally, I would go for it. It is certainly better than the tightly-coupled-reflection-based alternative.
I don't think it is necessary to "bet on MEF". Your code should have very little dependencies on MEF.
You can use the technique of dependency injection to break up your monolithic application into components which have only a single responsibility, and which limit their knowledge of other components to abstractions. See this blog post by Nicholas Blumhardt for a nice overview of the type of relations that can exist between components.
Wiring the components together into an application can then be done with any dependency injection framework, or even manually. The component logic shouldn't need to be aware of the container - there might not even be a container.
In the case of MEF, you do need to add import/export attributes to your classes. However, you can still ignore those attributes and reuse those components without MEF, e.g. by using another DI framework like AutoFac.
It's a relatively new technology, so I'm not sure if it's exactly mature. I'm sure it will change quite a bit over the next several years, perhaps merging with other frameworks to better support IoC. That said, MS has a pretty good history of preserving backwards compatibility, so now that MEF is actually part of the Framework, I would consider the public interfaces stable.
That said, MEF might not actually be the right solution for your project. It depends on your extensibility needs and how large is 'large'. If you want to support true extensibility, including the possibility for third-party plugins, it has an enormous impact on your design responsibilities. It's much harder to make changes to the infrastructure as you now need to maintain very stable public interfaces. If you're really only after the IoC features, you're probably better off with a true IoC framework, which more clearly limits your design responsibility to support of your internal dependencies. If you're betting the future of the company, this is the bigger question, in my mind.
Looking at Microsoft's Managed Extensibility Framework (MEF) and various IoC containers (such as Unity), I am failing to see when to use one type of solution over the other. More specifically, it seems like MEF handles most IoC type patterns and that an IoC container like Unity would not be as necessary.
Ideally, I would like to see a good use case where an IoC container would be used instead of, or in addition to, MEF.
When boiled down, the main difference is that IoC containers are generally most useful with static dependencies (known at compile-time), and MEF is generally most useful with dynamic dependencies (known only at run-time).
As such, they are both composition engines, but the emphasis is very different for each pattern. Design decisions thus vary wildly, as MEF is optimized around discovery of unknown parts, rather than registrations of known parts.
Think about it this way: if you are developing your entire application, an IoC container is probably best. If you are writing for extensibility, such that 3rd-party developers will be extending your system, MEF is probably best.
Also, the article in #Pavel Nikolov's answer provides some great direction (it is written by Glenn Block, MEF's program manager).
I've been using MEF for a while and the key factor for when we use it instead of IOC products is that we regularly have 3-5 implementations of a given interface sitting in our plugins directory at a given time. Which one of those implementations should be used is actually something that can only be decided at runtime.
MEF is good at letting you do just that. Typically, IOC is geared toward making sure you could swap out, for a cononical example, an IUserRepository based on ORM Product 1 for ORM Product 2 at some point in the future. However, most IOC solutions assume that there will only be one IUserRepository in effect at a given time.
If, however, you need to choose one based on the input data for a given page request, IOC containers are typically at a loss.
As an example, we do our permission checking and our validation via MEF plugins for a big web app I've been working on for a while. Using MEF, we can look at when the record's CreatedOn date and go digging for the validation plugin that was actually in effect when the record was created and run the record BOTH through that plugin AND the validator that's currently in effect and compare the record's validity over time.
This kind of power also lets us define fallthrough overrides for plugins. The apps I'm working on are actually the same codebase deployed for 30+ implementations. So, we've typically go looking for plugins by asking for:
An interface implementation that is specific to the current site and the specific record type in question.
An interface implementation that is specific to the current site, but works with any kind of record.
An interface that works for any site and any record.
That lets us bundle a set of default plugins that will kick in, but only if that specific implementation doesn't override it with customer specific rules.
IOC is a great technology, but really seems to be more about making it easy to code to interfaces instead of concrete implementations. However, swapping those implementations out is more of a project shift kind of event in IOC. In MEF, you take the flexibility of interfaces and concrete implementations and make it a runtime decision between many available options.
I am apologizing for being off-topic. I simply wanted to say that there are 2 flaws that render MEF an unnecessary complication:
it is attribute based which doesn't do any good to helping you figuring out why things work as they do. There's no way to get to the details burred in the internals of the framework to see what exactly is going on there. There is no way to get a tracing log or hook up to the resolving mechanisms and handle unresolved situations manually
it doesn't have any troubleshooting mechanism to figure out the reasons for why some parts get rejected. Despite pointing at a failing part it doesn't tell you why that part has failed.
So I am very disappointed with it. I spent too much time fighting windmills trying to bootstrap a few classes instead of working on the real problems. I convinced there is nothing better than the old-school dependency injection technique when you have full control over what is created, when, and can trace anything in the VS debugger. I wish somebody who advocates MEF presented a bunch of good reasons as to why would I choose it over plain DI.
I agree that MEF can be a fully capable IoC framework. In fact I'm writing an application right now based on using MEF for both extensibility and IoC. I took the generic parts of it and made it into a "framework" and open sourced it as its own framework called SoapBox Core in case people want to see how it works.
In particular, take a look at how the Host works if you want to see MEF in action.
Anyone who develops knows that code is a living thing, so how do you go about defining a "complete" interface when considerable functionality may not have been recognised before the interface is published?
Test it a lot. I've never encountered a panacea for this particular problem - there are different strategies depending on the particular needs of the consumers and the goals of the project - for example, are you Microsoft shipping the ASP.NET MVC framework, or are you building an internal LoB application? But distilled to its simplest, you can never go wrong by testing.
By testing, I mean using the interface to implement functionality. You are testing the contract to see if it can fulfill the needs. Come up with as many different possible uses for the interface you can think of, and implement them as far as you can go. Whiteboard the rest, and it should become clear what's missing. I'd say for a given "missing member", if you don't hit it within 3-5 iterations, you probably won't need it.
Version Numbers.
Define a "Complete Interface". Call it version 1.0.
Fix the problems. Call it version 2.0.
They're separate. They overlap in functionality, but they're separate.
Yes, you increase the effort to support both. That is, until you deprecate 1.0, and -- eventually -- stop support.
Just make you best reasonable guess of the future, and if you will need more create second version of your interface.
You cannot do it in a one-shot release. You need feedback.
What you can do is first make a clean interface that provide all the functionalities your library should provide; then expose it to your user base for real-world usage; then use the feedbacks as guide to update your interface -without adding features other than helper function/classes- until it starts to be stable on the interface.
You cannot rely only on experience/good-practice. It really helps but it's never enough. You simply need feedback.
Make sure the interface, or the interface technology (such as RPC, COM, CORBA, etc), has a well-defined mechanism for upgrades and enhanced interfaces.
For example, Microsoft frequently has MyInterface, followed by MyInterfaceEx, followed by MyInterfaceEx2, etc, etc.
Other systems have a means to query and negotiate for different versions of the interface (see DirectX, for one).