What is a tie delegation model in a CORBA application? When is it
used?
It is a different way to implement your servants. The normal approach is to use the inheritance approach, but TIE is mostly used when multiple inheritance in application code is tried to mix with CORBA. I would recommend you to use the inheritance approach.
The tie model is used for Java implementations to get rid of inheritance, which is usual in CORBA objects.
see also http://www.cse.ohio-state.edu/~gurari/course/cis888w04/cis888w04su64.html
The tie model frees the implementation to inherit from arbitrary interfaces
The tie model is an alternative to the typical inheritance model
Related
I've just started with F# and using Record types as I am trying to move away from OOP to a more Functional programming approach. The objects will ultimately be stored in MongoDB and used in the application.
I am moving my code from typescript and I have some objects that inherit from other objects. Is that possible with record types or should I be using classes or structs?
No, F# records don't support subtype polymorphism (like classes in OOP land) nor structural subtyping (like various aspects of TypeScript).
If you must work with something that requires inheritance, you should generally use classes.
My IOS application includes similar views that draws data from server and visualise them.
I want to combine common networking code in a class to ensure reusability and to avoid repeated code.
Should I locate networking code in a super class or in an associated class. I couldn't make a decision which method should I use, generalisation or association (aggregation)?
What would you do if you were me?
It is not good solution to create view superclass for storing client-server communication code due causes:
Client-server communication isn't a part of data presentation (View). Logically it is separate entity.
If you use associated object you could use it anywhere, not only in Views that represent loaded data. It makes your architecture more flexible.
There are more reasons to not use inheritance in your case but I think these two points are enough to make decision.
To my mind you should use associated object (aggregation).
Heyho,
There´s a question in my mind for some time now, which hopefully can be cleared quickly by some of you:
I am a big fan of MVC, ASP.Net Mvc in my case.
What I have noticed is the hype about interfaces. Every video, tutorial and book seems to solve any kind of abstraction with interfaces. I have adapted these patterns, understood why and how and I am basically very happy with it.
But I just don´t get why interfaces are used everywhere. I´ve almost never seen some abstraction being done with abstract base classes, which I don´t understand. Maybe I miss something? I know that you can only inherit from one base class while multiple interfaces are possible. But interfaces do have disadvantages, especially when some changes need to be done, which breaks your implementations.
In my projects so far, I only used to pick interfaces for completely different classes.
For example, the whole repository pattern could be done with an abstract base class, still providing testability and exchangeability, or did I miss something?
Please point me to the part where my brain laggs :)
Interfaces are used in tutorials, blogs and elsewhere because those authors are particularly influenced by a group of methodology called "design for testability".
Primarily, design for testability school of thoughts used interface every way because they want to be able to mock any component under tests. If you use concrete class, then a lot of mocking tools can't mock those class, and hence will make it difficult to test your code.
A Story
I once attended a Java user group
meeting where James Gosling (Java's
inventor) was the featured speaker.
During the memorable Q&A session,
someone asked him: "If you could do
Java over again, what would you
change?" "I'd leave out classes," he
replied. After the laughter died down,
he explained that the real problem
wasn't classes per se, but rather
implementation inheritance (the
extends relationship). Interface
inheritance (the implements
relationship) is preferable. You
should avoid implementation
inheritance whenever possible.
While using only or mostly Interfaces does have code reuse problems(as well as eliminating nice base classes), It makes it a lot easier to do Multiple Inheritance like things. As well as having widely different implementations that will work and where you don't have to worry about the base class changing or even what it does(you do have to implement the whole thing though so its a trade off).
P.S. I think the new Go language is based on interfaces rather then inheritance(looks sort of interesting).
If the language doesn't support multiple inheritance or mix-ins abstract base classes are limited in scope compared to interfaces. E.g. in .NET if you must inherit from some other type such as MarshalByRef, you can't use an abstract base class to implement a pattern. Interfaces do not impose this restriction.
Besides the fact you mentioned that you can inherit from a single base class only (which is pretty inconvenient if you want to use an existing class that already inherits from some class with the new framework base class), you also avoid the fragile base class problem if you use interfaces instead.
Coding against interfaces makes your design more flexible and extensible. For instance, plugin frameworks and dependency injection. Without interfaces, the extensibility of it is pretty much limited.
Read about interfaces, abstract classes, breaking changes, and MVC here: http://ayende.com/Blog/archive/2008/02/21/Re-Versioning-Issues-With-Abstract-Base-Classes-and-Interfaces.aspx.
One solution that is presented there (or somewhere else on Ayende's blog) is: do use interface but also provide abstract classes. Those who case about breaking changes can base their implementations on abstract classes. Those who need power of interfaces are also satisfied. But do make sure your methods accept interfaces, not abstract classes, as input.
So as I understand it with good loose coupling I should be able to swap out my DAL with a couple lines of code at the application root.
I have 2 DAL written, Linq-to-sql and a JSon file repository (for testing and because I wanted to try out the System.Web.Scripting.JavascriptSerializer).
linq to sql will create entities instead of my business models. and feed them upwards through an IRepository which is using constructor injection at the application root.
my JSon layer doesn't have any autogenerated classes from which to deserialize so I'm lost as to a simple way to have it depend on an interface or abstract class and still function.
This question is based on the following assumptions/understandings:
I believe I would need the linq to sql layer to implement an interface so the application domain at compile time can dictate that the entity classes are going to have a place to read/write all the current model's fields
Any Business logic dictates a need for another set of classes with almost the same names and same properties in the model layer
Then conversion methods that take the DALs objects and translate them to business objects and back would be needed. (even if both sides are implementing the same interface this seems very inefficient)
This code is yet another place that would have to make a change if the model class or interface changed (interface, business class, view, dal entity)
Deserialization of any alternative DALs requires I create 'entities' with the same properties and fields in that layer(more duplication)
So to meet all of the flexibility/agility goals it appears I need an interface for each application domain/business object, a concrete class where business logic can live, and DAL objects that implement the interface (this means layers that don't autogenerate entities would have to be hand coded pure duplication).
How would I use loose coupling without a ton of duplication and loss of DRY?
Welcome to the beautiful and exciting world of loosely coupled code :)
You understand the problem correctly, but let me first reiterate what you are already implying: The Domain Model (that is, all Domain classes) must be defined independently of any specific Data Access technology, so you can't use auto-generated LINQ to SQL (L2S) classes as a basis for your Domain classes for the simple reason that you can't really reuse those together with other technologies (as you have found out with your JSON-based Repository).
Interfaces for each Domain object is not even going to help you, because to avoid Anemic Domain Models you will need to implement behavior in the Domain classes (and you can't put behavior into interfaces).
This means that to hydrate and dehydrate Domain objects you must have some mapping code. It has always been like this: in the old days we had to map from IDataReader instances to Domain classes, while now we need to map from Data (L2S) classes to Domain classes.
Could we wish for something better? Yes. Can we get something better? Probably. The next version of the Entity Framework will support Persistence Ignorance for exactly this reason: you should be able to define your Domain model as POCOs and if you provide a map and a database schema, EF will take care of the rest.
Until that arrives Microsoft doesn't have anything that offers this kind of functionality, but NHibernate does (caveat: I have zero experience with NHibernate, but lots of smart people say that this is true, and I trust them on that). This is a major reason that so many people prefer NHibernate over EF.
Loose coupling requires lots of mapping, so I can only second queen3's suggestion of employing AutoMapper for this kind of tedious work.
As a closing note I do want to point out a related issue: Mapping doesn't necessarily imply a violation of DRY. The best example is when it comes to strongly typed ViewModels that correspond to a given Domain object. Don't be fooled by the semantic similarity. They may have more or less the same properties with the same values, but their responsibilities differ vastly. As an application grows, you will likely experience that little divergences sneak in here and there, and you will be glad you have that separation of concerns - even if it initially looked like a lot of repetitious work.
In any case: Loose coupling is more work at the beginning, but it will enable you to keep on evolving an application where a tightly coupled application would freeze in maintenance hell long before. You are in for the long haul, but instant gratification it ain't.
Not that I understand the problem correctly, but to solve duplicated classes you may use AutoMapper.
Note that you may apply mapping declaratively or using reflection, i.e. semi-automatically. For example see here - this is not about data layer, but shows how simple attributes can help to automate mapping. In that case MVC applies attributes, but you may invent your own engine that looks for [Entity("Order")] attribute and applies AutoMapper.
Also you cannot have 100% persistence independency with just "couple of lines". ORM selection plays big role here. For example Linq-To-SQL cannot use plain classes (POCOs) so it's not as easy to re-use them as with NHibernate, for example. And with Repository you're going to have many queries in the data layer; different ORMs usually have different query syntax or implementation (even Linq not always compatible between ORMs) so switching data access can be a matter of replacing data layer completely, which is not couple of lines (unless your app is "Hello, world!").
The solution with AutoMapper above is actually a kind of self-baked ORM... so maybe you need to consider a better ORM that suites your requirements? Why don't you use EF4, especially given that it supports POCOs now, and is very similar to Linq-to-SQL, at least with query language?
An answer to a question of mine on DB design suggested something called single table inheritance. I've done a bit of searching on that, but I can't seem to find that much clear information on it.
Basically what I seem to understand from it is that you have a big table with all the fields in it and also a type field - and then your ORM layer uses the type field to give you different object views. Is that correct?
More importantly, is single table inheritance an 'approved' database design technique? By that I mean is it 'sensible' to use it? Is it also safe to use it, or does it cause problems?
The other issue is how well this works in rails? I've found a few references to it from rails - but does it cause problems by doing things the non-conventional way?
Any help much appreciated.
Is it a good idea ? It depends. It breaks Normalization in that a table does not have a single purpose. What happens when you extend the base class for the nth time ? You will have to add columns to the table. Most modern DBs don't have a problem with that as you can modify the table but what about refactoring and removing a class. Now you have columns that don't have a purpose.
A rule of thumb - if most of design has been worked out, it's probably safe to use. If the design is changing frequently - you have other issues and you need to lock down your use cases/user requirements. (yes, not really XP friendly)
I don't know about the Rails effects.
STI is a way of dealing with a mismatch between object- and database-oriented thinking. It allows a reasonable representation of the information within the database and a different representation within the object model.
For example, I have an application where each of my products contains one or more fees, each calculated slightly differently. Within my object model I want to have subclasses of a Fee class, each of which knows how to calculate itself. I don't really want to have a table per fee type though: so I create Fee as the base class and fees as the table, which contains the union of all the fields needed across all the sub-types, plus a "type" column whose value corresponds to the name of the relevant sub-class. ActiveRecord handles the plumbing thereafter.
In short, Single Table Inheritance (STI) is a design pattern that allows a mapping of OOP inheritance relationships to the database. If you define any subclasses from your ActiveRecord model objects, then you should consider STI.
STI is (originally?) documented in Martin Fowler's 'Patterns of Enterprise Application Architecture' book, and is also described in DHH's canonical Rails book 'Agile Web Development with Rails' (section 18.4, I think.) I refer you to these books because they provide a much better explanation than I could hope to do in this space.
I strongly disagree with the sentiment expressed at www.matthewpaulmoore.com (linked by robintw in this thread), that STI is inherently a bad thing. This seems to be a somewhat naive view that discounts the usage of OOP inheritance. I have used STI to create some elegant solutions in Rails, but you can abuse any design pattern, I suppose.
Definitive reference. It allows a single table to store multiple objects that have a common base class.
Ruby on Rails uses a library called Active Record. This is a common Ruby framework that supports STI.
I can only speak from the (new) ADO Entity Framework perspective, which includes table-per-type (TPT) functionality.
Here is a good series of blog posts introducing the core concepts (using the Entity Framework) and there is an MSDN paper on it also here.
There also seems to be some guidance when using nHibernate for TPT, it's located here.
There's this link which explains table-per-type inheritance in SQL Server. This seems to have a pretty good summary and introduction to the concept.
I'm not sure what impact it would have on Rails.
I've just seen http://www.matthewpaulmoore.com/articles/1276-ruby-on-rails-code-quality-checklist#sti which suggests its a bad idea.
Generally I find it useful, but I've encountered some bugs
The example in that link may provide a useful picture of how you might use it.