Interfaces vs Abstract Classes

It's to provide type safety in JavaScript where type / error checking can be done compile-time, pre-ES6.
Understand the sentiment... doubtful this is going end any better than Dart.
I think the time would be far better spent on trying to startup a new unhinged language to replace JS... but the chance of getting Microsoft, Google, Apple, Firefox to agree, is probably as good as TS succeeding.
 
[)roi(];18882428 said:
Understand the sentiment... doubtful this is going end any better than Dart.
I think the time would be far better spent on trying to startup a new unhinged language to replace JS... but the chance of getting Microsoft, Google, Apple, Firefox to agree, is probably as good as TS succeeding.
Don't sell it short, tech like Native Script prefers you using it. Personally I'm not a fan of transpiling, but the type safety and generics TS brings certainly has appeal.
 
Don't sell it short, tech like Native Script prefers you using it. Personally I'm not a fan of transpiling, but the type safety and generics TS brings certainly has appeal.
Maybe re not selling it short... but can't see much appeal for me, still far too OOP centric & what's there ito type safety & generics is meh, ...
 
Read the right stuff - like the work from Martin Fowler. First understand the theory and then look at implementation in a language.
Be careful with just accepting the work of "person X" as absolute.

Martin Fowler in particular has encouraged a lot of practices, many that are now considered code smells. Far better to question everything, and adopt those practices that make sense.
 
[)roi(];18883892 said:
Be careful with just accepting the work of "person X" as absolute.

Martin Fowler in particular has encouraged a lot of practices, many that are now considered code smells. Far better to question everything, and adopt those practices that make sense.

Good point. I should have added a couple of examples, but I still think Fowler is a good place to start.

Especially on infoq and similar sites there are a lot of material (often opposing Fowler). They also look at a lot of real world lessons learned.
 
[)roi(];18883892 said:
Be careful with just accepting the work of "person X" as absolute.

Martin Fowler in particular has encouraged a lot of practices, many that are now considered code smells. Far better to question everything, and adopt those practices that make sense.
Do not take the "lord's" name in vain!

:rolleyes:

My mood changes for the worse everytime i hear or see his name.
 
Do not take the "lord's" name in vain!

:rolleyes:

My mood changes for the worse everytime i hear or see his name.
Lol :D
Some of his stuff is well documented and sort of ok... anyway I'm always surprised by the places I learn something; was recently advised to look at a programming book from 1975 called "Recursive Programming Techniques" which was published as part of IBM's System Programming series; basically a project to collect and share techniques considered to have lasting value. To summarize I was compleletly gobsmacked, the author articulated most of the basis of today's Functional Programming and many of the techniques.

Point is to never discount a source of knowledge, even a bad one is good if it allows you to definitively argue that.
 
Don't shelve interfaces, try to use them instead and only use abstract classes / inheritance when it becomes desirable for the partial implementation it offers or when design patterns justifies the need.

One thing though, If I have a Data layer and a Business Layer ok. Even when I only use interfaces without any abstraction, I still need to provide the Business Layer with a means of calling the Data Layers methods like this:

Code:
Interface IEmployees {

   Dataset GetEmployees();
}

Code:
Class Employees: IEmployees{

EmployeesBAL BAL;

   public Employees() 
   {
        BAL = new EmployeesBAL();
   };

   Public Dataset GetEmployees() {
   
   }

}

I still have to couple the business layer to the data layer some how. They are not truly separated. I suspect DI would fix a problem like this but the solution is juuuust out of my reach.
 
Last edited:
Using DI here is as simple as:

Code:
Class Employees: IEmployees{

IEmployeesBAL BAL ;

   public Employees(IEmployeesBAL bal) 
   {
        BAL = bal;
   };

   Public Dataset GetEmployees() {
   
   }

}

IEmployeesBAL bal = new EmployeesBAL();
IEmployees employees = new Employees(bal);


Obviously something like Unity will manage the "newing" for you
 
Last edited:
Using DI here is as simple as:

Code:
Class Employees: IEmployees{

IEmployeesBAL BAL ;

   public Employees(IEmployeesBAL bal) 
   {
        BAL = bal;
   };

   Public Dataset GetEmployees() {
   
   }

}

IEmployeesBAL bal = new EmployeesBAL();
IEmployees employees = new Employees(bal);


Obviously something like Unity will manage the "newing" for you


Interesting. You are passing in an interface reference in the constructor ok I get that. Those last two lines hmm interesting. I'll give that crack thanks kabal.
 
One thing though, If I have a Data layer and a Business Layer ok. Even when I only use interfaces without any abstraction, I still need to provide the Business Layer with a means of calling the Data Layers methods like this:

Code:
Interface IEmployees {

   Dataset GetEmployees();
}

Code:
Class Employees: IEmployees{

EmployeesBAL BAL;

   public Employees() 
   {
        BAL = new EmployeesBAL();
   };

   Public Dataset GetEmployees() {
   
   }

}

I still have to couple the business layer to the data layer some how. They are not truly separated. I suspect DI would fix a problem like this but the solution is juuuust out of my reach.

Is your data layer generic?
 
An application which uses these Shapes can then be written by drawing all of the circles and rectangles by calling calling the draw method on an array of Shapes. The Shapes will be correctly drawn based on the sub classes implementation.
 
Last edited:
Is your data layer generic?

Not by these standards no.

In my CustomerDAL I handle only building the parameters then in the DB class I have 3 methods, insert,update and delete. I'm using this as an example from another project I'm working on. In the BAL I just handle custom lists like ICompare/IComparable and also do verification on my data.

Flame away.

DBManager
attachment.php


DAL
attachment.php
 
Not by these standards no.

In my CustomerDAL I handle only building the parameters then in the DB class I have 3 methods, insert,update and delete. I'm using this as an example from another project I'm working on. In the BAL I just handle custom lists like ICompare/IComparable and also do verification on my data.

Flame away.

DBManager
attachment.php


DAL
attachment.php

Argh man. You're not using Entity Framework. I only know that....
 
Argh man. You're not using Entity Framework. I only know that....

Dam. Well if and when I do need to learn EF I'll know to contact you, not atm though, still trying to create a model I'm happy with.
 
What's with catching the exception only to throw it again?
 
Omg this could be on a t-shirt. Aaahaha.

It's just for testing really, it gives me the most direct answer to what is going on. I'll clean it up later.
Replace it with "throw;" (i.e. remove the ex) so you at least keep the original stack trace. "throw ex;" resets it. Won't make much of a difference here but now you know.
 
Top
Sign up to the MyBroadband newsletter
X