Jump to content
Carlos Tré

Typecasting interfaces to keep code loosely coupled and LiveBinsings

Recommended Posts

Dear fellow programmers,

 

I'm trying to stick to Nick Hodges advice and keep the code loosely coupled, separating business from presentation, and observing oop principles. In order to accomplish this I:

1) code against interfaces;

2) adopted a sort of MVVM design pattern. Sort of because i don't really understand the difference among MVVM, MVC, MVP, etc. I thought that if I have business logic, view logic and persistence logic in separated units, apart from the views, and fully testable, I'd would be Ok to go;

3) I use Spring4D all around because in the future I want to take advantage of it's dependency injection capabilities.

 

When it came to implement LiveBindings I stumbled into a problem: in order to create the adapters I need the actual classes, and to make the class implementation details visible in the module I call ViewModel would defeat all the isolation I accomplished so far. The solution I came up with is to keep interfaces in one module, implement them with abstract classes in another codeless module, and inherit from them and writing all the code in a third unit. I could keep the interface and it's abstract implementation in the same unit, both have no code, or separated and add another level of organization.

 

That said, I kindly ask for your input on the solution I came up with. My goal is to keep Nick happy with interfaces, keep Delphi happy with classes, and myself happy with Spring4D. Is this the way to go or is there a better solution?

 

Thank you so very much in advance .

 

Best regards,

Carlos Tré

 

Share this post


Link to post

I think in the DI book there is a chapter about injectables and creatables. Stuff that you bind to UI are usually creatables thus objects and should not have a problem.

Binding interfaces is almost if not entirely impossible in a clean way because they simply don't have property RTTI.

Share this post


Link to post
1 hour ago, Stefan Glienke said:

I think in the DI book there is a chapter about injectables and creatables. Stuff that you bind to UI are usually creatables thus objects and should not have a problem.

Binding interfaces is almost if not entirely impossible in a clean way because they simply don't have property RTTI.

Hello Stefan.

 

Yes, there is. And I remember you've told so some time ago, when I was toying with REST DataSnap and run into a similar situation. What bothers me is that if I need to create objects for every UI class a great deal of decoupling will be gone. In your opinion, the use of an intermediate abstract class is too much of a kludge or a time bomb just waiting for the worst possible moment to explode in face?

 

On the other hand, thinking while typing this reply, if I skip the interface declaration for UI objects, and stick to abstract classes to hide the implementation details, I'll be as good as, right? 

 

Well, they joy of old dogs insisting in learning new tricks, senile moments get in the way mora and more. 🙂

 

Thank you so much for your time.

Share this post


Link to post

I was not talking about making classes for UI controls but exposing your dataobjects in a way that you can bind them in some way to the UI.

Personally I don't like LiveBindings that much - and I gave up on some MVVM-ish approach for Delphi.

 

What works kinda well is going the DB aware approach with datasets (can use things like the TObjectDataSet from Spring4D or other similar ones - DevArt for example has also one) that just are adapters to non dataset/database data such as lists of objects.

 

There are other approaches such as my TTreeViewPresenter that connects an IObjectList from Spring4D to a TVirtualStringTree to display and even edit data.

  • Like 1

Share this post


Link to post

I've failed to mention it is for a FMX application, so dataware is not possible. 

 

Once again, than you very much for your input, I'll try not to overdo things which, unfortunately, I only notice way down the road.

 

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×