Use of non-basic techniques

I have questioned myself about this several times, and more often than I'd like, the conclusion I come to is not the one I would wish.

• Is it viable, or even responsible to use "advanced" programming techniques in the workplace ?

The problem here is related to how people use the languages they have at their disposal.
There is a recurring joke about how C++ was named, basically pointing that the name of the language itself is a post-increment operator, and that is the reason so many people use C++ just as they used C (or like a hybrid I jokingly call C+/- ).
C++ is widely regarded as a language that is difficult to master. As such, is it a good idea to use, for example, template metaprogramming, when there is a (sadly strong) possibility that someone that isn't very confortable with regular templates will have to look at your code ?
One could argue that if the code is well designed (and eventualy bug-free), the implementation details should be just details and the other users wouldn't need to know them. But considering that someoone else will probably have to maintain your software, is it really wise to use techniques that might take some time for them to understant ?

From a purist point of view, I believe it is a good idea to do so, because it will probably force your colleagues learn something new, and thus, become better professionals.
On the other hand though, the saying "time is money" springs to mind.
Sometimes, this time might not even be available, and we all know what tight deadlines can do to code quality ...

What is you opinion about this issue ?

On interfaces

A concrete class may be seen as a comprehensive way of describing a set of objects sharing certain characteristics. These objects are said to be their instances.

An abstract class also describes comprehensively a set of objects. However, the objects in this set are not described in full. Rather, their description in full is always provided by one of the concrete classes which specialize the abstract class. Abstract classes, hence, correspond in terms of objects to the unions of the objects which are possible instances of their concrete specializations. Since it is always possible to provide a further concrete specialization of an abstract class, describing a whole new set of possible instances, abstract classes are, in a sense, open.

Classes, whether abstract or not, are always descriptions of objects. Hence, their identifiers are usually nouns or small noun phrases. E.g., Vehicle (abstract class) and Car (depending on the context, may either be concrete or abstract).

Interfaces should not be confused with abstract classes, though the lack of interfaces in some languages forces programmers to use abstract classes as an alternative. Interfaces represent abilities which objects may have. The abilities are supposed to be related to behaviour. Having a certain ability is usually insufficient to fully describe a possible, existing, object. Hence, interfaces usually represent partial abilities of objects. Objects may have multiple abilities. Since existing objects are always instances of concrete classes, their possession of certain abilities must be declared at the class level. Hence, classes implement interfaces. Multiple classes may implement the same interface, and multiple interfaces may be implemented by a single class.

Class specialization, or extension, may be seen as a two-way process. Firstly, the specialization implements the behaviour of the more general class, i.e., the more general class is seen merelly as an interface, whose abilities the specialization declares to provide. Secondly, the specialization inherits the implementation available in the more general class (which may or may not be complete, according to whether it is concrete or not - though specialization of concrete classes is not recomended).

It is the implementation of behaviour which provides the notion of sub-typing. Sub-typing allows dynamic polymorphism, which is thus (in a way, just) possible through interfaces. Sub-classing is sub-typing plus implementation sharing. In Java multiple sub-typing is possible, but multiple sub-classing is not.

Since interfaces declare behaviour, their identifiers should be adjectives (or adjective phrases) representing abilities. In the english language most of these adjectives end with the suffixes "-able" or "-ible", from the latin "-abilis", meaning "capable of". E.g., the classics Comparable or Clonable.

If your best choice for the identifier of some classe or interface does not fit with the above recomendations, then think again about your modelling: it is most likelly wrong.

Finally, yes. It is true. The name "interface" is not very good. One should say that a class "provides" a certain "behaviour" instead of simply saying that it "implements" a certain "interface". Even if the lack of support for programming by contract makes the explicit contracting of behaviour impossible, forcing the compiler to merely check whether... interfaces are implemented. Sigh...

From: Rambling about Java

O legado

C++.
A minha linguagem de eleição, infelizmente vítima de inúmeros mitos e preconceitos nos dias que passam.

Certamente um dos mais infundados e, na minha opinião, injustos é o de que o C++ é uma linguagem ultrapassada e antiquada.

A minha humilde opinião : Embora o standard tenha estado parado durante alguns anos, os usos da linguagem e as suas boas práticas alteraram-se radicalmente durante o tempo de vida da mesma.
O C++ é frequentemente comparado ao Java e não menos frequentemente considerado menos "avançado". Há que notar uma grande diferença aqui. Java foi criado com uma filosofia quase oposta à do C++. Enquanto que o primeiro tenta esconder as fontes de erros do programador, o C++ deixa o poder (e as responsabilidades) nas mãos de quem o usa. Isto certamente torna C++ uma linguagem com uma curva de aprendizagem menos amena do que outras linguagens mais simples, mas nunca o tornará menos "avançado". Até pelo contrário...

Não conheco ninguém, que depois de compreender o que é possível fazer, e já foi feito, em projectos como a famosa STL, as libs do Boost ou ainda na lib Loki por indivíduos brilhantes, que considero como hackers dignos deste nome nos dias que correm, continue a olhar para C++ com os mesmo olhos de desdém ou até de medo...

O meu medo é do ímpeto que as linguagens concorrentes possam adquirir, atraindo cada vez mais novos talentos e esforço para as suas causa, deixando assim o C++ depleto do que faz qualquer linguagem vingar. O apoio, a escolha e o uso alargado por parte dos programadores.

E este preconceito vem de onde ?
Em grande parte julgo vir do forte legado que C++ tem. A sua luta para manter um alto nível de compatilidade com C.
O que começou por ser um ponto forte para a adopção da linguagem é, actualmente e na minha opinião, a raíz de muitos problemas com código C++ (e, irónicamente, também o que possibilitou uma fácil adopção progressiva do C++ por parte de programadores da velha guarda).
Ao usar o C++ como apenas um C com classes (ou seja, o que C++ já foi, lá nos princípios, na década de 80), acabamos por ficar com o que eu gosto de chamar de código C mais ou menos ...
É este tipo de código que, apesar de ser código válido, vai dar o mau aspecto que C++ parece ter aos olhos de quem ainda não o abraçou de alma e coração.