Wednesday, November 5, 2008

Why using workflows

  1. Workflows can handle long running work by persisting to a durable store, such as a database, when idle and loading again once there is work to do.
  2. Workflows are a declarative way of writing programs by linking together pre-defined activities rather than an imperative programming model of writing lines of code.
  3. Workflows allow you to declare business rules that are separated from your code making it easier for you to modify them in the future.
  4. Workflows support different styles of systems with sequential and state machine workflows.
  5. An instance of a workflow can be modified dynamically while running in the event that new conditions require the workflow to behave differently than it did when it was created

Friday, October 24, 2008

Problem- Solution- Pattern Triology

  • Seeking for better raises problems.
  • Problems encourage beautifull minds to find solutions.
  • Solutions may be objects or actions.
  • Objects and actions some times follow patterns, so beatifull minds again encoutaged to discover these patterns.
  • Discovering patterns lead to speed development of other solutions that folow these patterns.
  • But there is no best solution ever so the solution itself can have another problems inside it
  • Applying the solution raise these problems.
  • And we start over again and again

Hints in OOP and design patterns

Abstraction

  • Abstraction is all about breaking your approach to a problem into natural segments. This is where you come up with the objects that divide the problem into manageable parts. In other words, abstracting a problem simply.
  • Abstraction Means thinking of how to tackle that problem in terms of object-oriented code. The data items needed by each object become that object’s properties, whether public or private, and the actions each object needs to perform in the real world become its actions in code.

OOP Principles

  • Objects should represents real life entities.
  • Single responsibility — a class should have only one thing to do.
  • As possible as you can Make your code closed for modification, open for extension.
  • Maintenance should not cost a lot
  • Principle of least know: separate entities (classes of objects) have not to know too much about each other. As much as possible, you should lock away the details inside each class or object and make the coupling between entities as loose as possible If one object needs to know too much about another make their coupling loose (Always go for the loosest coupling you can.).
  • Pure inheritance : inherit every thing

Object relationships

  • Inheritance = "IS A" Relationship
  • Composition = "Has A" Relationship
  • Aggregation = "Has A" Relationship

Design Patterns

  • In problem solving we use the essence of previous problem’s solution to solve the new one (thinking in problem-solution pairs).
    Abstracting from specific problem-solution pairs and distilling out common factors leads to patterns: These problem-solution pairs tend to fall into families of similar problems and solutions with each family exhibiting a pattern in both the problems and the solutions.
    Every pattern deals with a specific, recurring problem in the design or implementation of a software system.
  • Patterns can be used to construct software architectures with specific properties.
  • Design Patterns are solutions for well known programming problems
  • Help making your code closed for modification but open for extension
  • Much of what design patterns are all about has to do with making sure you’re setting up the way you attack the problem correctly. Working with design patterns often means spending more time on the abstraction part of the process than on the concrete classes part.