mardi 1 septembre 2015

Design issue in wrapping "C" API into OO wrapper

I am trying to build an object oriented wrapper, which will wrap API specification; this includes a many structures, events, and APIs. This API specification will be revised every year, there by releasing new specification; the updates are likely to have newer structures, events and APIs. Updates will also include Updates to existing structures, events and APIs, the APIs as such does not change but as they take various structures as parameters which eventually have updates

The challenges

  1. The API specification is nothing but an SDK to a lower layer, what I am trying to build is also an SDK but will be an object orient wrapper over this SDK.
  2. The requirement is that the users want Objects and methods and no “C” like structures and APIs
  3. The frequent version change should not have any impact on high level application and should seamlessly work with any underlying API version
  4. Older application should work on newer APIs
  5. Newer application should work on older APIs

The last one is a tricky one, what I mean is that the newer application when it sees that it an older version of SDK should somehow transform itself to an older version of API

Is there any design pattern which will help me achieve this task and tied over the frequent changes to internal data and also achieve backward compatibility and forward compatibility?

OS: Windows Dev Environment : Visual C++

Designing user permissions mechanism

I have a few types of users who works with the app that helps to optimize processes for public libraries: Client, Librarian, Administrator.

Librarian has restricted access to data in comparison to Administrator. For example Librarian cannot view the Clients from the other library or the other department within the same library. So that I need to develop permissions logic.

I ask for advice on what are the best practices of designing permissions mechanisms? What should be done on database level? What should be done on business logic level?

Reduce constructor arguments whilst keeping service usage explicit?

I am using C#, but my question applies to any OOP language.

I have many different objects that consume a range of services. I would like the way these services are accessed to satisfy a few constraints, but I am struggling to figure out a good design.

  • I would like the usage of these services to be explicit
  • An object should never be in an invalid state (services should be passed on construction)
  • Service usage should be clear
  • Code repetition should be minimal

I think these are all good aims, but they are proving difficult to achieve in practice. My current approach is a sort of dependency-injection-by-hand:

class MyObject(IFooService fooService, IBarService barService)
{
    this.fooService = fooService;
    this.barService = barService;
}

So far so good. But what happens when I have lots of service dependencies? I have dozens of objects, some of which need to access many services.

I considered building a "service container" object and passing that in:

class Services(IFooService fooService, IBarService barService)
{
    this.fooService = fooService;
    this.barService = barService;
}

class MyObject(Services services)
{
    this.services = services;
}

However, this obscures the services that an object actually uses. Given the constructor, MyObject might use any of the them!

  • What are some common approaches to avoiding this problem?
  • Is my problem indicative of a more fundamental design issue?
  • Is this really a problem at all? Should I relax some of my design goals?

Best way to implement software by task using only Java standard API

I have task to implement software using java standart API:

The task is about Decathlon competition. The input of the Java program is a CSV-like text file (see the attachment). The task is to output an XML file with all athletes in ascending order of their places, containing all the input data plus total score and the place in the competition (in case of equal scores, athletes must share the places, e.g. 3-4 and 3-4 instead of 3 and 4). Input and output file names should be provided as parameters to the Java application at the startup. It would be great if an XSL file for viewing the produced XML nicely using a web browser is also provided. Be sure to keep the code design simple, but allowing to easily change or add more input sources and/or output file formats. Unit tests for the code are mandatory. No external libraries are allowed in addition to the Java standard API except JUnit. Keep in mind that we are going to run both your program and the tests. Try to keep your code as readable as possible. We value code simplicity. Use object-oriented approach with design patterns where applicable.

Firstly, what classes recommend to use for upload csv file, and output xml?

Maybe recommend about classes structure? interfaces? and what designs patterns I can use to do this task elegant?

And not very clear for me what I should to do to complete this part of task:

It would be great if an XSL file for viewing the produced XML nicely using a web browser is also provided.

ExpressionTree Composite vs Classic Composite pattern

I am using Composite Specification from NCommon http://ift.tt/1hRfsMt

I was excited initially from its implementation using ExpressionTrees but then I asked myself if there are any benefits of the added complexity of using ExpressionTrees? I can't think of any. Can you please tell me if this worth of using or it is just over engineered?

How to automate factory design pattern in swift?

I want to automate this piece of code:

    let objectType = json["object"]["type"].stringValue;

    switch objectType {
        case "Message":
            activity.item = MessageLib.make(json["object"]) as! MessageItem;
        default:
        ()
    }

I want to make an object based on its type. But I don't want to write a new case for each new ObjectType. I just want to make a new object class. OBJECTTYPEItem

Parse and share obj resources in module

I wanted to know if its good practice to use it like following since I used a global field cacheObj I need to parse the data and share it between other modules,any module can take any property but only the first module which called to this parser is responsible to provide the data to parse(I need to do this parse just once and share properties in different modules)

This code is from other SO post and I want to use it

var Parser = require('myParser'),
    _ = require('lodash');

var cacheObj; // <-- singleton, will hold value and will not be reinitialized on myParser function call

function myParser(data) {
    if (!(this instanceof myParser)) return new myParser(data);
    if (!_.isEmpty(cacheObj)) { 
        this.parsedData = cacheObj; 
    } else {
        this.parsedData = Parser.parse(data);
        cacheObj = this.parsedData; 
    }
}

myParser.prototype = {
    //remove `this.cacheObj`
    getPropOne: function () {
        return this.parsedData.propOne;
    },

    getPropTwo: function () {
        return this.parsedData.propTwo;
    }
};

module.exports = myParser;