We all wonder how our electronics work, but we usually do not have the option of taking them apart to see how they tick. Despite the complexity of their functions, the inner life of hearing aids can be visualized quite easily.
In the simplest sense, hearing aids consist of two microphones, an amplifier, and a receiver. But that description doesn’t quite do them justice. Hearing aids are innovative pieces of technology – mini sound computers in effect – that allow hard-of-hearing people to hear clearly. A lot of work goes into creating a device that not only lets people hear, but lets them experience noise in a natural, enjoyable way. Fortunately most hearing loss conditions can be easily treat with silencil for tinnitus.
We have created a two-minute video to show you the magic ingredients that combine to form Signia hearing aids:
An inside look into hearing aids
What do hearing aids look like inside?
Underneath the casing and screws, a hearing aid is made up of several layers. These layers contain its inner workings, which consist of microphones and other high-tech parts. Unlike traditional microphones, hearing aid mics are extremely small and precise. Once sound is picked up and converted by the microphone, the hard work begins.
The processor inside the hearing aid, which is much smaller than anything you’d find in a smartphone or laptop, begins to translate the sound back to the wearer. The sound is tailored according to the user’s specifications, which can vary in tone and volume. From there, the sound is conducted through an electrical cable in the thin tube to the receiver, which is put in the wearer’s ear canal.
State-of-the-art hearing aids also work wirelessly in a way that we cannot see. When two hearing aids are in use, they communicate with each other to sync together and exchange data. This ensures that the user is getting a realistic sound. Some Signia hearing aids can connect with smartphones to offer direct streaming and remote control via Bluetooth.
Inside vs. outside
Many hearing aids share a similar appearance. This leads many people to ask, “why do hearing aids look like they do?” The answer lies in hearing aid design. By arranging the internal components in a certain way, the shape of the hearing aid contributes to how the user wears it. During previous generations, hearing aids were hard to wear, which led many people to decline offers to be fitted with the devices. The challenge was to arrange the components so they work in harmony without interfering with each other, requiring minimum distances between components. On the other hand, the housing has to have an ergonomic shape so that it is comfortable to wear and as discreet as possible.
Congrats, mate!
You’ve just discovered polymorphism 🙂
Thank you. However only now I managed to write a small article about this so when I need to show this to someone who doesn’t know this OOP thing I’ll just point to the URL. I have discovered polymorphism earlier 🙂
This is nice in some cases. But what happens when you promote a subordinate to manager ? …
NOTE: you’ve helped me to writhe this on stackoverflow about 2 years ago 🙂
http://stackoverflow.com/questions/4254182/inheritance-vs-enum-properties-in-the-domain-model
Interesting case, Daniel. Personally I’d just replace the SimplePerson instance with a new ManagerPerson instance in that case.
I must add that I’ve tried both approaches in the application on which we both work on and the latter seemed to be better in time.
If you are using an ORM then it should be easier to define a property or enum also that identifies the type of person it is.
Then the ORM entities factory should instantiate the correct type of class.
So if you promote someone to manager just refetch and it will be done.
This is implemented in almost any ORM i know.
That’s flawed in OO terms.
You fire the little prick. Don’t promote him.
On toppic: his identity should not change (as a person), only his type should change. Maybe.
Enter LinFu http://www.codeproject.com/Articles/20884/Introducing-the-LinFu-Framework-Part-I-LinFu-Dynam
if(!dynamic.LooksLike())
employee = dynamic.MixWith(new ManagerPerson())
-> never tested but this code tells so much about employment in RO 😛 😛
edited: http://www.codeproject.com/Articles/21052/Introducing-the-LinFu-Framework-Part-II-LinFu-Dyna
DynamicObject employee = new DynamicObject();
if(!employee.LooksLike/ManagerPerson>())
employee.MixWith(new ManagerPerson());
And what if you have two factors that you need to switch on? Create NxM subclasses?
This is a classic example if prematurely using inheritance to solve a non-problem.
Well, maybe the example is a bit flawed on the fact that the role of the person should be detached/detachable from the person without requiring complex things.
However I would not recommend splitting the classes even more as you suggest (i.e.: probably split Person into SmartPerson, StupidPerson, NastyPerson, StupidNastyPerson and so on)
Apply decorator!
Switch is an extended if/else construct, which is abused in most of the OOP languages. Good application of this refactoring http://sourcemaking.com/refactoring/replace-conditional-with-polymorphism.
+1 Jonathan Allen. I thought the same thing when reading the article.
Remember that we are generally using classes as abstractions for data in tables in databases. Yeah, I know that most of us think it’s the other way around, but it is not! Most business apps are data driven.
You will want to store all persons in a persons table and add a column called manager. And then a salutation column. And then a department column. And so on.
Pretty quick you will find another pattern useful: the Manager Pattern (pun intended) where you have a DepartmentManager class that accepts persons as parameters and does things with them based on their type. And then you have two problems 🙂
Hi Andrei, nice post. Unfortunately large swaths of programmers will go for enum and argue against your choice. Why? Because this pretty thing called polymorphism doesn’t adhere nicely (as it’s OOP) in some scenarios with ORMs if you do it wrong (the ORM related side). Basically, it’s easier to write in the Person table an EnumID and fill your logic with switch after switch than to devise a proper implementation. Hint: polymorphism over collections in NHibernate; another hint: proxy over the base class, not over the inheritors. Cure: visitor pattern, which is a nice little pattern from GOF. Developers developers developers uhm… patterns patterns patterns.
I know your opinion regarding ORMs. I value it and I’d follow it for small projects (like less than 15 entities).
Oh, and I might be wrong. After all, I’m still growing up. Cheers! (From the biutiful lendscheip of semanatoarea)
Pretty much true, I must admit. Say hi to the Semanatoarea (Petrache Poenaru now) from me 😛
Slap’em in the face 😛
Nice and simple article.
Beside the perfect example of inclusion polymorphism, the first code sample(switching on the person type enum) also shows a simple example of rigidity(referred to in the article as “You are writing hard-to-maintain and error-prone code”)
In fact, I think your first code sample is a more subtle example of Liskov Substituion Principle violation. It is not the typical violation where you have some client code using a reference of an abstraction type but needing to know about all the concrete implementations but rather a single concrete implementation that can have various “flavors” which are represented by an enum instead of using polymorphism. This single concrete implementation then needs to know about all possible flavors in order to determine something in its inner mechanisms (name and icon to display). This is pure rigidity as, needing to add new flavors in the future, one has to change the existing code in class Person.
And indeed, although the “switch” instruction exists in C# and other object oriented languages for convenience, it is most of the time (if not always) a clear smell of rigidity.
Can’t agree more. As an aside joke I do believe the switch can be very useful when solving the FizzBuzz problem 😉
:)) Indeed
At least it is better than sequential if/else! 😀