What's the difference between an Adapter and a Converter? Are all converters Adapters?
(In terms of design patterns)
No, I wouldn't consider them the same thing. An adapter is something that generally adapts one interface for another. For example, I might create an adapter interface for my application to send an email. One adapter would do all the work involved in interfacing with SMTP, another adapter might do all the work involved in interfacing with Exchange. The the code using either of the adapters, they would be used in the same way (maybe both implementing the same interface). The adapters adapt one interface for another. The idea is that I could swap them out as needed.
A converter is something that changes one or more values to one or more different values. e.g. I may need to convert Unicode text into ASCII text. That's not adapting an interface so that something else that expects a different interface can use it, that's converting values so that the single interface that expected ASCII text can be used.
Now, an adapter might need to do some conversion in order to adapt an interface; but that's not always the case.
Related
Communication in AUTOSAR can take two major paths : com and ldcom. I understand that ldcom is more efficient version of com (By removing most COM features). But are there any general rules/Criterion that can help decide to stick with one of them?
If you are reimplementing all the features of Com within your SWC(s), then you are definitely using LdCom for the wrong reasons.
And if your SWCs now depend also too much on the definition of the network (e.g. you have to change your SWC always as soon as the network description changes), then you also using LdCom for the wrong reasons.
Its been a while since Ive had to write what amounts to a custom format edi processor. The last time I wrote one, I was an AS/400 programmer (not iSeries to give you a timeframe). It was pretty easy, I built a structure and inspected the record type column and began processing based on the fix positions of data and record type.
Fast forward to 2012 and I have almost exactly the same requirements except I no longer have an AS/400 to make it easy.
For brevity, the first 2 columns contain a record type and the structure is based on that type. Any suggestion on how to best handle this in c# on a web server?
Some options I have considered are filehelpers and SSIS. I have full control over the environment so I can do pretty much anything that makes sense.
You can try using the Multi Record engine option of FileHelpers
http://www.filehelpers.com/example_multirecords.html
You must define as many record classes as different kind of lines you have and later provide a delegate that lets FileHelpers choose the right one.
There is also a Master Detail engine:
http://www.filehelpers.com/example_masterdetail.html
Last version of the library: http://teamcity.codebetter.com/viewLog.html?buildId=51642&tab=artifacts&buildTypeId=bt66
We have a project full of custom components that today is working in Lazarus and Delphi.
I'm thinking in code interfaces on it, but I am not much familiar with them. What I would like to know is: What are the implementation nuances from Delphi and Lazarus interfaces? There is something that I should be specially aware? Will I have to code really different things?
Background explanation:
I think the components could benefit from interfaces, or at least, I will learn more from them. For example, one of the components make communication to many different hardwares using serial port. But user should use only our component to create the application. So we have the component and one class to each of this hardware that descendant from a base class. At run-time we create the specific class inside the component.
Not sure this last explanation was needed, but I can write more if any of you need it.
In Free Pascal, the interface type depends on mode. Basically there is mode COM or CORBA . COM is default and roughly compatible with Delphi. CORBA is a more simpler case without the reference counting. (and thus also not generating calls to refcounting functions). So basically a FPC Corba interface is like the hypothetical ancestor of the IUnknown interface.
Besides this, there are sometimes some differences wrt when interfaces are released. Delphi tends to save decreasing the refcount at for the end of the procedure or block (in larger procedures), while FPC sometimes is known to release them sooner, typically immediately after the statement of last use. Both are legal implementation choices btw, base on which scope is used for temporary variables. (only on the function level, or also in deeper nested blocks)
However this sometimes reveals hidden (bad) assumptions in code, specially when using interface references and object references within one procedure that might "survive" in Delphi, but not in FPC. It is a typical case that shows that long-time working code is not necessarily correct. One might only notice hidden assumptions when changing implementation
(added later:) note that you can use COM style on *nix. It mainly is the insertion of calls to reference counting routines that set the two interface types apart. Not what system (COM, Corba or simply in RTL reference counting) those calls are routed to.
Note that I think the COM vs Corba names for both interface types were badly chosen. Corba interfaces are refcounted actually, but traditionally this refcount is manually handled, because Java does not support externally handled interfaces in an automated manner.
Added 2021-11-06: It seems that Delphi Alexandria now follows suit
I don't quite get type providers after watching Don Symes's pdc video
http://player.microsoftpdc.com/Session/04092962-4ed1-42c6-be07-203d42115274
Do I understand this correctly. You can get ready made type providers for Twitter, Excel...
What if I have a custom Xml structure, do I need to implement my own type provider for that and how is this different from creating my own custom mapper?
Say you have some arbitrary data entity out in the world. For this example, let's say it's a spreadsheet.
Let's also say you have some way to get/infer schema/metadata for that data - that is, you can know types (e.g. double versus string) and relationships (e.g. this column means 'salary') and metadata (e.g. this sheet is for the June 2009 budget).
Type providers lets you code up a kind of 'shim library' that knows about some kind of data entity (e.g. a spreadsheet) and use that library as part of the compiler/IDE toolchain so that you can write code like
mySpreadsheet.ByRowAndColumn.C4
or something, and get Intellisense (autocompletion) and tooltips (e.g. describing cell C4 as Salary for Bob) and static typing (e.g. have it be a double or a string or whatever it is). Essentially this gives you the tooling affordances of statically-typed object models with the ease-of-use leverage of various dynamic or code-generation systems, with some improvements on both. The 'cost' is that someone has to write the shim library (the 'type provider'), but many such providers are very general (e.g. one that speaks OData or Excel or WMI or whatnot) and so a small handful of type provider libraries makes vast quantities of the world's data available in your programming language with static typing and first-class tooling support.
The architecture is an open compiler, where provider-authors implement a small interface that allows them to inject new names/types into the programming context. A type provider might be just another library you pass to the compiler (a reference in your project, -r-ed), with extra metadata that marks it as a type provider that participates in the compilation/IDE/codegen portions of development.
I don't know exactly what a "custom mapper" is in your xml example to draw a comparison.
I understand that this is an old question, but now Type providers are available (as F# 3.0 got released). There is a white paper explaining it too. And we have a code drop from Microsoft that can let you see under the hood.
http://www.infoq.com/news/2012/09/fsharp-type-providers
Type providers use F#'s quotations to act as (effectively) compiler plugins that can generate code based on meta-data at compile time.
This allows you to (for example) read in some JSON, or a data base schema, or some XSD or whatever and then generate F# classes to model the domain that meta-data represents.
In terms of creating them, I wrote a few blog posts that might be of interest starting with Type Providers from the Ground Up.
We’re rewriting a calculation core from scratch in Delphi, and we’re looking for ways to let other people write code against it.
Automation seems a fairly safe way to get this done. One use we’re thinking of is making it available to VBA/Office, and also generating a .NET assembly (based on the Automation object, that's easy).
But the code should still be easy to use from Delphi, since we’ll be writing our (desktop) UI with that.
Now I’ve been looking into creating an Automation server in Delphi, and it looks like quite a hassle to have to design the components in the Type Library wizard, and then generate the base code.
The calculations we’re having to implement are described in official rules and regulations that are still not ratified, and so could still change before we’re done — they very probably will, perhaps quite extensively. Waiting for the final version is not an option.
An alternative way could be to finish the entire object model first, and write a separate Automation server which only describes the top-level object, switch $METHODINFO ON, and use TObjectDispatch to return all the subordinate objects. As I see it, that would entail having to write wrappers to return the objects by IDispatch interface. Since there's over a 100 different classes in there, that doesn’t look like an attractive option.
Edit: TObjectDispatch is smart enough to wrap any objects returned by properties and methods as well; so only the top object(s) would need to be wrapped. Lack of a complete type library does mean only late-binding is possible, however.
Is there an other, easier (read: hassle-free) way to write a COM-accessible object model in Delphi?
You don't have to use the type library designer. You can write or generate (e.g. from RTTI of your Delphi classes) a .ridl file and add it to your Automation library project.
Generating interface description from RTTI is a great idea! After you have your interfaces generated you can generate a delphi unit from them and implementing in your classes. Of course the majority are implemented already since you have generated the interfaces from those classes after all. The late binding resolution can be done after that by hand using RTTI and implementing IDispatch and IDispatchEx in a common baseclass of the scriptable classes.