Structure of program - polymorphism

Do you really need each building type to have its own type in the language as well, and not just have one building type that has data members describing the different buildings instead?

I didnt think about just one class, because it would have really lots of data and functions, but it can work. But I think that in games like Age of Empires or Caesar it is done in some nicer way.

Of course you can separate your data in different ways more than just one single big class, but modelling the game in the language is not really flexible. What is the alternative to lots of members; lots of functions? At least the data members can be easily set dynamicallyfrom external sources so you can tweak eveyrhing as you like and create new building, units, weapons, monsters, player classes, cities and whatever by just poking around in a text file. Your alternative here would be to program them in the source code and recompile your whole game.

A better and more specific answer to your particular situation can perhaps be given if you describe your situation and what all you 30 types and 90 functions are.

OK, thanks for the answer. I thought that there is some common way or some trick how to deal with this problem. But it looks like it isnt, so I will do it somehow.

You may be running into the M*N problem (a typical issue in OOP), with M being #buildings, and N #operations-on-buildings, and M*N being your code complexity.
A solution wouldn't be to go back to procedural programming (as someone noted: "What is the alternative to lots of members; lots of functions?").
Instead, consider a generic programming (GP) solution -- if there is a common algorithmic functionality to what you're trying to achieve, perhaps a few (instead of "lots") free-standing (i.e., not member) function templates parametrized on your building-type might be the way to go? In case of STL, this solution allowed to bring down code complexity from M*N (which would've been the case if the containers & algorithms were to be organized into a class hierarchy and distinguished when operated upon via virtual member functions -- the OOP way) to M+N (which is the case for generic container classes (no virtuals) operated on by generic (parametrized by container and/or iterator type) algorithms) -- so, arguably, that's a common way to deal with this problem :-)
See:
http://gsd.web.elte....cles/icai99.pdf
https://github.com/b...aph_library.pdf